From owner-freebsd-pf@FreeBSD.ORG Thu Jul 29 05:37:48 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 6F10B106564A for ; Thu, 29 Jul 2010 05:37:48 +0000 (UTC) (envelope-from mcbride@openbsd.org) Received: from smtp1.countersiege.com (imap.countersiege.com [IPv6:2001:240:581:69::218]) by mx1.freebsd.org (Postfix) with ESMTP id 56C348FC1B for ; Thu, 29 Jul 2010 05:37:48 +0000 (UTC) Received: from anchovy.countersiege.com (unknown [IPv6:::1]) by smtp1.countersiege.com (Postfix) with ESMTP id 2B422192F3; Thu, 29 Jul 2010 05:37:47 +0000 (UTC) Received: by anchovy.countersiege.com (Postfix, from userid 2000) id 835454C238; Thu, 29 Jul 2010 14:37:45 +0900 (JST) Date: Thu, 29 Jul 2010 14:37:45 +0900 From: Ryan McBride To: Justin Message-ID: <20100729053745.GC13817@countersiege.com> 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.20 (2009-06-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 05:37:48 -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. Yes, PF has to handle every packet of a synproxy'd connection. > 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. It's not clear what you mean by either of these statements. > 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? I don't think it is possible to do what you want. Once you have completed the 3-way handshake and negotiated a set of sequence numbers to use for the connection, there is no way to simply dump the established connection on another box that knows nothing about it. synproxy works by completing the 3-way handshake with the source first, then negotiating a separate 3-way handshake with the client. Because the negotiations are separate and the two endpoints have no direct knowlege of each other, there sequence numbers negotiated are different. PF handles translation between the different sets of sequence numbers, and has to be man-in-the middle for every packet on the connection in order to do this translation.