Re: make buildkernel failed related to ip_divert module

John Hay wrote:
>>>Is there any harm in making IPFIREWALL_FORWARD default for the ipfw
>>>module? For that matter, why have a separate FORWARD option and not
>>>just have it as part of the standard firewall stuff?
>>
>>The reason is simple.  FORWARD modifies the entire ip_input(), ip_output()
>>and tcp_input() path.  This is not something that should be in stock kernels
>>unless you want to use 'ipfw fwd' (which is only a minority).
> 
> Ok, what about another module, called say ipfwfwd or something, that is
> ipfw compiled with forwarding? Then one can just load the one
> apropriate for you.

That wouldn't help any.  If you enable FORWARD parts in the kernel itself
are changed.  Just having a ipfw module with FORWARD doesn't help any
without a matching kernel.

>>>And related to this, is there a problem with kern/71910? This one is
>>>needed on a NAT box that have to forward packets to a web proxy for
>>>transparent proxying.
>>
>>This is two-edged sword.  Lets assume you have 192.168.0.1/24 on one
>>interface and 192.168.10.1/24 on the other interface with a default
>>route of 192.168.10.5.  You want everything from 192.168.0.0/27 to go
>>through 192.168.10.10 instead.  In this case an ICMP reply from the
>>router to the use will also be forwarded to that other gateway and never
>>reach the destination.  That is the reason for the check.  This can be
>>very nasty.
> 
> Well I was just a little surprised because it used to work. I have a 4.x
> machine where it does work.

In 4.x it is differently implemented.

> At some stage I thought kernel modules will take the need for recompiling
> kernels away, but slowly I'm resigning that that was probably just a nice
> dream. :-)

Well, it depends.  For intrusive things like IPFIREWALL_FORWARD it will
be only a dream.  For everything else it should become reality.

-- 
Andre