From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 16:26:27 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 3B87916A425 for ; Fri, 27 Jan 2006 16:26:27 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04D04441A8 for ; Fri, 27 Jan 2006 15:56:53 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id F1BB0D3; Fri, 27 Jan 2006 10:57:14 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 8A2898C59; Fri, 27 Jan 2006 10:57:13 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F2Vxx-000Fpj-Oc; Fri, 27 Jan 2006 15:56:49 +0000 Date: Fri, 27 Jan 2006 15:56:49 +0000 From: Brian Candler To: Archie Cobbs Message-ID: <20060127155649.GA60799@uk.tiscali.com> References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DA30AD.5040907@dellroad.org> User-Agent: Mutt/1.4.2.1i 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:26:27 -0000 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.