Link to home
Start Free TrialLog in
Avatar of saetaes

asked on

Sonicwall SOHO3 VPN Problems


I've tried posting this once to no goes again!

I have a SOHO3 with 10 Global VPN licenses; firmware is 6.5.04; using Global VPN Client 2.0.  I need to set up a VPN for remote users to access Intranet, Terminal Services, etc.  Because we are running Windows Server 2003 DHCP services, I would like to have the IP address assigned by the server, not the SonicWall.  Under DHCP over VPN, the SonicWall is set as a Central Gateway and "send DHCP requests to the server listed below" is configured to point at the W2K3 box.  In the VPN settings under client settings, I have selected "Use DHCP to obtain Virtual IP for this Connection."

Here's my problem - I can connect to the  firewall using the VPN client, but I cannot ping any internal addresses.  When I go to the Virtual IP settings, it has not received an IP from the DHCP server, and renewing eventually times out.  The Group VPN connection is reporting that packets have been sent and received, but I cannot (obviously) connect to internal addresses.  When I enable logging, I get the following message: "Failed to renew the IP address for the virtual interface. The semaphore timeout period has expired."

Anyone have any ideas?  This is extremely urgent, so I'm awarding 500 points to the first person to get me an up-and-running VPN!
Avatar of Tim Holman
Tim Holman
Flag of United Kingdom of Great Britain and Northern Ireland image

Do things work if you use SonicWall to assign DHCP addresses ?
Does the W2K 2003 event viewer show any attempt by the SonicWall to lease addresses ?
Avatar of saetaes


I haven't tried enabling DHCP from the SonicWall since this is a production firewall and we're using W2K3 DHCP services.  Nothing in the Event Viewer reflecting the SonicWall trying to get a lease.  I have also tried manually assigning an IP address and reconfiguring accordingly, and still have not had any luck getting to internal machines.  Do you have anything else I should try?
I'm not quite sure what the issue is yet, but you need to get it working using a manual IP address from your machine first.
Also make sure there are routes setup on your network so that your servers can get back to the VPN clients.  
These links should help get you started:

Client setup guide here:

Global VPN setup guide:

Advanced VPN setup guide:
I have been having the exact same problem with a Sonicwall TZ 170. I would be very interested in hearing if you have found a solution as I have tried everything but letting the firewall become the DHCP server.
I have just enabled the DHCP service in the Sonicwall with no joy. The client still does not receive a Virtual IP address. The Sonicwall reports a tunnel is connected but there is no connectivity to any hosts on the LAN.
Avatar of saetaes


Sounds like the exact problem I've had.  It's really a shame that these SonicWalls have this chronic VPN problem, because I will probably never buy another one because of it....
Saetaes, I'm in your exact situation as well.  What's interesting is that some users (less than 5) connect, all others cannot.  There are plenty addersses in the DHCP scope and remote users are not being blocked by personal firewalls (hardware or software).  Licensing is not an issue either.  A call to SonicWALL did not help either. If anyone has a fix, it would be greatly appreciated.
Avatar of pancho2004

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks panch02004. I got my VPN to work also by setting the NAT traversal to disabled. Why isn't this documented somewhere? I am quite disenchanted with Sonicwall. We bought a TZ 170 with unlimited nodes and the promise of an OS Enhanced upgrade. As soon as I registered the unit it resorted to a 10 node configuration. It took our reseller several days to get them to straighten out the problem and forget the OS upgrade, it isn't worth the battle. It seems that all the firewall appliance manufacturers have the same attitude, soak the customer. Next time I'll use the IPCop firewall.
All NAT-T does is encapsulate VPN traffic on port 4500 in order for it to traverse NATted firewalls.  For example, if one VPN server is behind a firewall using address translation, then your standard protocol 50 and 51 wll get dropped as firewalls generally only route TCP/UDP.
Knickers get twisted though as it's quite possible for one end to think it's doing NAT-T whereas the other end has already negotiated IKE over port 500.
General rule is make sure both ends are matched up, and protocols you don't want are disabled...
the solution suggested - to Disable NAT traversal will not always correct this problem. This option will work if you have a Linksys router with the very latest firmware which can support not only "IPSEC passthrough" but also UPnP. These capabilities allow for the Sonicwall Global VPN client to Automatically apply encapsulation to the NATed packets.
I also had and continue to have problems with IP address timeouts. The problem is not always consistent. Sonicwall just produced new Firmware v2.2 for their firewalls which supposedly addresses this problem. I now find the problem to be even more intermittent.Tonignt i had to reset my router - a SW3060 Pro.After that, I was not able to get IP addresses from my Windows NT server for 4 hours. Until at last in desperation i stopped and restarted the DHCP service on the NT server. Voila - it started to work again.
My issue is the same- however the traversal trick didn't fix it. My user is not sitting behind any hardware firewalls (so no NAT is happening- it has a public IP) and my SonicWall device is also first in line (public IP address). I am looking into other possible issues- but no luck for me. And the Sonicwall is the only device passing out DHCP- its been restarted so its not that. In fact other clients are not having a problem getting DHCP addresses through VPN- it is just one in particular. I have followed everything to the letter, but the SonicWall techs had to escalate my case.

