Menu

Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Sign In Register

SSL VPN connection breaks when DHCP client renews IP settings

rprrpr Newbie ✭
in SSL VPN

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?

Category: SSL VPN
Reply

Best Answer

  • CORRECT ANSWER
    rprrpr Newbie ✭
    Answer ✓

    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.

Answers

  • ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    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.

  • rprrpr Newbie ✭

    @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:

    • On the Windows PC I started NetExtender GUI and established a SSL VPN connection. Then run the following command to renew the IP address of the Ethernet adapter: ipconfig /renew Ethernet
    • At the same time, on a Linux machine, which is in the same LAN with the Windows PC, I was pinging the Windows PC. At the moment the Windows PC was renewing its IP address, ping showed no answer for about 0.4 seconds:

    $ 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
    ...

    • The SSL VPN connection on the Windows PC disconnected at the moment of IP address renewal. Here is what I see in the NetExtender log:
    NetExtender_log.png

  • ArkwrightArkwright All-Knowing Sage ✭✭✭✭

    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

Sign In or Register to comment.