From owner-freebsd-net@FreeBSD.ORG Sat Dec 4 21:53:55 2004 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 62CF316A4CE; Sat, 4 Dec 2004 21:53:55 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E08243D39; Sat, 4 Dec 2004 21:53:54 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id iB4LrqcV045004; Sun, 5 Dec 2004 00:53:52 +0300 (MSK) (envelope-from maxim@macomnet.ru) Date: Sun, 5 Dec 2004 00:53:52 +0300 (MSK) From: Maxim Konovalov To: Andre Oppermann In-Reply-To: <41B2200F.FB46E28A@freebsd.org> Message-ID: <20041205005101.H44692@mp2.macomnet.net> References: <200412021322.iB2DMxLj066304@freefall.freebsd.org> <20041202134041.GB32699@cell.sick.ru> <41B2200F.FB46E28A@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (169/041203) X-SpamTest-Info: Profile: Detect Standard No RBL (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], SpamtestISP/Release cc: net@freebsd.org Subject: Re: kern/73129: [patch] IPFW misbehaviour in RELENG_5 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: Sat, 04 Dec 2004 21:53:55 -0000 On Sat, 4 Dec 2004, 21:37+0100, Andre Oppermann wrote: [...] > > Investigating pre-PFIL_HOOKS ipfw I have not found any analog of > > this check. These checks do break some useful functionality: > > > > 1) policy routing of hosts from connected networks > > 2) policy routing of locally originated traffic > > > > The second one is used very widely. When you have lines to two > > ISPs and run natd for both of them, you policy route nated packets > > to them. > > I know. On the other hand having these checks avoids breaking responses > from the host doing the policy routing towards hosts on connected networks. > > In my case I had a problem where the MTU of the policy-routing target > interface was lower than 1500 but the ICMP fragmentation needed packets > never made it back to the real host; they were forwarded to the policy > destination. > > This is how I came to this check. It is more correct but indeed breaks > forwarding packets that were targeted at an IP address configured on a > local interface. This is an unintended side effect but I haven't found > a nice solution to work around that. I'm not entirely sure what the > best way is to handle this and it's also the reason why I haven't changed > it so far. > > If you have suggestions I'm all ears. But think through all cases at least > twice, there are some nice traps. Fixing one end without breaking another > one is hard. IMHO restoring the historic behaviour (even broken in some respects) is the best thing we can do at the moment. > > P.S. kern/73129, kern/73910, kern/71910 -- Maxim Konovalov