intertwingly

The funny thing is that the Mac OS X Network Preference Pane allows you to set MTU for Ethernet connections graphically, but not VPN.

I’m surprised you didn’t have to do this sooner, I had to make this change months ago. What ISP?

There are a number of parts to this problem:

• the standard ethernet MTU is 1500 bytes, which is slightly larger than an ADSL frame
• modern operating systems don’t like to fragment packets because it reduces performance.  Instead, they set the “don’t fragment” flag, and wait for errors if the packets are too big.  If they get an error, they send smaller packets til they make it all the way.
• it seems that a lot of DSL modems (or maybe DSL networks) happily accept and discard large packets without sending an error message back to the original sender.

To make things more complicated, with some VPN software you end up having to pick an MTU manually such that the maximum packet size plus the VPN headers plus the TCP/IP headers will fit inside an ADSL frame, which is not easy to do.

As far as I can tell, the root problem is the DSL network or modem accepting packets that it can not possibly transmit without an error.

A problem that I’ve seen is firewalls dropping incoming ICMP type 3/code 4 errors.  This breaks Path MTU discovery, so the IPSEC headers push the packet size over the maximum MTU, and the packets get lost silently.

I found that our ADSL router dropped these ICMP errors by default.

BTW - Robert Graham’s excellent Firewall Forensics FAQ describes MTU problems well:
[link]

Or, at least it did do, until it dropped off the web some time ago.  It is still available via archive.org though.

I’ve now seen an alternate suggestion:

iptables -A INPUT  -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400 
iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400