From owner-freebsd-current@FreeBSD.ORG Tue Oct 26 12:39:55 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 BBD8616A4CE for ; Tue, 26 Oct 2004 12:39:55 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E59E543D49 for ; Tue, 26 Oct 2004 12:39:54 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 19700 invoked from network); 26 Oct 2004 12:37:38 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Oct 2004 12:37:38 -0000 Message-ID: <417E4598.1090902@freebsd.org> Date: Tue, 26 Oct 2004 14:39:52 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Hay 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> In-Reply-To: <20041026063545.GA57014@zibbi.icomtek.csir.co.za> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 12:39:55 -0000 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