Date: Thu, 29 Jul 2010 14:37:45 +0900 From: Ryan McBride <mcbride@openbsd.org> To: Justin <justin@sk1llz.net> Cc: misc@openbsd.org, freebsd-pf@freebsd.org Subject: Re: pf synproxy Message-ID: <20100729053745.GC13817@countersiege.com> In-Reply-To: <4C50EE88.3010206@sk1llz.net> References: <4C509A99.4030305@sk1llz.net> <4C50EE88.3010206@sk1llz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100729053745.GC13817>