Public IP with reverse DNS - Tunnel doesn't get re-established

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Get a public IP from the ISP DHCP server.
2. ISP hands out a dynamic reverse DNS (machine name/hostname) name.
3. configd changes the hostname (from "MacBook") to ISP reverse DNS.
4. Connect to remote VPN. Tunnel is up and working as expected.
5. DHCP Request from localhost to ISP (Wireshark confirms that the request
contains the option: Host Name = "MacBook")
6. configd changes hostname to "MacBook"
7. Leasewatch triggers a restart
8. openVPN stalls (resolv-retry infinite) with message: RESOLVE: Cannot
resolve host address: vpn.xxxxxx.xx.xx: [HOST_NOT_FOUND] The specified host
is unknown.
9. After about 1 min the kernel starts to fill up the log with:
"dlil_output: output error retval = 37" 

What is the expected output? What do you see instead?

Tunnel doesn't get re-established. Unable to resolve remote host. 

What version of Tunnelblick are you using? On what version of OS X? PPC or
Intel?
OS X Intel 10.5.8; Tunnelblick 3 (3.0b24 build 1301); OpenVPN 2 (2.1_rc20)

Please provide any additional information below.

If a router with NAT/PAT is used, every thing works as expected.
Tunnelblick-Leasewatch.log does not contain anything useful (just normal
DNS/WINS changes under DHCP rebind.

Original issue reported on code.google.com by alexande...@gmail.com on 25 Jan 2010 at 3:13

[GoogleCodeExporter]

Since Tunnelblick 3.0b26 (build 1395) with OpenVPN 2.1.1 is out I tried the 
above
once more. The problem persists... It also occurs in a fresh install of 
Tunnelblick
on OS X 10.6.2.

Obvious Workaround, if the remote side of the VPN has an IP address that doesn't
change: Use the other end's IP address instead of an hostname...

So something breaks when there is no router/NAT involved and that results in an
situation where openVPN can't resolve an hostname. 

The use of an hostname in the openVPN client configuration files shouldn't alone
cause this behaviour.

Has anyone else reproduced this issue?  

Could it be an issue with the standard scripts? Any thoughts?

Original comment by alexande...@gmail.com on 11 Feb 2010 at 11:40

[GoogleCodeExporter]

Please try Tunnelblick 3.1beta18 with "Monitor connection" checked. A recent 
change to the leasewatch script deals better with DHCP renewals and may solve 
this problem.

Original comment by jkbull...@gmail.com on 18 Oct 2010 at 10:55

[GoogleCodeExporter]

OS X Intel 10.5.8; Tunnelblick 3.1b18 (build 2078); OpenVPN 2.1.3

This issue seems to be gone! (Upgraded from Tunnelblick 3.0 stable)

I can't reproduce the symptoms and I still use the hostname as remote entry in 
my OpenVPN configuration file.

The tunnel now stays up during DHCP rebind.

Keep up the great work with Tunnelblick! :)

Original comment by alexande...@gmail.com on 18 Oct 2010 at 8:02

[GoogleCodeExporter]

Thanks for your support!

Original comment by jkbull...@gmail.com on 18 Oct 2010 at 9:34

• Changed state: Fixed