Date: Fri, 19 Oct 2012 16:05:42 +0200 From: Andre Oppermann <oppermann@networx.ch> To: "Andrey V. Elsukov" <ae@FreeBSD.org> Cc: ipfw@freebsd.org, net@freebsd.org Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time Message-ID: <50815E36.6010703@networx.ch> In-Reply-To: <50814523.2070002@FreeBSD.org> References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Other firewalls than ipfw don't make use of it. You could rename it to transparent connection proxy or some such. -- Andre
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50815E36.6010703>