Another networking lesson

[HCHTech]

I have a small construction business customer. They are out in the sticks a bit, so DSL is their only option. They have a an SBS2011 server and a small Sonicwall. The symptom that generated the call was an inability to get into their payroll website. Other sites worked fine, but the payroll site wouldn't load in any browser - They could go through the login process, but the site would just timeout and you'd get the browser's "check your networking" message.

Everything was working fine until Friday. I couldn't get out there until today, but I had them try a few things, reboot equipment, flush DNS, reset networking, using a public DNS, that kind of stuff. We also found some other sites that wouldn't load - for example the CNN main site would load, but the "Money" site woudn't. This was across all of their computers. I did note that the site would still not load using the IP address, so the problem wasn't DNS.

I remoted in and checked the Sonicwall, rebooted it, upgraded the firmware, nothing helped. They called their DSL vendor and of course - they said their connection was fine. I somehow talked them through configuring a laptop for the PPPoE connection to test things outside of the Sonicwall, and sure enough - all sites loaded fine. Rats - I was hoping to find out it was really their fault.

I tried disabling the various content and packet filtering, but no change. It was getting late and I was getting a headache from all of this so I told him I would come onsite with a replacement firewall today. Their unit would be 5 years old in June, so maybe it's time for a new one anyway.

In the middle of dinner with friends on Saturday, it finally dawns on me that I should test changing the MTU value of the WAN connection.

I go out this morning and sure enough, lowering the MTU value from 1500 (which worked just fine for the 4-and-a-half years that Firewall had been there) to 1492 solved the problem. Now why couldn't I have thought of that in the first place?

So anyway, I thought I'd go through the steps to find the maximum MTU value for a connection in case someone else might benefit.

Pick a website and run a ping as follows:

Ping www.xxxxxxx.com -f -l 1500

-f means "don't fragment the packet". -l 1500 means "use a send buffer of 1500"

Look at the results. If you get "Packet needs to be fragmented but DF set", then you need to decrease the buffer size. If you get normal ping result, then you need to increase the buffer size.

Run the command again either decreasing or increasing the buffer size. You are looking for the maximum buffer size that does not return the "needs to be fragmented" message.

Once you find the maximum buffer size that doesn't fragment, add 28 to this number to account for the packet header and this is your correct MTU value. Adjust the MTU to equal this number in your modem/router/firewall.

I had known about this whole process as a way to optimize your connection, but hadn't really used it much in several years. I certainly didn't have it at the ready for a solution to the "some sites don't load" problem.

I would also note that this whole problem must have come about because the DSL vendor changed something about their connection that resulted in the requirement for a lower MTU setting. You would think tech support might have mentioned that when they called!

I hope this helps someone!

 

[YeOldeStonecat]

Ahhh....MTU. I got to learning about that from the owner of Speedguide.net (which I was staff at).

For what it's worth, back when Windows 95 was the norm, and I had a large healthcare client with multiple locations, I went and setup a WAN for them using Sonicwalls, this was my first experience with Sonicwalls, the old SOHO3 models.

Fought with some VPN tunnels for a long time, couldn't get them to connect, even had Sonicwall support stumped...saying it wouldn't work over DSL. //scratches head

Rang up a colleague of mine from Speedguide that dealt with Sonicwalls a lot, and he went right in and adjusted the MTU on it. PPPoE DSL should be 1492, as you found out.
ATM DSL, cable, and T's...1500.

At this point I was fresh at Speedguide.net, new about tweaking computers with Philips SG TCP Optimizer tool, but didn't know about the setting on some routers yet (back then the Linksys BEFSR41 routers were the norm, and Netgear RT312. Early versions of firmware back then often didn't have MTU settings on them...yet.

In theory, routers often have the "Automatic" setting for MTU, but....as some of us learn, "automatic" doesn't always work. Sometimes you have to manually specify it.

 

[putz]

This was common with PPPoE connections and Sonicwall a few years back, not sure if they ever optimized this by default since I haven't had any new recent customers that have PPPoE DSL. But we have had to adjust the MTU on almost every Sonicwall device we have deployed on a PPPoE connection in the past, even if the hardware it was replacing never seemed to have any issues. I think some devices automatically reduce the MTU size when you set the connection type to PPPoE even though they might not specifically say they do. We typically follow this to find the optimal MTU size for the connection which is pretty much identical to what you noted in your post:

https://support.sonicwall.com/kb/sw3557

 

[ZenTree]

I thought MTU as soon as I read it but that's only because when I worked for an ISP we spent forever with a customer and their IT support who were insistent everything was set up correctly their end and the issue was with our stuff and it turned out to be this. It's burned into my troubleshooting now. Kudos on the fix, easily overlooked.

 

[HCHTech]

It's burned into my troubleshooting now.

Yes - for sure. I made an evernote for my techs, I've adjusted our "How to setup a Sonicwall procedure", and I got a whiff of scorched grey matter myself - I don't think I'll forget this one for a while - haha. Plus, this is one of those "magic" fixes where such a tiny adjustment of an arcane setting cures a huge problem. The NEXT time this happens, I'll look like a genius!