Problems related to mismatches with the Maximum Transmission Unit and VPNs can be difficult to troubleshoot. Troubleshooting efforts are hampered by the somewhat obscure and convoluted machinations a given host uses to figure out exactly is the largest packet it can transmit. This is partly because all operating systems don't behave exactly the same way, and partly because it takes some effort to comprehend how it's supposed to work, and potentially a lot of effort to figure out exactly what's wrong when it's not working.
As it relates to VPN users, the issue is often the additional bytes used when headers are applied by the tunneling protocol. Subsequent fragments may be blocked by a firewall and the ICMP messages instructing the client about acceptable packet sizes are then blocked by the client's firewall, creating some havoc.
But, these issues are not unique to VPN users. In fact, there is a loosely related website devoted to the MSS (Maximum Segment Size) Initiative, which seeks to solve these black holes. It can be found at http://home.earthlink.net/~jaymzh666/mss/index.html.
Another piece of interesting reading is the suggestions for Path MTU Discovery in RFC 2923, which can be found at http://www.faqs.org/rfcs/rfc2923.html.
Although most administrators have already implemented "fixes" like lowering MSS values to compensate for headers, you should also strongly consider a more granular approach to filtering ICMP. Specifically, don't block ICMP type 3. Many firewalls and even desktop firewalls like Symantec's Desktop Firewall have rules that allow ICMP type 3 by default, but these rules are often changed by well-intentioned administrators who are concerned about the general number of exploits that involve ICMP.
Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.