Could it have something to do with the ISP- this is a former ATT cable/now Comcast user in Nantucket (and I'm in Santa Fe trying to troubleshoot- big fun)?
I also have this problem.  I have tried doing the Nat-T thing, but to no avail.  I'm still getting the semaphore timout error and no IP address.  My client (whom I'm trying to set this up for) got the exact same error while she was in a hotel in New York.  Now you'd THINK a hotel would be bright enough to open the correct ports so that clients could VPN back to the office, eh?

I'm going to call my client later and have them do the Nat-T switch and see if it helps them.  But honestly I'm pretty let down so far by this. I get a phase 1 ISAKMP error at home (behind a SOHO3 of my own using a WISP) and this semaphore error at work and at her location in New York.  That's 0 for 3 so far.  However, everytime I call Sonicwall, they buzz right in and get an IP with no trouble.  I'm beginning to think the problem here isn't my network(s), but the requirements of the client VPN system...

I 've used the SOHO3 in several installations and its a rock of a firewall for the price.  Plus I've had NO trouble with box to box VPNs, but this client VPN may be the death of me.
OK, I've had some help and managed to get this problem fixed.  From what I understand, Nat-T is used when you have one or more NAT networks between your client and firewall.  So I Forced ON Nat-T on the client and made a few tweaks to my Soho3.  It now works.  But I also hired a security expert to help me out too.

Here is a good MS article on the Nat-T subject:

I have taken the liberty of making screen shots of all of the relevant pages of my Soho3 and my Global Client software.  I have made them into a PDF file and placed it here:

I hope this helps.  The guy who helped me out did note that he didn't feel that the Sonicwal Nat-T solution was a little odd.  Here's what he said:
"I did a packet capture and when the NAT Traversal is enabled the VPN client only uses UDP port 500, which isn’t true to the standard. NAT-T is supposed to use UDP/500 for IKE and UDP/4500 for the data, but this seems to work OK even though it’s proprietary. Remember that whatever network you wind up plugged into, they must allow UDP/500 out or your VPN client won’t work."

If you give in like me and decide you need to PAY for support (the horror), might I recommend Security Volition.  They've helped me out more times than I can count.  Am I incompetent or are they really good?  A little from column A and little from column B on that one...

[company data removed - ee_ai_construct, cs admin]
It all comes down to two things: DNS and routing. Regarding the vpn giving an IP address to the client, I don't think it does, as I have done an ipconfig /all on my vpn connected system at home and it only shows my normal assigned IP (from my cable router). I had the problem where I couldn't communicate anywhere except the main site and it turned out to be routing. Check your subnets / masks too. I know not too much help, but my 2c worth if it can help at all.
I recently experienced the same problem and solution (thanks pancho2004) when a colleague started to use SonicWALL Global VPN Client from same location as me. Are using Windows XP SP2 behind a D-Link 624+ wifi access point. The SonicWall we are connection to is a TELES3 with DHCP enabled.
I just used this solution to fix an error in the GroupVPN connection that the log listed as: "Failed to renew IP address for the virtual interface.  The semaphore timeout period has expired."

Not sure about the firmware version on the Sonicwall box at work.  But the problem was directly traceable to recently installing an Airport Extreme Wireless base station at home.  I'm using it with an all Windows set of computers to take advantage of the Airport Express I got for Christmas. :)  

Connecting either wirelessly or wired through the Airport Extreme gave the error.  A direct connection to the cable modem worked.

But now with the configuration change in the GroupVPN client, I can connect fine.
I  had the same issue.  Went into the SOHO VPN Client settings and told it to assign virtual IP.  Worked like a champ
Hi to all,

Had same exact problem. Finally boiled down to the "Apply NAT and firewall rules " setting for the GroupVPN SA, under advanced settings. Turn it off and it might make your day.