make buildkernel failed related to ip_divert module
Andre Oppermann
andre at freebsd.org
Tue Oct 26 09:56:33 PDT 2004
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
More information about the freebsd-current
mailing list