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?
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
