Re: make buildkernel failed related to ip_divert module

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

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.

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

I have just figured out a way of doing it without patching the kernel,
just use 2 machines, one doing the nat and another doing the forwarding.
:-) .... Hmmm, I guess I'll just keep on patching the kernel. :-)

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

I don't have all the answers either. :-) Maybe a compile or runtime kind
of option?

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

John
-- 
John Hay -- John.Hay_at_icomtek.csir.co.za / jhay_at_FreeBSD.org