Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Oct 2012 19:16:30 +0400
From:      "Alexander V. Chernikov" <melifaro@FreeBSD.org>
To:        Andre Oppermann <oppermann@networx.ch>
Cc:        "Andrey V. Elsukov" <ae@FreeBSD.org>, ipfw@freebsd.org, net@freebsd.org
Subject:   Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time
Message-ID:  <50816ECE.4020002@FreeBSD.org>
In-Reply-To: <50815E36.6010703@networx.ch>
References:  <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> <50815E36.6010703@networx.ch>

next in thread | previous in thread | raw e-mail | index | archive | help
On 19.10.2012 18:05, Andre Oppermann wrote:
> 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
Not exactly. It is currently supported in both IPv4 and IPv6.
> 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.
fwd is widely used as policy-based routing, so it is not just 
upper-layer TCP feature.
>



-- 
WBR, Alexander




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50816ECE.4020002>