From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 16:39:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B8E16A420 for ; Fri, 27 Jan 2006 16:39:10 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F35A43D6A for ; Fri, 27 Jan 2006 16:39:10 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from [10.3.2.11] (unknown [208.63.111.51]) by smtp-relay.omnis.com (Postfix) with ESMTP id 21269200690C; Fri, 27 Jan 2006 08:39:09 -0800 (PST) Message-ID: <43DA4CAC.3070906@dellroad.org> Date: Fri, 27 Jan 2006 10:39:08 -0600 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> In-Reply-To: <20060127155649.GA60799@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2006 16:39:10 -0000 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