[unisog] Anyone doing large scale NAT for their campus?
sagenung at ilstu.edu
Mon Sep 23 19:40:16 GMT 2002
At 11:40 AM 9/23/2002 -0400, you wrote:
>NAT breaks *EVERY* protocol that expects you to be able to issue a listen()
>on the "inside" of the NAT without having to invent some sort of directory
>service to work around the fact that NAT screws up the concept of a "well
>known port" if there's two machines that want to listen to the port behind
>the NAT. (Notice this is why IPSec doesn't get along with NAT - it assumes
>that it's able to reach port 500 on the destination without the data getting
>molested along the way - and the NAT box can't rewrite the IP addresses
>breaking the signatures on them).
I should have been more specific. The implementation of NAT that I'm
referring to is based upon a 1 to 1 translation of inside to outside
addressing. The NAT model you are referring to is NAT overload (aka PAT)
where multiple inside addresses are mapped to a single (or limited number
of) outside address(es). In the NAT overload model, you are absolutely
correct (although there are workarounds for IPsec using NAT overload to
address the problem with ISAKMP keys). We do not use overload in our
environment. Although we are using a VPN solution for off-campus users
based upon IPsec, we exclude the address space served to the client from NAT.
>For instance, what implication does NAT have for VoIP or streaming multicast
>of media? Does your answer change if both people who want to use VoIP are
>behind a NAT, and neither one particularly wants to publish themselves in
>a phone number directory (which shouldn't be needed, if you're able to use
>hostnames or IP addresses because the end-to-end model works).
I think that most of us that are using NAT have no illusions about the
limitations of it. In the case of H.323 or SIP, NAT obviously creates
challenges. If you are trying to build a VoIP model that allows any to any
communication outside of your network without the use of a common directory
or controller, then I can understand your dislike for NAT. However, some
H.323 applications function fine with NAT as long as the user behind the
NAT engine initiates the call or the user on the outside is able to
determine the outside address of the user on the inside (assuming that a
translation exists and the NAT implementation is not overload). Of course,
this places a burden upon the user and therefore diminishes the
effectiveness of the application. We are looking at the possible
implementation of an H.323 MCU in our environment to address this concern.
I have no illusions about the challenges of this approach either - mostly
in scaling it.
>Ever tried to do FTP through a NAT that wasn't FTP aware? Remember how
>that was in the days when NATs weren't FTP-aware? Now consider that you get
>to go through that pain *EVERY SINGLE TIME* some new protocol comes out. And
>there's a good chance that unlike FTP, a lot of protocols will be marginal
>enough that you're NOT going to get a firmware update for your NAT box to
>support it. Sorry - there's a new better-than-Kazaa system? You can't use it
>because your vendor hasn't supported it yet.
Like anything else in networking, the decision for implementing NAT must be
based upon criteria that creates more opportunities than pitfalls for your
users. In our environment, we have not encountered a great deal of
application problems with our implementation of NAT. More importantly, it
allowed us to avoid the process of remasking our class B (something that
our users were less than euphoric about). Perhaps someday we will find an
application that will dictate the need to change what we're doing. For now,
we find that the benefits of implementing NAT outweighs the drawbacks. In
many environments, you will likely find that the opposite is true. That's a
decision that you will need to make.
>If that's "only a religious argument", so be it.
I used the term "religious" only because it is a passionate topic - not
because there are no valid technical concerns for using it. I keep
forgetting about NAT overload when I talk about NAT. Obviously, there are
valid concerns depending upon how you implement NAT and what your
application needs are. Sorry for the confusion.
Manager of Networking Systems
Telecommunications and Network Support Services
124 Julian Hall
Illinois State University
More information about the unisog