[121107] in North American Network Operators' Group
Re: I don't need no stinking firewall!
daemon@ATHENA.MIT.EDU (William Herrin)
Sun Jan 10 12:48:31 2010
In-Reply-To: <6eb799ab1001100048n69349777n4c95b506067aa753@mail.gmail.com>
From: William Herrin <bill@herrin.us>
Date: Sun, 10 Jan 2010 12:47:24 -0500
To: James Hess <mysidia@gmail.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sun, Jan 10, 2010 at 3:48 AM, James Hess <mysidia@gmail.com> wrote:
>=A0there are a few different =A0things that can be
> done, =A0such as =A0the firewall answering on behalf of the server (using
> SYN cookies) and negotiating connection with the server after the
> final ACK.
James,
That's called a proxy or sometimes an application-layer gateway. The
problem with proxies, aside from the extra computing overhead, is that
they radically change the failure semantics of a TCP connection. The
sender believes itself connected and has transferred the first window
worth of data (which may be all the data he needs to transmit) while
the firewall is still trying to connect to the recipient. Often the
proxy isn't clever enough to send an RST in stead of a FIN so the
remote application thinks it has a successful finish. Even if it does
send an RST, most application developers aren't well enough versed in
sockets programming to block on the shutdown and check the success
status, and even if they do they may report a different error than the
basic "failed to connect."
Proxies can be a useful tool but they should be used with caution and
only when you're absolutely sure that the difference in TCP failure
semantics is not important to the protocol you're proxying.
Regards,
Bill Herrin
--=20
William D. Herrin ................ herrin@dirtside.com bill@herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004
