Date: Fri, 19 Oct 2012 18:38:40 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-ipfw@freebsd.org Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time Message-ID: <slrnk837hi.1jj.vadim_nuclight@kernblitz.nuclight.ipfw.ru> References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> <50815E36.6010703__40288.6851611131$1350655584$gmane$org@networx.ch>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Andre Oppermann! On Fri, 19 Oct 2012 16:05:42 +0200; Andre Oppermann wrote about 'Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time': > On 19.10.2012 14:18, Andrey V. Elsukov wrote: >> On 19.10.2012 16:02, Andre Oppermann wrote:>> >> http://people.freebsd.org/~ae/pfil_forward.diff >>>> >>>> Also we have done some tests with the ixia traffic generator connected >>>> via 10G network adapter. Tests have show that there is no visible >>>> difference, and there is no visible performance degradation. >>>> >>>> Any objections? >>> >>> No objection as such. However I don't entirely agree with the >>> naming of pfil_forward. The functionality is specific to IPFW >>> and TCP, it's doing transparent interjected termination of tcp >>> connections on the local host while keeping the original IP >>> addresses and port numbers visible in netstat output. >>> >>> So it's a feature of IPFW/IP and should be fitted in there for >>> sysctl name and .h files instead of pfil. >> >> Actually it can be used not only by ipfw. We already have >> net.inet.ip.forwarding and net.inet6.ip6.forwarding variables, and >> placing it into net.inet.ip.fw is undesirable, because we can have >> kernel without ipfw. So, i decided to choose pfil, because it could not >> work without pfil. > > Again, it's not a property of pfil. It's a property of IP and it > should live there from a configuration point of view. Wrong. It is already supported by IPv6 and could be used for any protocol which supports concept of routing. > Other firewalls than ipfw don't make use of it. Wrong, if one will look long-term, as it should be. This should (er, must) be non-ipfw but generic pfil solution. And if later other firewalls - as they should - will be converted to this mechanism, such sysctl naming would become misleading. And there are chances they *will* be converted, given the ongoing pf's SMP work, which is effectively better pf port to FreeBSD. Better port should be better utilizing native FreeBSD mechanisms, instead of foreign hack, this pfil_forward is one of that native mechanisms. > You could rename it to transparent connection proxy or some such. No, you are wrong here again. While 'ipfw fwd' could be used for transparent proxy, too, there are two completely different applications of this - one for local socket and another for policy routing. The latter, more proper be called 'route-to', is used far more often than the former. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnk837hi.1jj.vadim_nuclight>