Date: Tue, 26 Oct 2004 18:56:30 +0200 From: Andre Oppermann <andre@freebsd.org> To: John Hay <jhay@icomtek.csir.co.za> Cc: freebsd-current@freebsd.org Subject: Re: make buildkernel failed related to ip_divert module Message-ID: <417E81BE.5000909@freebsd.org> In-Reply-To: <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> <20041026161757.GA77267@zibbi.icomtek.csir.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
John Hay wrote: >>>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. That wouldn't help any. If you enable FORWARD parts in the kernel itself are changed. Just having a ipfw module with FORWARD doesn't help any without a matching kernel. >>>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. In 4.x it is differently implemented. > 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. :-) Well, it depends. For intrusive things like IPFIREWALL_FORWARD it will be only a dream. For everything else it should become reality. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?417E81BE.5000909>