SonicWall Global VPN Client and Windows DHCP Server
We have a SonicWall TZ 170 with DHCP turned off. I have 2 laptops with near-identical configuration: Windows 7, Windows Firewall off, both with Global VPN Client 4.2.6.0305, both connecting to the same Wireless Access Point (Public IP sitting outside SonicWall), same adapter and client settings, same VPN Policy. One computer can receive an IP address from our Windows Server via DHCP (NOMAD), one cannot (TOSHLAP-WIN7). Here's a dump of the logs during each computer's DHCP requests:
31:10.5 DHCP lease relayed to remote device 192.168.0.10, 67, LAN, aptdomain.internal.applied
31:10.5 ICMP packet from LAN allowed 192.168.0.10, 512, LAN, aptdomain.internal.applied
31:10.5 DHCP REQUEST received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=192.168.0.121, HostName: NOMAD tunnel=GroupVPN
31:10.5 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
31:09.1 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: NOMAD tunnel=GroupVPN
35:03.9 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
35:03.9 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
35:02.0 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
35:00.9 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
SonicWall's IP: 192.168.0.100
DHCP Server: 192.168.0.10
Without knowing the fine details to DHCP handshaking, I noticed the one that fails never receives a DHCP REQUEST from the server for some reason. Any ideas why?
31:10.5 DHCP lease relayed to remote device 192.168.0.10, 67, LAN, aptdomain.internal.applied
31:10.5 ICMP packet from LAN allowed 192.168.0.10, 512, LAN, aptdomain.internal.applied
31:10.5 DHCP REQUEST received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=192.168.0.121, HostName: NOMAD tunnel=GroupVPN
31:10.5 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
31:09.1 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: NOMAD tunnel=GroupVPN
35:03.9 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
35:03.9 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
35:02.0 DHCP OFFER received from server 192.168.0.10, 67, LAN, aptdomain.internal.applied
35:00.9 DHCP DISCOVER received from remote device 0.0.0.0, 68, WAN 255.255.255.255, 67, LAN IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
SonicWall's IP: 192.168.0.100
DHCP Server: 192.168.0.10
Without knowing the fine details to DHCP handshaking, I noticed the one that fails never receives a DHCP REQUEST from the server for some reason. Any ideas why?
Sniff on Toshlap and see if the offer ever makes it from the DHCP server back to the client.
ASKER CERTIFIED SOLUTION
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
ASKER
Unfortunately, that's what I think we're going to have to do. I've done some initial testing with the SonicWALL's DHCP server and it works pretty good. I don't like having to de-centralize a service, but we have to go with what works.
yes. those were my sentiments. although, i just thought of something else. what version of DHCP server you are using. i realized that conflict detection is set to 0 by default. you might consider increasing that and see if that resolves your IP allocation issue.
i'm running Windows 2008 DHCP. Start > Run > dhcpmgmt.msc and press enter. expand the dhcp server and right-click IPV4 then click Properties. Go to the Advanced tab and you'll see conflict detection. it should be set to 0.
if this works, you won't have to decentralize your DHCP service. let me know one way or the other.
i'm running Windows 2008 DHCP. Start > Run > dhcpmgmt.msc and press enter. expand the dhcp server and right-click IPV4 then click Properties. Go to the Advanced tab and you'll see conflict detection. it should be set to 0.
if this works, you won't have to decentralize your DHCP service. let me know one way or the other.
ASKER
Most of our servers are still 2003. The main DHCP server had 1 set for Conflict Detection Attempts.
You mentioned it should be set to 0 but also increasing it to see if it resolves the issue?
You mentioned it should be set to 0 but also increasing it to see if it resolves the issue?
no...the default is 0 and setting it higher might resolve your DHCP assignment issue within Windows.
either way, doesn't sound like that's the issue here.
either way, doesn't sound like that's the issue here.
ASKER
Yeah, I appreciate your suggestion but I think we'll just live with the second DHCP server and document it. Thanks, again!
You bet! Also, thanks for the points!