Date: Fri, 27 Aug 2004 17:28:07 +0200 From: Andre Oppermann <andre@freebsd.org> To: Oliver Brandmueller <ob@e-Gitt.NET> Cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem Message-ID: <412F5307.5040005@freebsd.org> In-Reply-To: <20040827141354.GC74653@e-Gitt.NET> References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?412F5307.5040005>