From: Kurtis D. Rader (no email)
Date: Fri Jan 02 2004 - 20:17:18 EST
On Fri, 2004-01-02 19:40:54, Greg A. Woods wrote:
> It depends somewhat on exactly what NAT implementation you're using, but
> typically many of the low level protocol error handling mechanisms either
> get trashed beyond recognition by a NAT, or don't work at all, so error
> handling at the connection level will be broken with the result that any
> number of strange symptoms will appear and be almost impossible to
> diagnose (especially by anyone who might think running a server behind a
> NAT is an OK think to do :-).
>
> Many other common errors can be masked, hidden, transformed, or otherwise
> butchered by a NAT too, depending on what else has to pass through the
> thing (e.g. DNS).
What sorry excuse for a NATing firewall are you talking about?
What exactly do you mean by "error handling at the connection level
will be broken"? Any NATing router that breaks application level error
handling is unfit for any use other than a doorstop. Care to cite
some of the "common errors" that "can be masked, hidden, transformed,
or otherwise butchered by a NAT"? I suggest you post your statements
above to the comp.protocols.tcp-ip news group. I predict you'll get
some scathing replies from people who have actually played a part in
the design of TCP/IP.
> The only time you really have to run a mail server behind a NAT is almost
> always a scenario where you're not supposed to, or at least not expected
> to, be running any servers in the first place. Either that or you're
> dealing with such a confused and ignorant firewall administrator that NAT
> issues are going to be the least of your troubles.
Poppycock. I have no doubt you've experienced problems trying to operate
services such as a SMTP MTA behind a firewall. But if those problems had
anything to do with NAT it's because the product you were dealing with was
seriously broken.
-- Kurtis D. Rader +1 503-531-8274
|
|
|