From owner-freebsd-current@FreeBSD.ORG Fri Aug 27 15:28:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7045C16A4CE for ; Fri, 27 Aug 2004 15:28:08 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A76EE43D2F for ; Fri, 27 Aug 2004 15:28:07 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 58069 invoked from network); 27 Aug 2004 15:26:45 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 27 Aug 2004 15:26:45 -0000 Message-ID: <412F5307.5040005@freebsd.org> Date: Fri, 27 Aug 2004 17:28:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver Brandmueller References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> In-Reply-To: <20040827141354.GC74653@e-Gitt.NET> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2004 15:28:08 -0000 Oliver Brandmueller wrote: > Hi. > > On Fri, Aug 27, 2004 at 02:22:02PM +0200, Andre Oppermann wrote: > >>Oliver Brandmueller wrote: >> >>>connection to port 25 is possible from a 192.168.25.x IP directly, but >>>if I enable this host on the load balancer, I do only see incoming >>>packets to port 25 on fxp0 but don't see any packets going back (on >>>neither fxp0 now em0 not even lo0). The forwarded packets simply >>>disappear. >> >>Please provide the ipfw line from dmesg as well. Then we can start to >>diagnose the problem. > > champagne# dmesg | fgrep ipfw > ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to deny, logging disabled > > additional information can be found here: > > http://the.addict.de/~ob/champagne/CHAMPAGNE (KERNCONF) > http://the.addict.de/~ob/champagne/dmesg.champagne (full dmesg) > http://the.addict.de/~ob/champagne/kldstat.champagne (loaded klds) > http://the.addict.de/~ob/champagne/make.conf.champagne (make.conf) > > "rule-based forwarding disabled" seems to be the point here. But I still > don't understand a few things then: > > - I did not not see any note about this change in UPDATING? Yes, you are right. This was probably not good enough documented. I'll update the ipfirewall.4 man page and conf/NOTES with this reintroduced option. It is in 4.x but somehow got lost in 5.x prior to my changes. I reintroduced the compile time option again because FORWARD is pretty intrusive and has its fingers in the TCP code as well. I don't think it belongs into a default kernel or a kernel with just ipfw compiled in. > - While this option is disabled, why can the rule then be loaded and > matched? If I don't enable dummynet, I cannot even load a dummynet > rule. It detects a missing dummynet because it has to pass on configuration options to dummynet and it can only do that if dummynet is loaded. For FORWARD this is not the case. Here the ipfw code just tags the packet for later treatment. And that later treatment is scattered through a few places where we have to inspect each packet it carries this tag. > - How to enable it? Put "option IPFIREWALL_FORWARD" into your kernel configuration file and recompile. > I think at least there's a POLA problem. Depends. If you are coming from 4.x it's not, if you are coming from 5.x it is. -- Andre