OpenVPN produces DCHP NAK bomb on Win 7 64bit

[JJK]

when launching OpenVPN 2.1.4 on Windows 7 64bit it sometimes results in a DHCPNAK bomb in the event log; the end result is that OpenVPN manages to connect but the routes are wrong.
I've managed to capture the traffic on the tap-win32 (tap-win64?) adapter during the connection process:

​http://www.nikhef.nl/~janjust/openvpn/win7-openvpn-dhcpnak-bomb.pcap

(3 MB)

A second dump without IPv6 traffic can be found here:

​http://www.nikhef.nl/~janjust/openvpn/win7-openvpn-dhcpnak-bomb-noipv6.pcap

(774 KB)

A third dump for OpenVPN 2.2-RC is attached (30 KB)

[Samuli Seppänen]

This issue has been discussed ​here.

[JJK]

Retried it using the DBG tap-win32 driver from the openvpn-2.1_RC7 installer and with 'verb 6' set. It is no longer possible to reproduce the issue. Switching back to the non-debug driver makes the problem appear again; this increases my suspicion that it is a timing issue in the driver itself. Next attempt is to build a debug driver which only prints messages on DHCP NAK packets.

[Gert Döring]

Hi Janjust,

you mentioned that the new 2.2.2 tap driver does not exhibit this behaviour anymore - shall we close the ticket then?

gert

[JJK]

let's just close this ticket, as I can still not reproduce it here on my win7 laptop...

[ert]

I'm still having this issue with the 9.0.0.9 TAP driver and OpenVPN 2.2.2.
It mostly happens on resume after hibernation and may be related to
​https://community.openvpn.net/openvpn/ticket/71

However I don't have permission ot reopen this ticket? :(

[ert]

Seems to be a bug in the TAP driver. It's happening after you try to refresh the DHCP lease 3 times (after resume from hibernation, Windows tries to acquire a DHCP lease too).
I think the reason for this is a programming error in dhcp.c in function ProcessDHCP:

Is this a bad DHCPREQUEST?
if (msg_type == DHCPREQUEST && dhcp->ciaddr != p_Adapter->m_dhcp_addr)

++p_Adapter->m_dhcp_bad_requests;

should be:

if (dhcp->ciaddr && msg_type == DHCPREQUEST && dhcp->ciaddr != p_Adapter->m_dhcp_addr)

++p_Adapter->m_dhcp_bad_requests;

as the win32 DHCP client always requests with all fields set to 0, so this increases the error counter even though it isn't a bad request and as BAD_DHCPREQUEST_NAK_THRESHOLD is 3, it fails after the third renew attempt.
Could someone please fix this in the TAP driver and provide a signed copy? We need the driver for production use...

Regards.

[Samuli Seppänen]

Replying to ert:

Could someone please fix this in the TAP driver and provide a signed copy? We need the driver for production use...

Please test ​this installer, it's got this fix in it.

[ert]

Looks good! No more NAK bombs and no more connection problems on resume after hibernate now! :)
Thank you for your fast response!

[Samuli Seppänen]

Excellent! We'll push out a new release tap-windows and openvpn with this fix this/next week probably.

[David Sommerseth]

Suggested fix is applied to tap-windows.git/master commit 5728d5f65b65b3e2304f18c160b1e5d89217ad10