From owner-freebsd-current@FreeBSD.ORG Tue Oct 26 16:18:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8483816A4CE; Tue, 26 Oct 2004 16:18:07 +0000 (GMT) Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72D7643D68; Tue, 26 Oct 2004 16:18:00 +0000 (GMT) (envelope-from jhay@icomtek.csir.co.za) Received: from zibbi.icomtek.csir.co.za (localhost [127.0.0.1]) i9QGHwZV077662; Tue, 26 Oct 2004 18:17:58 +0200 (SAST) (envelope-from jhay@zibbi.icomtek.csir.co.za) Received: (from jhay@localhost)i9QGHwNG077661; Tue, 26 Oct 2004 18:17:58 +0200 (SAST) (envelope-from jhay) Date: Tue, 26 Oct 2004 18:17:58 +0200 From: John Hay To: Andre Oppermann Message-ID: <20041026161757.GA77267@zibbi.icomtek.csir.co.za> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417E4598.1090902@freebsd.org> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: make buildkernel failed related to ip_divert module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2004 16:18:07 -0000 > >>>> > >>>>>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