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

0001535: Global options are pushed, but no names are resolving - MantisBT Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001535Endian FirewallNetwork related (VPN, uplinks)public2009-01-21 05:352010-09-21 13:03
Reporterwharfratjoe 
Assigned Topeter-endian 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionnot fixable 
PlatformOSOS Version
Product Version2.2-rc3 
Target VersionFixed in Version 
Summary0001535: Global options are pushed, but no names are resolving
DescriptionGlobal 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 Informationhttp://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.
TagsNo tags attached.
Attached Files

- Relationships
child of 0001927confirmed Reports to be checked - collecting ticket 

-  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


- 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

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker