SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264
| Anonymous | Login | 2021-02-25 13:23 UTC |  |
| Main | My View | View Issues | Change Log | Roadmap |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0001535 | Endian Firewall | Network related (VPN, uplinks) | public | 2009-01-21 05:35 | 2010-09-21 13:03 | ||||
| Reporter | wharfratjoe | ||||||||
| Assigned To | peter-endian | ||||||||
| Priority | normal | Severity | major | Reproducibility | always | ||||
| Status | closed | Resolution | not fixable | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | 2.2-rc3 | ||||||||
| Target Version | Fixed in Version | ||||||||
| Summary | 0001535: Global options are pushed, but no names are resolving | ||||||||
| Description | Global Push options are pushed to client but the dns servers for client are trying to resolve internal hostnames and the dns servers being pushed are not being used at all. /var/efw/openvpn/settings: AUTH_TYPE=psk DOMAIN=trimquick.int GLOBAL_DNS=192.168.1.3,192.168.1.4, GLOBAL_NETWORKS=192.168.1.0/24 PURPLE_DEVICE=tap1 PUSH_GLOBAL_NETWORKS=on PUSH_GLOBAL_DNS=on PURPLE_IP_BEGIN=192.168.1.230 PUSH_DOMAIN=on PURPLE_IP_END=192.168.1.245 PURPLECLIENT_BEGIN_DEVICE=tap2 DROP_DHCP= Client Example: Ethernet adapter {F46F30BE-D9FE-4026-8638-42B782745A18}: Connection-specific DNS Suffix . : trimquick.int Description . . . . . . . . . . . : TAP-Win32 Adapter V8 - Packet Schedu ler Miniport Physical Address. . . . . . . . . : 00-FF-F4-6F-30-BE Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.230 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.1.0 DNS Servers . . . . . . . . . . . : 192.168.1.4 192.168.1.3 Lease Obtained. . . . . . . . . . : Tuesday, January 20, 2009 9:23:45 PM Lease Expires . . . . . . . . . . : Wednesday, January 20, 2010 9:23:45 PM Server tqserver01 is supposed to resolve to 192.168.1.3 but is not: C:\Documents and Settings\joe>ping tqserver01 Pinging tqserver01.nttr.int [208.67.216.132] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 208.67.216.132: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), | ||||||||
| Additional Information | http://www.nabble.com/DNS-address-format-for-OpenVPN-server--to21340568.html#a21577037 [^] I was able to replicate this on two seperate 2.2RC3 machines from various internet connections vpn'ing into the networks. | ||||||||
| Tags | No tags attached. | ||||||||
| Attached Files | |||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0001927) magu (reporter) 2009-01-21 22:57 |
I have the same issue, and found that openvpn.conf does NOT show any 'push dhcp-options DNS' lines. DHCP is turned OFF on my green network (I have another DHCP server inside green). |
|
(0001930) wharfratjoe (reporter) 2009-01-26 19:01 |
Anyword as to a correct work around for this? I also noticed that when connected from a local network to a remote network, the local dns for that local network stops resolving correctly. After you disconnect from the remote network local dns starts resolving correctly again. For example: Remote network is 192.168.1.0/24 Local Network is 172.16.0.0/24 I vpn successfully to remote network. Now when i go to browse, ping or use a local resource on the 172.16.0.0/24, i cannot resolve at all. This local resource of nas-nttr should resolve to 172.16.0.5. Hence I am resolving to OpenDNS ip, which is not correct at all: Pinging nas-nttr.nttr.int [208.67.216.132] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 208.67.216.132: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), After disconnecting from Remote network. Local DNS resolution is correct again: Pinging nas-nttr.nttr.int [172.16.0.5] with 32 bytes of data: Reply from 172.16.0.5: bytes=32 time<1ms TTL=64 Reply from 172.16.0.5: bytes=32 time<1ms TTL=64 Reply from 172.16.0.5: bytes=32 time<1ms TTL=64 Reply from 172.16.0.5: bytes=32 time<1ms TTL=64 Ping statistics for 172.16.0.5: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms |
|
(0001936) wharfratjoe (reporter) 2009-01-29 06:44 |
After working on this for awhile this evening, I found a quick workaround for this. If you just disable the Global Push options in the webgui and then do a save/restart openvpn, remote and local dns resolves correctly. I tested this on three 2.2RC3 machines and its working fine for local and remote dns resolution. |
|
(0001937) wharfratjoe (reporter) 2009-01-29 17:16 |
remote network cnames do not work with this work around only a record entries. |
|
(0001966) wharfratjoe (reporter) 2009-02-15 19:24 |
Anyword on a fix for this yet? |
|
(0002050) wharfratjoe (reporter) 2009-03-16 15:37 |
Anyword on a fix for this yet? |
|
(0002306) wharfratjoe (reporter) 2009-05-09 18:48 |
Anyword on a fix for this yet? |
|
(0002549) peter-endian (administrator) 2009-06-10 10:08 |
i think this is because of the dns suffix. in your post, you ping: tqserver01.nttr.int which uses the global resolver configuration and not the connection specific resolvers, which have been pushed by openvpn. that connection has as suffix: trimquick.int now i am not that windows expert, but try to ping a hostname with trimquick.int as suffix, maybe that resolves correctly. the output of your connection specific configuration is however correct. i think there is nothing we could change on the firewall which would fix this behaviour. i think it's more a configuration issue or issue on windows side. can you try with the other suffix? |
|
(0002756) steven (reporter) 2009-07-14 22:31 edited on: 2009-07-14 22:32 |
I am experiencing similiar DNS issues, got OpenVPN setup G2G all works fine, can ping everything access internal website via IP address everything works except DNS, so far tried a few different options but cant get the DNS to work across the VPN? I am using Community Edition v2.2 |
|
(0002759) luca-endian (developer) 2009-07-15 09:51 |
You can try with dns routing configuring a custom nameserver for your internal domain that is behind the vpn. |
|
(0002766) wharfratjoe (reporter) 2009-07-18 02:47 edited on: 2009-07-18 02:50 |
Its not working. I have all outbound ports open behind another firewall. Connection-specific DNS Suffix . : trimquick.int Description . . . . . . . . . . . : TAP-Win32 Adapter V8 0000002 Physical Address. . . . . . . . . : 00-FF-93-37-D8-28 Dhcp Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.230 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : DHCP Server . . . . . . . . . . . : 192.168.1.0 DNS Servers . . . . . . . . . . . : 192.168.1.4 192.168.1.3 Lease Obtained. . . . . . . . . . : Friday, July 17, 2009 7:35:03 PM Lease Expires . . . . . . . . . . : Saturday, July 17, 2010 7:35:03 PM tqserver01.trimquick.int --> should resolve to 192.168.1.4 Pinging tqserver01.trimquick.int [208.67.219.132] with 32 bytes of data: Reply from 208.67.219.132: bytes=32 time=23ms TTL=55 Reply from 208.67.219.132: bytes=32 time=29ms TTL=55 Reply from 208.67.219.132: bytes=32 time=41ms TTL=55 Reply from 208.67.219.132: bytes=32 time=56ms TTL=55 Ping statistics for 208.67.219.132: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 23ms, Maximum = 56ms, Average = 37ms I also recently upgraded from a Beta to 2.2: Endian Firewall Community release 2.2 (c) 2004-2009 Endian Linux brooklyn.trimquick.int 2.6.22.19-72.endian15 0000001 SMP Mon Sep 8 11:49:17 EDT 2008 i686 i686 i386 GNU/Linux |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 2009-01-21 05:35 | wharfratjoe | New Issue | |
| 2009-01-21 05:35 | wharfratjoe | Assigned To | => peter-endian |
| 2009-01-21 22:57 | magu | Note Added: 0001927 | |
| 2009-01-26 19:01 | wharfratjoe | Note Added: 0001930 | |
| 2009-01-29 06:44 | wharfratjoe | Note Added: 0001936 | |
| 2009-01-29 17:16 | wharfratjoe | Note Added: 0001937 | |
| 2009-02-15 19:24 | wharfratjoe | Note Added: 0001966 | |
| 2009-03-16 15:37 | wharfratjoe | Note Added: 0002050 | |
| 2009-05-09 18:48 | wharfratjoe | Note Added: 0002306 | |
| 2009-06-10 10:08 | peter-endian | Note Added: 0002549 | |
| 2009-06-10 10:08 | peter-endian | Relationship added | child of 0001927 |
| 2009-07-14 22:31 | steven | Note Added: 0002756 | |
| 2009-07-14 22:32 | steven | Note Edited: 0002756 | |
| 2009-07-15 09:51 | luca-endian | Note Added: 0002759 | |
| 2009-07-18 02:47 | wharfratjoe | Note Added: 0002766 | |
| 2009-07-18 02:50 | wharfratjoe | Note Edited: 0002766 | |
| 2010-09-21 13:03 | peter-endian | Status | new => closed |
| 2010-09-21 13:03 | peter-endian | Resolution | open => not fixable |
|
Issue History |
| Copyright © 2000 - 2012 MantisBT Group |
 |