There are a couple of reasons for this, and let’s review…
First of all, altering the MTU to a size lower than the default 1500 is usually only needed when you’re WAN Connection is using PPPoE. In those cases, you’ll need a smaller MTU, typically 1492 works fine, but any multiple of 8 works fine. In this case, it was 1452. So why does this happen. There is overhead assoicated with PPPoE which consumes typically 8 bytes. However with the Sonicwall set at 1500 when it conencts to another server, such as a website, it will negotiate a connection speed of 1500. When the packet passes through it fragments and depending on the routers along the path, it may drop any packets larget than 1500 instead of fragment them. The end result, is an incomplete transmission. Now TCP/IP is a bit smarter than to just leave it there… It sends an ICMP packet back to the source server and tells it to lower the MTU size. However a lot of web servers, and other servers for that matter, block inbound ICMP packets, and thus, the server never lowers the MTU tranmission size from 1500 to something lower, resulting in persistant problems.
However, as you can imagine, the firewall and security of the source servers will be different so you will have inconsistant results, not an “across the board” type problem. So for this reason, please keep in mind how MTU relates to DSL connections, specifically when they use PPPoE. Simple DNF (do-not-fragment) ping test can really help you figure out the correct MTU size.
For more information, please see the following resource at Cisco.com: Troubleshooting MTU Size in PPPoE Dialin Connectivity