[unisog] Anyone doing large scale NAT for their campus?

Scott Genung 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 
>without
>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 
>painful
>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.


Scott Genung
Manager of Networking Systems
Telecommunications and Network Support Services
124 Julian Hall
Illinois State University

(309)438-8731   http://www.tnss.ilstu.edu



More information about the unisog mailing list