Date: Fri, 27 Jan 2006 10:39:08 -0600 From: Archie Cobbs <archie@dellroad.org> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS Message-ID: <43DA4CAC.3070906@dellroad.org> In-Reply-To: <20060127155649.GA60799@uk.tiscali.com> References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
First of all, let's be clear about terminology.. there are two different
MRU's negoatiated in opposite directions and those negoations are done
independently. The problem, which is basically "the FreeBSD->WinXP MTU
is causing a PIX-bug-triggering MSS in the WinXP->FreeBSD direction"
arises because:
- WinXP sets its MSS (which applies to data flowing in the FreeBSD->WinXP
direction) based on the MTU that it sees (which applies to the
WinXP->FreeBSD direction). This is a heuristic "guess" made by the
TCP stack, based on the assumption that the link is MTU-symmetrical.
- This "guess" is wrong and because of path-MTU problems can't be
corrected.
In any case, in the FreeBSD -> WinXP direction, you say we could send 1400
byte packets out the ng0 interface, but this is not necessarily true. What
is the MRU that the WinXP machine asked for? If it's 1400, then the ng0
interface must definitely be < 1400, because of PPP overhead (e.g., IPCP).
The 1400 negiotiated by LCP applies to PPP frame payload, not IP size.
Seems like the proper workaround would be to configure sl2tps to negotiate
a smaller MRU (WinXP->FreeBSD direction) than 1400. There's no config
knob for this but one could be added. Then WinXP would "guess" better.
> 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.
You can remove that hack, but the hack is not the reason for the failure
so to speak. It just happens to trigger the problem (which occurs elsewhere).
The hack itself should probably be turned into a config knob too.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43DA4CAC.3070906>