From owner-freebsd-ipfw@FreeBSD.ORG Fri Oct 19 18:38:57 2012 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3BD383F0 for ; Fri, 19 Oct 2012 18:38:57 +0000 (UTC) (envelope-from freebsd-ipfw@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id E05168FC0A for ; Fri, 19 Oct 2012 18:38:56 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TPHTI-0004ty-C2 for freebsd-ipfw@freebsd.org; Fri, 19 Oct 2012 20:39:00 +0200 Received: from broadband-77-37-234-86.nationalcablenetworks.ru ([77.37.234.86]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Oct 2012 20:39:00 +0200 Received: from vadim_nuclight by broadband-77-37-234-86.nationalcablenetworks.ru with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 19 Oct 2012 20:39:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ipfw@freebsd.org From: Vadim Goncharov Subject: Re: [RFC] Enabling IPFIREWALL_FORWARD in run-time Date: Fri, 19 Oct 2012 18:38:40 +0000 (UTC) Organization: Nuclear Lightning @ Moscow, Home Lines: 55 Message-ID: References: <508138A4.5030901@FreeBSD.org> <50814166.1000602@networx.ch> <50814523.2070002@FreeBSD.org> <50815E36.6010703__40288.6851611131$1350655584$gmane$org@networx.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: broadband-77-37-234-86.nationalcablenetworks.ru X-Comment-To: Andre Oppermann User-Agent: slrn/0.9.9p1 (FreeBSD) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: vadim_nuclight@mail.ru List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 18:38:57 -0000 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]