sl2tps, MRU, MTU, and MSS

[Brian Candler]

On Fri, Jan 27, 2006 at 08:39:41AM -0600, Archie Cobbs wrote:
> Brian Candler wrote:
> >>1. PPP negotiates an MRU of 1400
> >>2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?)
> >>3. When the client opens a TCP connection, it offers an MSS of 1360
> >
> >...and then fragmentation problems occur, because the remote server sends 
> >IP
> >datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU
> >1376 rejects them, the generated ICMP messages are discarded by an
> >intervening NAT gateway, and the TCP connection fails.
> 
> Sounds like the NAT gateway is the root cause of all this, no?
> 
> While all the MTU logic in slt2ps is probably not optimal, in theory
> it shouldn't matter if it's not optimal because ICMP should be working.
> A router is supposed to be able to reduce the MTU if it needs to and
> things should continue to work.
> 
> Instead of "fixing" sl2ps to work in your particular situation (and
> breaking it in other situations), is it possible to fix/replace the
> broken gateway instead? (Try a FreeBSD box instead :-)

It's a PIX. Perhaps I should draw out the test scenario properly just to
make sure all is clear:


              fxp0             rl0         RFC1918          pub
  Win ------------ FreeBSD 6.0 -------//---------- firewall ---- Internet
   XP              + ipsec-tools                     PIX
                   + sl2tps
     <============>
        L2TP over
         IPSEC

The FreeBSD box runs pf NAT, in order for the IP address given out from the
sl2tps pool to be usable. The rl0 address is from private address space, as
it hangs on an office network. The PIX firewall also runs NAT to give
external connectivity.

When I bring up the tunnel, LCP negotiates an MRU of 1400. The Windows box
is happy with this, and therefore chooses a TCP MSS of 1360 for outbound
connections.

FreeBSD configures its ng0 interface with an MTU of 1376. Even if this is
technically allowed, because path MTU discovery should take care of it, it's
certainly suboptimal, since we *could* send datagrams with an MTU of 1400
over the negotiated tunnel.

Although I understand your argument that the PIX is broken, there are also
parts of the Internet which wrongly block ICMP fragmentation-needed
messages. Unfortunately, fixing the whole Internet is outside of my power.
However I'm happy to rely on the vast majority of the Internet supporting an
MTU of 1500, and for the last hop to be lower than this since the
originating socket will directly set the initial MSS to an appropriate
value.

> Some background as best as I can remember...
> 
> The reduction of MTU to account for PPP protocol overhead (MPPE) is
> not controversial. Obviously if the hard MTU is (say) 1400 and you've
> got 4 bytes of MPPE overhead, then the interface MTU should be <= 1396.
> 
> You're right that this shouldn't really happen unless MPPE is actually
> negotiated, but that's harder to do.. MPPE negotiation happens after
> link negotiation. To avoid this, disable MPPE if you can.

OK. I already changed sl2tps not to allow MPPE. I guess an option in
config.xml would be better.

> The WinXP hack is something that at some time was deemed necessary to
> work around a bug in Windows XP. As I recall, it would advertise a MRU
> that was actually bigger than what it would really accept. Since there
> was no easy way to detect WinXP clients, we had to put in this workaround
> unconditionally. This may have only been a bug in pre-SP2 WinXP. It
> was (IIRC) when trying to do L2TP over IPSec, not PPTP.

To paraphrase your words: instead of "fixing" sl2tps to work in this
particular situation, is it possible to fix/replace the broken WinXP box
instead? :-)

The WinXP box I'm using is running SP2, and doesn't seem to have the bug you
describe. Since SP2 has been out for a long time, perhaps it would now be
reasonable to drop this workaround, or to make it a compile-in option. In
any case, I think pre-SP2 XP has other problems with IPSEC, so any serious
XP user should be upgrading to SP2 anyway.

Besides which, any PPP implementation which announces an MRU of X but then
refuses to receive packets of size X is so totally broken that it defeats
the object of PPP option negotiation in the first place.

Cheers, and thanks for your quick response,

Brian.