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!