Re: make buildkernel failed related to ip_divert module

John Hay wrote:

> On Mon, Oct 25, 2004 at 10:25:44PM +0200, Andre Oppermann wrote:
> 
>>Sean McNeil wrote:
>>
>>>On Mon, 2004-10-25 at 13:13, Andre Oppermann wrote:
>>>
>>>>Conrad J. Sabatier wrote:
>>>>
>>>>>For a further bit of clarification (I know, should have done this the
>>>>>first time):
>>>>>
>>>>>This problem is occurring with the following kernel options:
>>>>>
>>>>>options     IPDIVERT
>>>>>options     IPFILTER
>>>>>options     IPFILTER_LOG
>>>>>
>>>>>The only workaround at this time is adding "options IPFIREWALL".
>>>>
>>>>Yes, that is correct.
>>>>
>>>>IPDIVERT is a module now and you can dynamically load it just like you
>>>>can load ipfw (options IPFIREWALL).
>>>>
>>>>IPDIVERT depends on ipfw being loaded or compiled into the kernel.
>>>>
>>>>I have done the last step of IPDIVERT's transition into a KLD a few
>>>>minutes ago.  It will warn you now if you try to compile it into a
>>>>kernel without IPFIREWALL as well.  As a module it will simply complain
>>>>that ipfw needs to be loaded first.
>>>
>>>
>>>I build my kernel with
>>>
>>>options         IPFIREWALL
>>>options         IPFIREWALL_FORWARD
>>>options         IPDIVERT
>>>
>>>Can I now use loadable modules as well?  Will IPFIREWALL have the
>>>forwarding option or would I still have to specify that?
>>
>>You can certainly use IPDIVERT as a loadable module.  The FORWARD option
>>to IPFIREWALL needs to be compiled into the module if you want to load
>>it as a module.  For modules options in the kernel configuration file
>>are not automatically included.  You have to edit sys/modules/ipfw/Makefile
>>instead.  Then you can load everything as module.  If you start natd from
>>rc.conf it will load ipdivert.ko automatically (if you have run mergemaster
>>to update your rc scripts).
> 
> 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).

> 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.

So I'm not sure what the right fix is.  Make the change to you can shoot
your foot off, and document that fact.  Or leave the checks in as they
are now?

-- 
Andre