RELENG_5 ipfw problem

Andre Oppermann andre at freebsd.org
Fri Aug 27 08:28:08 PDT 2004


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



More information about the freebsd-current mailing list