From: Peter H. Coffin (no email)
Date: Fri Jan 02 2004 - 21:58:50 EST
On Fri, Jan 02, 2004 at 05:17:18PM -0800, Kurtis D. Rader wrote:
> 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.
First off, the first thing a mail server needs to do during an SMTP
connection is IDENTIFY itself, and the realistic situation that we face
today is that that mail server had better identify itself how the
smtpd server sees it. Which, frankly, means that that NATted SMTP server
needs to identify itself DIFFERENTLY depending on where it's connecting.
RFCs may say otherwise, but I know *my* Postfix installation is going to
refuse service from anything claiming to be a host that I can't verify.
Which also means that all kinds of preset variables that make sense for
an internal net ($myhostname, etc) are wrong for the NATted connection,
and have to be custom-crafted.
> > 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.
Heh. PIX Fixup, anyone?
--
36. I will not imprison members of the same party in the same cell block, let
alone the same cell. If they are important prisoners, I will keep the only
key to the cell door on my person instead of handing out copies to every
bottom-rung guard in the prison. --Peter Anspach's Evil Overlord List
|
|
|