SSL VPN connection breaks when DHCP client renews IP settings
On MS Windows 10 clients with NetExtender (current ver. 10.2.339) I noticed that SSL VPN connection breaks when the DHCP client on the machine renews IP settings of the network adapter used for the VPN connection. Even if the IP address is not changed in the renewal process, it causes a short disconnect of the network connection (a split of a second) which makes NetExtender break the VPN connection.
Is there anything we can do to prevent breaking SSL VPN connection in such cases?
Best Answer
-
rpr Newbie ✭
In the meanwhile, I found that the DHCP client on the Windows machine logged the following error in the Microsoft/Windows/DHCP-Client/Admin log at the moment it tried to renew IP address:
Log Name: Microsoft-Windows-Dhcp-Client/Admin
Source: Microsoft-Windows-Dhcp-Client
Event ID: 1002
Task Category: Address Configuration State Event
Level: Error
User: LOCAL SERVICE
Description:
The IP address lease 192.168.5.3 for the Network Card with network address … has been denied by the DHCP server 192.168.5.1 (The DHCP Server sent a DHCPNACK message).The DHCP server runs on a home router device which had a reservation defined for 192.168.5.3 according to the client MAC address. When I removed the reservation, the DHCP stopped responding with DHCPNACK on IP renewal request and there was no breaks in the network connection any more.
On https://petri.com/almost-everything-you-need-to-know-about-dhcp-as-a-systems-administrator/ I read:
DHCPNACK
The DHCPNACK or Negative Acknowledgment is a packet that the server sends if the IP address is not available in stand of DHCPACK (in use on other client for example) or the address is no longer valid.
In case of DHCPNACK the client must restart the lease process in order to get an IP address.So, for some reason the DHCP server considers the IP address with MAC reservation defined as not available when the client having that IP address and MAC address asks for IP renewal. I'd say its a bug in that DHCP server.
1
Answers
I have never heard of this, and if this happened in general, I think NetExtender would barely be usable [some routers have a stupidly short DHCP lease time, for example]. So there is probably some specific issue at play in your environment.
@Arkwright
I know that some routers have a very short DHCP lease time. This is how I encountered the problem :-)
Here is how I tested the issue:
ipconfig /renew Ethernet
$ sudo ping -D -O -i 0.1 mypc
PING mypc (192.168.5.3) 56(84) bytes of data.
[1719599782.935701] 64 bytes from mypc (192.168.5.3): icmp_seq=1 ttl=128 time=1.68 ms
[1719599783.036614] 64 bytes from mypc (192.168.5.3): icmp_seq=2 ttl=128 time=1.47 ms
...
[1719599788.169324] 64 bytes from mypc (192.168.5.3): icmp_seq=53 ttl=128 time=1.30 ms
[1719599788.369044] no answer yet for icmp_seq=54
[1719599788.473024] no answer yet for icmp_seq=55
[1719599788.577033] no answer yet for icmp_seq=56
[1719599788.685042] no answer yet for icmp_seq=57
[1719599788.687619] 64 bytes from mypc (192.168.5.3): icmp_seq=58 ttl=128 time=2.29 ms
[1719599788.787597] 64 bytes from mypc (192.168.5.3): icmp_seq=59 ttl=128 time=1.56 ms
...
That sounds like a "specific issue at play in your environment" - it is not normal for a client to entirely lose networking because of a lease renewal.
I replicated your test here, 0 pings dropped, even with 10 pings/second.
…
64 bytes from 192.168.1.68: icmp_seq=121 ttl=128 time=3.52 ms
64 bytes from 192.168.1.68: icmp_seq=122 ttl=128 time=0.898 ms
64 bytes from 192.168.1.68: icmp_seq=123 ttl=128 time=1.12 ms
64 bytes from 192.168.1.68: icmp_seq=124 ttl=128 time=0.930 ms
^C
--- 192.168.1.68 ping statistics ---
124 packets transmitted, 124 received, 0% packet loss, time 12357ms
rtt min/avg/max/mdev = 0.898/1.422/5.292/0.700 ms