From owner-freebsd-net@FreeBSD.ORG Thu Jul 17 05:28:03 2003 Return-Path: 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 9AE6237B401 for ; Thu, 17 Jul 2003 05:28:03 -0700 (PDT) Received: from webfw.progtech.net (webfw.progtech.net [195.226.167.252]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96B6243F85 for ; Thu, 17 Jul 2003 05:28:02 -0700 (PDT) (envelope-from grossman@webfw.progtech.net) Received: from isis.muc.progtech.intern (isis.muc.progtech.intern [10.25.0.100]) by webfw.progtech.net (8.12.9/8.12.9) with ESMTP id h6HCRrEK049878 for ; Thu, 17 Jul 2003 14:27:54 +0200 (CEST) (envelope-from grossman) Received: (from grossman@localhost) by isis.muc.progtech.intern (8.11.6/8.9.3) id h6HCRr601636; Thu, 17 Jul 2003 14:27:53 +0200 (CEST) Date: Thu, 17 Jul 2003 14:27:53 +0200 (CEST) Message-Id: <200307171227.h6HCRr601636@isis.muc.progtech.intern> From: Rolf Grossmann MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: freebsd-net@freebsd.org X-Mailer: VM 7.04 under Emacs 21.2.1 X-Virus-Scanned: by amavisd-new Subject: Trouble with natd and path mtu discovery (ICMP_UNREACH_NEEDFRAG) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 17 Jul 2003 12:28:03 -0000 Hi, I'm currently running into a problem using natd with a private network that does not have an overall mtu of 1500. Unfortunately the setup is quite complex and I'd like to get by without explaining it all. So for the moment I'll just ask about what I think is the problem and if you need more information, you tell me so, okay ;) The packet in question is here. This is what it looks like before natd (received on internal interface): 14:04:43.688857 10.128.10.100 > 172.21.30.170: icmp: 10.129.16.1 unreachable - need to frag (mtu 1400) (DF) (ttl 253, id 0) 10.128.10.100 is the gateway that has a smaller mtu. 172.21.30.170 is the external host that was sending the big packet 10.129.16.1 is the internal host behind the gateway that requested the packet Now when that packet passed natd it looks like this (transmitted on external interface): 14:04:43.689091 10.128.10.100 > 172.21.30.170: icmp: 192.168.89.1 unreachable - need to frag (mtu 1400) (DF) (ttl 252, id 0) As you can see, the requesting host's ip has been adjusted to the "external" address of the host running natd. Unfortunately, the gateway's ip has not. Now if any router on the external side is doing reverse path checking (and as it's not working I believe there is one doing that), it will just drop the packet. And rightfully so, because it has an illegal source address. Now my question is: Is that a bug in natd or is there some standard that mandates the original ip must be preserved? And can someone please point me at the code to change to get that packet aliased? (I've been looking at libalias, but so far I don't quite get it.) Thanks a lot, Rolf.