Global VPN Client issues - Windows DHCP server filling up with BAD_ADDRESS
NoMax
Newbie ✭
We have been experiencing issues with our Global VPN client users for some time now and I have not been able to find a resolution to the problem. Here is a description of what is happening. We have 2 SonicWall NSA 2600s in HA mode,
A user is working from home using the global VPN client. Instead of shutting down their PC when they are finished working, they just close the lid or let the compuer enter sleep mode. When they come into the office and wake their PC the VPN client will still be running. If you look at the VPN client on their PC it will be stuck on "Authenticating".
What happens in this scenario is all the unused DHCP addresses on our Windows DHCP server will be taken up with BAD_ADDRESS coming from this client with the VPN active. I can go into Wireshark to see the DHCP Deny entries and find the MAC address of the PC who is running the VPN client while in the office. The BAD_ADDRESS entries will continue to be generated until the entire range of DHCP addresses is exhausted.
Windows DHCP Server BAD_ADDRESS:
Wireshark DHCP Deny example:
The DHCP server handling the requests for the Global VPN client is the SonicWall and the network is 192.168.13.0 /24
The DPCP server handling the requests for the on-site Office network is WIndows Server 2016 and the network is 192.168.3.0/24
There is no overlap of networks serveved by the 2 DHCP servers. I have had several tickets open with SonicWall support and so far thay have not been able to resolve the issue. I am hoping someone here can provide some insight.
Thank you in advance for any suggestions you may have.
Answers
Hi @ NoMax, what interface is 192.168.13.0 assigned to on the SW, and what Interface is 192.168.3.0 assigned to SW?
192.168.3.0 is assigned to X0, 192.168.13.0 is not assigned to a separate interface, it's just using the internal DHCP server of the SonicWall and then linked to X0
Hi @NoMax , try as my answer in the below ( don't set the Virtual Adapter to None as in the example though, leave as DHCP)
it should then force the GVPN Client to connect to the WAN IP from inside without looking internally for DHCP
https://community.sonicwall.com/technology-and-support/discussion/3303/can-a-gvc-vpn-be-tested-from-behind-the-firewall
Hi @NoMax - did you ever figure this out or try the workaround from @preston? We're having the same problem with TZ series devices.
Same problem here. Lucking I can track down the MAC address and let the person know to turn off the VPN