Date: Wed, 28 Jul 2010 19:59:20 -0700 From: Justin <justin@sk1llz.net> To: freebsd-pf@freebsd.org, misc@openbsd.org Subject: Re: pf synproxy Message-ID: <4C50EE88.3010206@sk1llz.net> In-Reply-To: <4C509A99.4030305@sk1llz.net> References: <4C509A99.4030305@sk1llz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
On 7/28/2010 2:01 PM, Justin wrote:
>
>
> Ahh. That explains it then. I was operating under the assumption
> that the machine doing the synproxy would forge the reply such that
> the TARGET host would reply to the synproxy box, not its default gateway.
>
> As in 1.2.3.4 request to client 5.5.5.5 via -> 2.3.4.5, forged 2.3.4.5
> request to 5.5.5.5, 5.5.5.5 replies to 2.3.4.5, 2.3.4.5 no long
> proxies state and allows 1.2.3.4 and 5.5.5.5 to talk to each other
> directly.
>
> The topology is as such:
>
> internet - switch -> em0 | pf | em1 -> switch -> client
> \--------------------------/
>
> So the clients default gateway out is the switch, which doesn't send
> all traffic back over the PF machine. From what you've described, the
> PF synproxy box would literally have to be inline and the default
> gateway.
>
> internet - em0 | pf | em1 -> client
>
> Is this the case?
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C50EE88.3010206>