• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1454
  • Last Modified:

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.appliedperformance.com      192.168.0.100, 67, LAN      IP=192.168.0.121, HostName: NOMAD tunnel=GroupVPN
31:10.5      ICMP packet from LAN allowed      192.168.0.10, 512, LAN, aptdomain.internal.appliedperformance.com      192.168.0.121, 8, WAN      ICMP Ping, Code: 0
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.appliedperformance.com      192.168.0.100, 67, LAN      IP=0.0.0.0, HostName: NOMAD tunnel=GroupVPN
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.appliedperformance.com      192.168.0.100, 67, LAN      IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
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.appliedperformance.com      192.168.0.100, 67, LAN      IP=0.0.0.0, HostName: TOSHLAP-WIN7 tunnel=GroupVPN
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?
0
Wade_Chestnut
Asked:
Wade_Chestnut
  • 4
  • 3
1 Solution
 
ziaic1Commented:
Sniff on Toshlap and see if the offer ever makes it from the DHCP server back to the client.
0
 
digitapCommented:
something you might want to consider, have the sonicwall handle DHCP for your GVC users.  i've had challenges with DHCP management from Windows servers for GVC users.  since i was already using the WLAN zone to hand out IP to wireless hosts, i merely configured DHCP over VPN to use the WLAN DHCP server to hand out IP to GVC users.

what do you think of that?
0
 
Wade_ChestnutAuthor Commented:
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.
0
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
digitapCommented:
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.
0
 
Wade_ChestnutAuthor Commented:
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?
0
 
digitapCommented:
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.
0
 
Wade_ChestnutAuthor Commented:
Yeah, I appreciate your suggestion but I think we'll just live with the second DHCP server and document it.  Thanks, again!
0
 
digitapCommented:
You bet!  Also, thanks for the points!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now