This removes any chance of scalability or the ability to separate
out single targeted IP addresses. I suppose the synproxy machine would
have to in some way act as NAT - translating between the two - or
alternately, act as a NAT to establish an initial session, then insert a
state to pass all traffic between both ends without additional
inspection or proxying... perhaps some sort of validation then push
back... I just can't see how to impliment it with existing stuff...
On 7/28/2010 6:24 PM, Denis Doroshenko wrote:
On 7/29/10, Justin<[email protected]> wrote:
I got a reply on the FreeBSD lists suggesting the firewall itself -had- to
be the default gateway for the client;
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.
how could it be done within the same TCP connection? a TCP connection
is identified with two addresses and two ports. if the handshake is
done off 2.3.4.5, how can the connection go on aftewards off 1.2.3.4?
the connection should be proxied then till the end, and 5.5.5.5 will
never know who was the real originator of the connection. obviously,
for 5.5.5.5 to be able to answer to 1.2.3.4, the firewall doing the
synproxying should be the gateway. sounds logical.
