Date: Tue, 26 Oct 2004 18:17:58 +0200 From: John Hay <jhay@icomtek.csir.co.za> To: Andre Oppermann <andre@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: make buildkernel failed related to ip_divert module Message-ID: <20041026161757.GA77267@zibbi.icomtek.csir.co.za> In-Reply-To: <417E4598.1090902@freebsd.org> References: <417B128B.7080904@gddsn.org.cn> <20041024133045.40733f45@dolphin.local.net> <417D5E51.2060100@freebsd.org> <1098735588.41693.4.camel@server.mcneil.com> <417D6148.6050807@freebsd.org> <20041026063545.GA57014@zibbi.icomtek.csir.co.za> <417E4598.1090902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> >>>> > >>>>>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@icomtek.csir.co.za / jhay@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041026161757.GA77267>