Valdis.Kletnieks@vt.edu writes: > On Wed, 18 Jun 2003 16:06:08 PDT, Eric Rescorla said: > > Melinda Shore <mshore@cisco.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@rtfm.com] http://www.rtfm.com/