pf synproxy

[Justin]

    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?
>
>