From owner-freebsd-net@FreeBSD.ORG Thu Jan 5 11:04:09 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 BB19016A41F for ; Thu, 5 Jan 2006 11:04:09 +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 31BCF43D55 for ; Thu, 5 Jan 2006 11:04:08 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 92270D9 for ; Thu, 5 Jan 2006 06:04:28 -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 5F2A91FC8 for ; Thu, 5 Jan 2006 06:04:28 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EuSua-0006hu-Ty for freebsd-net@freebsd.org; Thu, 05 Jan 2006 11:04:05 +0000 Date: Thu, 5 Jan 2006 11:04:04 +0000 From: Brian Candler To: freebsd-net@freebsd.org Message-ID: <20060105110404.GA25737@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: 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: Thu, 05 Jan 2006 11:04:09 -0000 I've done a bit more debugging on the MSS problem I'm having with sl2tps running with IPSEC transport layer security. The client is Windows XP out-of-the-box. Here's what happens: 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 4. When the remote webserver responds, it offers an MSS of 1380 (?) 5. The client sends a HTTP request, the server responds (MSS1360 / MTU1400), but that's too large to fit ng0 (MTU 1376) root@candlerb ~# ifconfig ng0 ng0: flags=88d1 mtu 1376 inet 172.17.0.216 --> 192.168.100.100 netmask 0xffffffff root@candlerb ~# tcpdump -i rl0 -n -s1500 tcp port 80 or icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes 10:41:16.454720 IP 172.17.0.216.58826 > 212.100.234.54.80: S 1482417021:1482417021(0) win 16384 10:41:16.464675 IP 212.100.234.54.80 > 172.17.0.216.58826: S 1193972421:1193972421(0) ack 1482417022 win 5840 10:41:16.465486 IP 172.17.0.216.58826 > 212.100.234.54.80: . ack 1 win 17680 10:41:16.466490 IP 172.17.0.216.58826 > 212.100.234.54.80: P 1:522(521) ack 1 win 17680 10:41:16.477538 IP 212.100.234.54.80 > 172.17.0.216.58826: . ack 522 win 6432 10:41:16.485841 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432 10:41:16.485983 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 10:41:16.487047 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1361:2721(1360) ack 522 win 6432 10:41:16.487114 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 10:41:19.512030 IP 212.100.234.54.80 > 172.17.0.216.58826: . 1:1361(1360) ack 522 win 6432 10:41:19.512182 IP 172.17.0.216 > 212.100.234.54: ICMP 172.17.0.216 unreachable - need to frag, length 36 172.17.0.216 is the IP address of the FreeBSD box; the client's L2TP pool address has been NATted to this using pf. And of course, being a private address, the FreeBSD box is also behind a NAT firewall. And because of this, the ICMP 'need to frag' message isn't getting back to the webserver, and everything falls over. So I have the following questions: 1. If the PPP MRU is 1400 (which appears to be correctly picked up on the Windows side), why is the ng0 MTU 1376? 2. How can I fix this problem, without manually frigging the MTU at the Windows client side? I don't think the IPSEC transport header is anything to do with this: the PPP session sits *within* the IPSEC encapsulation, and 1400 is plenty of space for an IPSEC header to be added and still fit within Ethernet MTU. Regards, Brian.