[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 709
  • Last Modified:

VPN to Sonicwall dies when Wireless in use

We have an office (1 of 20) that has a site-to-site VPN to our corporate HQ (like all offices do).  The office has a Sonicwall TX170 (like all offices do) and HQ has a Sonicwall pro 2040.  For the last few weeks, the office VPN has been working intermittently.  It was working fine for many months before that.  No recent changes have been made to either Sonicwall that we know if.  After some troubleshooting, we found that if we disable the wireless on the office Sonicwall, then the VPN is stable.  But our offices need the wireless connectivity.

We've tried playing with the advanced wireless settings DTIM Interval, RTS Threshold, Fragmentation Threshold, etc. with no luck.  But we are not real clear on what those settings should be or if they would help in this situation.

Help!
0
okacs
Asked:
okacs
  • 24
  • 18
1 Solution
 
digitapCommented:
Here are some initial questions:

-Are you running the latest firmware on the TZ170?
-How long does it take before the p2p vpn fails?
-When the vpn fails, what is the log telling you about the VPN?
-Are you running enhanced on the SW?
-Is your wireless network on a different IP network from your LAN or IP networks on the other side of the VPN?
-How many clients are at this site?

Do you think they've outgrown the Sonicwall and need a new model?
0
 
okacsAuthor Commented:
-Are you running the latest firmware on the TZ170?
          No.  We don't currently have an active support subscription, so an updated firmware would be $$$

-How long does it take before the p2p vpn fails?
          Just a few seconds.

-When the vpn fails, what is the log telling you about the VPN?
          Nothing in the logs.
 
-Are you running enhanced on the SW?
          No.  WE are running the Standard OS on this office SW.

-Is your wireless network on a different IP network from your LAN or IP networks on the other side of the VPN?
          Sonicwall OS requires that the LAN and WLAN be on different subnets, so yes.

-How many clients are at this site?
          About 4.

Do you think they've outgrown the Sonicwall and need a new model?
          No.  
0
 
digitapCommented:
Without an update to the OS on the sonicwall, I don't know where to start.  I agree that it doesn't sound like you've outgrown your appliance.  Have you tried deleting the SA for the p2p back to HQ and recreating it?
0
Firewall Management 201 with Professor Wool

In this whiteboard video, Professor Wool highlights the challenges, benefits and trade-offs of utilizing zero-touch automation for security policy change management. Watch and Learn!

 
okacsAuthor Commented:
Yes, we've deleted the SA on both ends and recreated from scratch more than once.
0
 
digitapCommented:
If the log doesn't show anything and the SA has been deleted, I'm defaulting to the update which, as you say, you are not eligible for.  By the way, what version IS the sonicwall on currently?
0
 
okacsAuthor Commented:
Firmware Version:        SonicOS Standard 3.8.0.1-27s
ROM Version:                SonicROM 4.0.1.1
0
 
okacsAuthor Commented:
And no, there's nothing of any apparent use in the logs.  Just a lot of repeated but very brief TCP messages.  They have source & dest IP and ports, but no descriptive info. examples:

VPN TCP PSH
VPN TCP SYN
VPN TCP FIN

My understanding is that these are normal log entries; ie: just 'chatter' between the two nodes.
0
 
digitapCommented:
Interesting.  The latest version for the TZ170W Standard OS is in the screen shot.  I'm not sure how you have the version you indicated above.

Do you have the logs set to debug?
greenshot-2010-04-06-16-13-46.jpg
0
 
okacsAuthor Commented:
Ah, good point.  The OS has not been updated since we bought the unit, but this unit is a TZ180w std, not a TZ170w std!
0
 
digitapCommented:
OK...it looks like the last release for the 180 was 2008!  Did you check if the logs were set to debug?
greenshot-2010-04-06-16-29-43.jpg
0
 
okacsAuthor Commented:

Yes, the TZ180 series was replaced by the TX190 series wasn't it?

Yes, Debug is already enabled in the logging.

0
 
okacsAuthor Commented:
I might mention that this office also has a site-to-site VPN to another office and *THAT* VPN seems stable.  (though they are not really using it currently, so maybe it isn't?)  The HQ also has about 30 other site-to-site VPNs to all the offices and some other places, and they are all stable as well.

They will start using the VPN to the other office as of tomorrow, (and using the VPN to HQ less)  so we'll see...
0
 
digitapCommented:
I looked through the subsequent releases and I don't see where this is an issue.  I've seen vendors fix bugs that were not reported in the release logs.  Did you check the diag.hml screen?  After you login to the sonicwall, type in the address bar, https://sonicwallip/diag.html.  Maybe there's something there.
0
 
okacsAuthor Commented:

I've looked though the diag page and didn't see anything that looked particularly relevant.

The issues are still occurring as of this AM.  :(
0
 
digitapCommented:
Does the Pro 2040 manage any Sonicpoints?  Did you change the default IP of the WLAN on the TZ180?
0
 
okacsAuthor Commented:

No, we have no sonic points.  No, the WLAN IP and subnet has not changed since it was installed (but it is not the default either)  This unit was running fine for many months and then suddenly developed an allergy to working...
0
 
digitapCommented:
I'm out of ideas at this point.  It's quite possible that the Sonicwall has failed.  Perhaps someone else might have an idea.  Actually, have you tried just resetting thing back to factory defaults and configuring it from scratch?
0
 
okacsAuthor Commented:
Not yet.  But I'm tempted.  Taking down an remote office requires someone being there to assist - and the boss isn't gonna fly me to Arizona for this.  :)  So I gotta take it down during the day when the office manager is there...
0
 
digitapCommented:
I know that scenario so well.  Users just LOVE us when we do thing like that.
0
 
okacsAuthor Commented:
heh
0
 
okacsAuthor Commented:
OK, last night the problem got worse.  THe VPN was all green lights, but they could not access ANYTHING over the VPN even when wireless was not in use.  It was just dead.  I played with it for about 2 hours and could not get it working.  I noticed that it was having licensing issues - a 101 error, meaning that there were DNS issues - despite change the DNS settings repeatedly.

This morning we reset the unit to factory default & set it back up from scratch.  The unit came up all green again.  The licensing and DNS issues are gone.  But they STILL cant access any apps over the VPN to the HQ.  The 2nd VPN (the one to the other office) came up and works just fine.

I'm about to pull my hair out!
0
 
okacsAuthor Commented:
Ok, I noticed that there were some log entries with the error "Received notify: INVALID_ID_INFO" so I set the VPN to "main mode" on both ends and save it.  (didn't come up, but I expected that).  Then I changed it back to aggressive mode, and the VPN came up, and they can now access apps at the HQ.  Whah-la!

The question is... Is it fixed now, or are we back to just having INTERMITTENT problems like se started with?!?  Sheesh...  I guess we'll just have to wait and see.
0
 
okacsAuthor Commented:
Ok, Oddly enough, the hardwired PCs can access the apps over the VPN, but not the wireless PCs.  Yes, I've got the VPN SA object set to terminate at "LAN/WLAN" and I've disabled "require WiFiSEC for S-2-S VPN traversal" as well as checking "trust WPA as WiFiSec".  We've also done a ipconfig /flushdns and then rebooted the wireless PCs.

0
 
digitapCommented:
Agressive mode typically used when you have dhcp at one end.  Also, the IPSec packet size is smaller with aggressive mode than main mode.  Main mode is still valid.  When you change the settings on the VPN SA, you're merely causing it to renegotiate.  You can disable the VPN and re-enable it to get the same results.  Do you have static IP addresses at both ends on the WAN interface.  If you do, then main mode should have worked without issues.

What wireless clients are your users utilizing to connect to wireless access points?  Intel, Windows, Dell?

0
 
okacsAuthor Commented:
No, one is static and the other is DHCP.  We use Dell PCs, not sure about the NICs or wNICs in them...

No further changes made, but the Wireless PCs just suddenly started working.  About 30 minutes after the VPN SA negotiated! And they have been working ever since.

I guess we'll have to wait & see if their connection stays up or continues to drop intermittently like earlier this week.
0
 
okacsAuthor Commented:
Just re-read though all these posts and realized that I never wrote anything about the DSL connection.  I found out late yesterday that this office uses DSL instead of a Cable Modem like all out other offices have.  We had a similar (but not identical) problem a while back, and it was DSL related.  When we switched them to a cable modem, everything worked fine & was stable - with no changes to the Sonicwall config.  If todays changes don't work, then we are considering switching to cable...

Going to go Google DSL vs VPN now.... anyone else have experience with DSL killing a VPN?
0
 
digitapCommented:
It's puzzling why it's only affecting the WLAN hosts.  You might try changing the MTU of the WAN interface.  I've seen this with cable modems, but it could affect a DSL connection.  Go to a host and type the following in a command line:

ping -f -l 1500 www.google.com

I think the default might be 1500.  You may get a response to the ping of, "Packet needs to be fragmented but DF set."  Decrease 1500 by 8 and try the ping again.  Continued to decrease subsequent pings by 8 until you get a ping reply.  Whatever number you end up on, use that number as your MTU.
0
 
okacsAuthor Commented:
I did the ping test.  Lowered it to 1460 until the tests came through reliably.  The VPN is still not working correctly.
0
 
digitapCommented:
I'm out of ideas.  At this point, I'd contact support.  I know you said you don't have support.
0
 
okacsAuthor Commented:
I double-checked the office's VPN this morning.  Everything is working fine.  It stayed up over the weekend. (gasp).  Given that it's average uptime has been less than 3 hours, this is good news.  Continuing to monitor it...
0
 
digitapCommented:
Very bizarre...the last thing I see you did was to lower the MTU, but you indicated that did resolve anything.
0
 
okacsAuthor Commented:
It didnt.  We had several issues after that.  Since my last post last week, I also looked at the DSL modem settings.  Only thing I changed was enabling then disabling the "Enable IPSec" setting which lets the DSL modem host it's own VPN sessions.  (so no change)  Other than that, all I did was more of the same as before... reboot DSL & Sonicwall, bounce the tunnels, etc.
0
 
digitapCommented:
Is the DSL modem not running in transparent mode?
0
 
okacsAuthor Commented:
No.  It has an "IP Passthrough" mode but it is not enabled.
0
 
digitapCommented:
What's the model of the DSL modem?  Knowing that, I'm betting that's where your issue lies.  Set the DSL modem to "transpartent" mode.
0
 
okacsAuthor Commented:
Maybe, but this unit was working fine for months.   Then again, I could say hte same thing about the sonicwall and VPN settings...

It is a Qwest Netopia model 3347-02 version QM01-7.74r10.

0
 
digitapCommented:
does the wan interface of the sw have a private or public ip..i forgot to ask.  in transparent mode the sw would have a public ip on the wan
0
 
okacsAuthor Commented:
Private - because transparent mode is off.
0
 
digitapCommented:
Well...I think that's your problem.  Change your DSL modem to transparent mode and configure your SW WAN interface with the public IP address.

This might a good place to start.

http://www.netopia.com/support/hardware/technotes/CQG_042.html
0
 
okacsAuthor Commented:
Oddly enough, the problem may have resolved itself.  We made no configuration changes to either the SonicWall or the DSL modem, but it has been up and stable since 4/17.  That's 10 days of up-time when we were lucky to get 10 minutes before...  very odd.  (knocking on wood).  I don't know if I should close out this question or keep it open....
0
 
okacsAuthor Commented:
I think this would have worked or at least helped tremendously if the problem hadn't self-resolved.  In either case, your assistance is very much appreciated.  Thanks!
0
 
digitapCommented:
I've seen this with your specific configuration.  It will work for some time, then not work.  Or, you'll see performance hits.  If it happens again, I'd say put your DSL router into transparent mode.  Some times you can configure the DSL router in transparent mode and perform PPPoE giving your SW a public IP address.  Sometimes, you put the DSL router in transparent mode, give your SW a public IP address AND perform PPPoE.

You've close this ticket and awarded points.  If the issue comes up again or you have any other questions, just post on your question.
0

Featured Post

The Firewall Audit Checklist

Preparing for a firewall audit today is almost impossible.
AlgoSec, together with some of the largest global organizations and auditors, has created a checklist to follow when preparing for your firewall audit. Simplify risk mitigation while staying compliant all of the time!

  • 24
  • 18
Tackle projects and never again get stuck behind a technical roadblock.
Join Now