make buildkernel failed related to ip_divert module
John Hay
jhay at icomtek.csir.co.za
Tue Oct 26 09:18:07 PDT 2004
> >>>>
> >>>>>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
More information about the freebsd-current
mailing list