pf synproxy

[Daniel Hartmeier]

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