Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu writes:
On Wed, 18 Jun 2003 16:06:08 PDT, Eric Rescorla said:
Melinda Shore <mshore(_at_)cisco(_dot_)com> writes:
Not really. For example, ftp as originally defined doesn't
work through NATs, and no standard VoIP or multimedia
conferencing protocol works through NAT.
None of these things worked real well through firewalls either,
which is sort of my point.
There's a *crucial* distinction here:
If it doesn't work through a firewall, it's because the firewall is doing
what you ASKED it to do - block certain classes of connections.
If it doesn't work through a NAT, it's because the NAT is FAILING to do what
you asked it to do - allow transparent connections from boxes behind the NAT.
Unless of course you're deploying NAT for some reason *OTHER* than
transparent connections? Are you trying to get your money's worth because
you paid for the extra-deluxe "works most of the time but breaks some apps"
version?
This seems to me like a false dichotomy. If I were deploying a NAT
(which I didn't) there would be certain things I would care about
and others I didn't. If I'm already firewalling off these services,
why should I care if NAT blocks them?
Or is the only reason you have NAT at all because you bought some vendor's
"connection appliance in a box" that proceeded to NAT you regardless of your
desires?
Why is it so hard for people here to believe that customers might
actually know what they want, even if you don't happen to think
it's a good idea?
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]
http://www.rtfm.com/