From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 09:37:02 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 414381065677 for ; Thu, 29 Jul 2010 09:37:02 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (106-30.3-213.fix.bluewin.ch [213.3.30.106]) by mx1.freebsd.org (Postfix) with ESMTP id 2EBFA8FC21 for ; Thu, 29 Jul 2010 09:36:59 +0000 (UTC) Received: from insomnia.benzedrine.cx (localhost.benzedrine.cx [127.0.0.1]) by insomnia.benzedrine.cx (8.14.1/8.13.4) with ESMTP id o6T9awMo025953 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 29 Jul 2010 11:36:58 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.14.1/8.12.10/Submit) id o6T9aqjd021695; Thu, 29 Jul 2010 11:36:52 +0200 (MEST) Date: Thu, 29 Jul 2010 11:36:52 +0200 From: Daniel Hartmeier To: Justin Message-ID: <20100729093652.GA2497@insomnia.benzedrine.cx> References: <4C509A99.4030305@sk1llz.net> <4C50EE88.3010206@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C50EE88.3010206@sk1llz.net> User-Agent: Mutt/1.5.12-2006-07-14 Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf synproxy X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 09:37:02 -0000 On Wed, Jul 28, 2010 at 07:59:20PM -0700, Justin wrote: > Confirmed - synproxy works great if the synproxy machine is the > default gateway for the end host. Sadly this means scalability (adding > multiple synproxy boxes) is not possible, nor is it possible to filter a > specific IP out of the end machines ranges. > > Perhaps I'm shooting for the moon here - but shouldn't it be > possible to have a machine validate a remote host to be real and then > create a state to simply permit all traffic from it to pass without > additional filtering? Thus no breaking of packets and allowing the > remote host to respond directly? As Ryan explained, Direct Server Return cannot work for a synproxied connection, since the synproxy needs to translate the TCP sequence numbers in every subsequent packet of the connection. You can NAT the connection going out through the internal interface, replacing the source address with the synproxy's internal address, like nat on em1 inet proto tcp to $client port 80 -> em1 This works even when the connection is synproxied on em0, the packets generated by synproxy get translated as well. For the internal host, the connection would appear to come from the pf box, and it would reply directly to the pf box, without needing its default route (which can continue to point to the router in your case). This would scale to multiple pf boxes (with individual local IP addresses). I guess they could share one external IP using CARP and arpbalance, to spread the load across the farm of synproxies. The downside is that the web servers don't see the real peer IPs anymore, messing up web server log analysis, for instance. Daniel