From owner-freebsd-net@FreeBSD.ORG Tue Dec 27 00:29:40 2005 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 B4BAC16A41F for ; Tue, 27 Dec 2005 00:29:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C30C43D66 for ; Tue, 27 Dec 2005 00:29:30 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBR0TRuG004457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Dec 2005 03:29:28 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBR0TR5m004456; Tue, 27 Dec 2005 03:29:27 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Dec 2005 03:29:27 +0300 From: Gleb Smirnoff To: Oleg Tarasov Message-ID: <20051227002927.GH1496@FreeBSD.org> Mail-Followup-To: Gleb Smirnoff , Oleg Tarasov , freebsd-net@freebsd.org References: <1687545235.20051226134150@osk.com.ua> <1122736554.20051226175631@osk.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1122736554.20051226175631@osk.com.ua> User-Agent: Mutt/1.5.6i Cc: freebsd-net@FreeBSD.org Subject: Re: Router on 6.0-stable fails to route tcp packets due to NAT?? malfunction 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: Tue, 27 Dec 2005 00:29:40 -0000 On Mon, Dec 26, 2005 at 05:56:31PM +0200, Oleg Tarasov wrote: O> Further analysis brought me to a conclusion that the problem is in MTU O> values. Changing MTU on client machines made everything work fine - O> but as I know this is not right. If packets are routed between O> different MTU interfaces they have to be fragmented or something. If O> fragmentation is impossible due to "dont fragment" bit set an icmp O> packet "Need Fragmentation" should be sent to packet sender. O> O> As I know web and ftp packets dont have "dont fragment" bit set so O> packet fragmentation should apply normally what doesn't happen. O> O> Reading my firewall configuration we can see that any icmp packets can O> go freely through it so the reason of such malfunction is unknown to O> me. Also there are rules that allow passing of fragmented packets O> freely. Anyway the firewall configuration was copied from another O> production system which also has different MTU's on interfaces. O> O> Can anyone tell me what is the problem? The problem is that you've got a PPPoE link between local net and internet. (internet cloud, MTU 1500)-(your ISP)-[mtu 1492]-(your server)-[mtu 1500]-(your clients). So, when your Windows create a new outgoing connection they set TCP MSS value to 1460, since they don't know about a 1492 MTU link on the way. And this link limits TCP MSS to 1452. There are numerous solutions to fix this: 1) ports/net/tcpmssd - a divert daemon, like natd. You need to divert traffic thru it, and it will alter the TCP MSS value to set limit. 2) ng_tcpmss(4) - a netgraph node, implementing same code in kernel. You usually need ng_ipfw(4) to divert traffic via ng_tcpmss(4) 3) Recently I have committed ng_tcpmss support into mpd, but this code is not yet included into any new release. If you are brave, you can checkout mpd from CVS and use it. It will configure ng_tcpmss node automatically. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE