1.3.1 DHCP bugs

[MasterYous]

Hey James and team -

I'm a long-time user (contributed to this community before with some DNS scripts) so you might remember me. Wanted to hop on and report two bugs I found while using 1.3.1 - one of which is a showstopper for someone using a pure DHCP configuration such as myself.

Bug one - bad -
My config: I don't push any options from the server and allow my clients to grab everything including IP address, domain suffix, etc. via DHCP.

In 1.3.1 the stuff sent BACK across the tunnel (tap) via DHCP is somehow not being interpreted properly by the Viscosity subsystem, hence the tap adapter is not getting an IP address. I ruled out that this was an openvpn problem by doing three things:

- I switched back to the older Viscosity 1.2.3 but replaced openvpn 2.1 with the newer 2.2.0 - it worked fine
- I switched to the new Viscosity 1.3.1 and I can see my DHCP server trying to hand out the IP address and send it across the tunnel (meaning we're negotiating fine), but Viscosity won't pick it up (my DHCP server's address pool was rapidly exhausted!)
- I invoked openvpn 2.2.0 from the command line (w/o Viscosity) and it works

I'm happy to send whatever you need to troubleshoot, not sure if the log file is helpful in this case.

Bug two -
lladdr doesn't work consistently with Viscosity - never has for some reason. I use lladdr to make the MAC address the same - I don't want to get a new IP address every time I connect. Sometimes it's ok, but more often, the use of lladdr prevents the passing through of a valid IP address and instead the IP address is the DHCP autoconfiguration address since it times out trying to get a real one.

Thoughts?

(does anyone out there use lladdr successfully with Viscosity?)

[James]

Hi MasterYous,

lladdr doesn't work consistently with Viscosity - never has for some reason.

I believe what you may have been seeing here is Viscosity turning on DHCP slightly before OpenVPN had set the MAC address. To most DHCP servers this wasn't an issue, however for some setups it could result in no IP address getting assigned. I've made some changes to the latest beta (1.3.2b7) to ensure DHCP will only ever be turned on after OpenVPN has set the MAC address. Give it a try and see how it goes.

In 1.3.1 the stuff sent BACK across the tunnel (tap) via DHCP is somehow not being interpreted properly by the Viscosity subsystem, hence the tap adapter is not getting an IP address.

I'm afraid this I can't explain. Perhaps it is related to the MAC address getting changed half-way through a DHCP negotiation, in which case the above beta version shouldn't have the problem.

With the exception of turning on DHCP on the tap interface, Viscosity doesn't have any interaction with a DHCP server at all. To be honest it sounds like an MTU issue I have experiencing just recently: I wasn't getting an IP from the DHCP server, even through the server could see the requests. It turned out the MTU the OpenVPN server was using was lower than what the tap interface was set to (the default of 1500). You could try lowering the MTU of your network interface as a test and doing a DHCP renew while connected to see if it could be a similar issue:

sudo ifconfig tap0 mtu 1300
sudo /usr/sbin/ipconfig set "tap0" DHCP

Viscosity's behaviour towards DHCP hasn't changed at all between 1.2.3 to 1.3.1 (there is nothing really to change). The only thing that I could see affecting anything is how it is spawning OpenVPN: it now uses the default OpenVPN script-security value, rather than forcing it to level 2. If you are relying on your own scripts for interaction with the DHCP server then this could affect things.

Finally, the only other thought I have is it could be related to IPv6: if you have Viscosity enabling IPv6 on the interface try turning it off and see if it makes a difference.

Cheers,
James

[MasterYous]

I've made some changes to the latest beta (1.3.2b7) to ensure DHCP will only ever be turned on after OpenVPN has set the MAC address. Give it a try and see how it goes.

Thanks for your response, I will try this now and see if it helps either or both issues - I will post back.

[MasterYous]

I've made some changes to the latest beta (1.3.2b7) to ensure DHCP will only ever be turned on after OpenVPN has set the MAC address. Give it a try and see how it goes.

Thanks for your response, I will try this now and see if it helps either or both issues - I will post back.

James - I am pleased to report that your latest 1.3.3 client solves all 3 of my issues. DHCP negotiation is back and working well; lladdr now works consistently for the first time since I've ever used Viscosity, and connections using OS X Lion work. Well done.

One final issue remains, which is that "Use simultaneous DNS Settings" does not work with my "pure" DHCP configuration. (My remote VPN peer's DNS settings do not get applied). Yes, the DNS settings show up as resolver #2 in scutil --dns but they are not applied. I have my own Apple python API scripts which I can continue use to fix this in the interim, but it would be great if you could fix this.

Well done, and thanks

[James]

Hi MasterYous,

Great to hear - and thanks for the feedback!

One final issue remains, which is that "Use simultaneous DNS Settings" does not work with my "pure" DHCP configuration.

Yes, support for this will certainly be getting added.

Cheers,
James

[NCI]

James, et al,

I seem to be having a similar problem under a similar configuration and it appears to be the DHCP REQ before the MAC address is set. If I drop lladdr from the configuration, I get an assignment but exhaust my DHCP pool quickly upon reconnects. Here's a snippet of the log output using Viscosity 1.3.5 and 1.4b3:

Jun 08 11:19:55: Peer Connection Initiated with [AF_INET] XX.XX.XX.XX:1194
Jun 08 11:19:57: TUN/TAP device /dev/tap0 opened
Jun 08 11:19:57: /sbin/ifconfig tap0 lladdr 2e:d4:26:02:6c:71
Jun 08 11:19:58: DHCP enabled on tap interface tap0
Jun 08 11:19:57: TUN/TAP link layer address set to 2e:d4:26:02:6c:71
Jun 08 11:20:07: Initialization Sequence Completed

Is there a way for me to delay the DHCP Req until the MAC address has been set?

thx.

[James]

Hi NCI,

Viscosity doesn't enable DHCP on the interface until OpenVPN reports it has successfully set the MAC address for the interface. You can see this from the log posted above - the time the log message from Viscosity comes after the two from OpenVPN indicating that the MAC address has been changed (the ordering isn't correct, as Viscosity displays its log messages instantly, but polls OpenVPN log messages, please look at the time for the exact ordering).

We haven't had any reports of this not working, and it appears to work correctly in our own test environments. Could something else be amiss?

Cheers,
James

[hallelujah]

I have the same issue with DHCP REQ sent before MAC address is set via laddr

Can't you add a DHCP delay option in the GUI ?

It may be an openvpn or tuntaposx delay issue though ...

[James]

Hi hallelujah,

I've just put an updated beta build online that adds a small delay before enabling DHCP on the TAP interface (this is running under the assumption that when OpenVPN reports the MAC address has been changed, it is still in the process of doing so). Please give it a try and let us know if it resolves the issue for you:
viewtopic.php?p=134#p134

Cheers,
James