VPN Occasionally Drops When Connected to SonicWALL T170

The SonicWALL T170 serves as our corporate firewall. We allow VPN for only a few people in order to provide remote technical support via Windows Remote Desktop. We use both Macs and Windows PCs at home using Bell ADSL highspeed to connect to the office and from time to time the VPN connection drops so we knew there was a problem at the corporate side and not at our homes as everyone experiences this problem. The office uses a Bell Dedicated Full T1 and it is not heavily used so it is practically un-used afterhours meaning that there is likely not a bandwidth issue. Furthermore I had our ISP test the line from the CO to their router in our computer room and there was no packet loss. We therefore narrowed the problem down to our SonicWALL. We ran internal tests using "ping -f -l 1500 www.yahoo.com" and "ping -f -l 1500 www.google.com" to see if we had a MTU setting problem. The sweet spot was 1340 which is where packet loss went from 100% to 0%.

We checked the SonicWALL settings and it was already set with a MTU size of 1372, a checkmark in "Fragment non-VPN outbound packets larger than WAN MTU", and a checkmark in "Ignore DF (Don't Fragment) Bit". When we changed this from 1372 to 1340 the same ping tests now reported 100% packet loss at 1340 and only went to 0% at 1308. This was very wierd and I noticed a pattern. At the 1372 setting 0% packet loss occured at 32-bytes less, that is 1340. When we changed the setting to 1340 the 0% packet loss then occurred 32-bytes less than the setting again. Wierd, or a clue??

In an event I am not sure if playing with the MTU settings is even the right resolution to the problem, and if it is then what the optimal setting should be and why does the ping test using the new value fail afterwards and only work for 32-bytes less than the setting. The default MTU setting for a SonicWALL is supposed to be 1500 so we think that a past support staff person changed this at some point to 1372. Help!
BeerTimeAsked:
Who is Participating?
 
rharland2009Commented:
Do you have control over the MTU size on the device to which your SonicWall connects on the WAN side? Those should match in a perfect world. Ask your ISP to verify the MTU size on the ethernet handoff they give to you. Get them to match and then run your tests.

 
0
 
BeerTimeAuthor Commented:
I only have control over managing the MTU size on the SonicWALL. The ISP keeps a Cisco 1800 router in our computer room that connects to our SonicWALL and only they can manage that device. I will put in a service call for them to check and let me know what their settings are. Thanks.
0
 
rharland2009Commented:
Sounds like a plan. I would start by having them set the MTU on their side to line up with your Sonicwall.
While you're at it, just make sure the SW ethernet port and the 1800 handoff port are configured physically alike, either hard-code it at 100/full or make sure they're both set to auto-negotiate.


0
IT Degree with Certifications Included

Aspire to become a network administrator, network security analyst, or computer and information systems manager? Make the most of your experience as an IT professional by earning your B.S. in Network Operations and Security.

 
BeerTimeAuthor Commented:
I just got off the line with our ISP. Their router was set to Auto (running at 100/Full) with an MTU of 1500. Our SonicWALL was also set to Auto but running at 100/Full. Our MTU (as mentioned before) was set down to 1340. We both hard-coded to 100/Full and I bumped our MTU back to 1500. I guess time will tell now if this did the trick. I'll report back after some testing from home.  Thank you.
0
 
BeerTimeAuthor Commented:
Sorry, I meant to say we were running Auto at 100/half (not full), but they had not seen any collisions.
0
 
rharland2009Commented:
Cool....100/full is good. If you want to test connectivity/bandwidth machine-to-machine during off-hours (and I'm assuming these are PCs) you can set up iperf. I've used it for link-saturation testing among other things and it works like a charm. You'll either need to do this inside the VPN tunnel or use endpoints with public IP addresses (or at least NAT mappings). This is just a traffic generator, so you might still need another app if you want to poll the ports for throughput numbers/errors/etc.

Check it out here:

http://sourceforge.net/projects/iperf/


0
 
BeerTimeAuthor Commented:
I think it worked! I stress tested by trying to open my Outlook locally to connect to Exchange over the VPN which never worked.....but now it does! No problems. Windows Remote Desktop over VPN appears stable too. When I get a chance I'll check out the tool you suggested. Thank you!
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.