A Network Address Translator ("NAT", a.k.a. "NAT Router") is software or hardware that transforms IP traffic passing through it. A NAT rewrites IP addresses; often it is configured also to rewrite other parts of the IP traffic.
NAT technology is used for a variety of different purposes, including constructing private IP networks, sharing a small number of IP addresses among larger numbers of clients, building an IP firewall, and avoiding IP address numbering conflicts.
NATs are available in several forms. Hardware-based NATs are standalone devices. Software-based NATs that run on existing computers are also available; in fact, a number of common operating systems include NAT software, although normally this software is disabled by default.
Hardware or software that performs NAT sometimes includes complementary functions such as a DHCP server, a Wireless Access Point, firewall, etc. There are even some multifunction standalone devices that may be configured to function as either a NAT or as a transparent bridge (the two functions may be though of as opposites; a device would only be configured as one or the other at a time).
The purpose of this document is not to describe what a NAT does, or how to use NAT. Instead, this document is intended to describe just the issues specific to connecting a NAT (software-based or hardware-based) to Princeton University's campus network.
NATs can be complex, and some applications or protocols will not function across a NAT. We assume that the reader who has decided to deploy a NAT is already familiar with NAT technology. If the reader is unfamiliar with NAT, the documents cited in the Technical Resources section at the end of this document may be helpful.
Note well: OIT permits customers to operate NATs attached to the campus network, however, we strongly discourage it. In most cases, operating a NAT on the campus network imposes costs (either to the individual customer or the University as a whole) that outweigh any benefits it provides to the owner of the NAT.
This document does not apply to External Customer Networks.
Besides the limitations on NAT that are implicit in the technology, you should also be aware of a number of caveats with respect to the use of NATs attached to the campus network.
Although you may use any IP addresses on the private network behind your NAT, any IP packets transmitted by the NAT onto the campus network must contain the IP source address assigned to the NAT's campus network interface. Any frames transmitted by the NAT onto the campus network must contain the hardware (e.g. Ethernet) source address registered for the NAT's campus network interface. Any IP ARP packets transmitted by the NAT onto the campus network must contain the IP source address (sender protocol address) and hardware (e.g. Ethernet) source address (sender hardware address) registered for the NAT's campus network interface.
It is not acceptable for your NAT to leak onto the campus network those packets that have IP source addresses or hardware addresses from the private network behind your NAT. Essentially, the devices attached to your private network should appear "invisible" to the campus network; the campus network should only see the NAT's campus-side IP address and hardware address.
OIT's experience is that many NAT implementations appear to be buggy, sometimes violating this requirement. If your NAT is found to leak packets, you will be asked to correct the problem. If you are unable to correct the problem, you may be instructed to disconnect the NAT from the campus network. If the problem is severe, or ongoing, OIT may disable your network service.
Many NAT implementations include an embedded DHCP or BootP server. You are welcome to enable this service as long as it only provides DHCP or BootP service on the private network behind your NAT. Your DHCP or BootP server must not provide any service on the campus network side; it must never respond to any BootP or DHCP client on the campus network.
OIT's experience is that customers running NATs with embedded DHCP or BootP servers sometimes misconfigure them, or connect them incorrectly to the campus network, causing the device to provide DHCP or BootP service to the campus network. Because this is extremely disruptive to other devices attached to the campus network, you will be instructed to disconnect the device from the network immediately. OIT may also disable connectivity your network service, to attempt to restore network service to the other devices on the campus network.
Some NAT implementations include an embedded IP router. You are welcome to enable this service as long as it only announces routing on the private network behind your NAT. Your NAT must not make any routing announcements on the campus network side.
OIT's experience is that customers running NATs with embedded IP routers only rarely misconfigure this component, or connect the NAT incorrectly to the campus network, causing the device to announce IP routing to the campus network. Although rare, because this is extremely disruptive to other devices attached to the campus network, you will be instructed to disconnect the device from the network immediately. OIT may also disable your network service, to attempt to restore network service to the other devices on the campus network.
Some dedicated NAT implementations allow you to configure the NAT to forge the hardware address of another device (e.g. of your client computer). Some vendors refer to this as "cloning" or "spoofing" a hardware address.
You must not use this feature.
As with any device attached to the campus network, the NAT must use its own unique hardware address. It is unacceptable to configure the NAT to forge the hardware address of some other device, even another device belonging to you. The hardware address is the most basic way a device identifies itself to the network; mis-identifying one device as if it is another can cause a varieyt of problems for network services. In some circumstances, it also leads to two devices with the same hardware address attached to the campus network; this can interfere with OIT Mobile IP Service.
OIT's experience is that some customers attempt to use this feature to avoid registering the NAT in the Host Database (or paying any associated Tigernet Host Charge, if applicable). This is unacceptable use of the campus network; in addition to blocking network service to your device(s), it may be treated as a disciplinary matter.
The NAT must be registered properly in the Host Database; correct registration for NATs is documented below.
Some customers deliberately misregister the NAT to avoid paying any Tigernet Host Charge that might be associated with operating a NAT on the campus network. They misregister it by registering the Ethernet address of the NAT as if it were the Ethernet or Wireless address of some other device (e.g. a PC) registered in the Host Database.
This is not acceptable. Every unique device (e.g. NAT, PC, etc.) must be registered in its own Host Database entry.
OIT does not support NATs. You are responsible for operating your NAT in a way that does not interfere with the operation of the campus wired and wireless network. If you cannot configure it to operate in such a way, you will have to disconnect it.
We do not identify "recommended" NAT hardware or software. Although in some cases we may provide limited documentation regarding the configuration of certain NATs, we do so only to reduce the likelihood that customers will configure these devices in ways known to harm the network. We cannot guarantee that any configurations we publish will always work properly on the campus, or provide the function you desire; our experience is that even when properly configured, common NAT implementations may still malfunction in ways that require you to disconnect them.
Some of the operating systems OIT formally recommends and supports include NAT software bundled with the operating system. The NAT software is normally disabled unless or until the customer enables it. Although OIT supports the operating system, we do not support the NAT software, or any features of the operating system (or applications) that rely on the NAT software.
NAT is incompatible with some communication software or hardware. If a program (or device) does not function when it is behind your NAT, but functions when it is attached to the campus network with no NAT in front of it, then the presumption is that your NAT is causing the difficulty. OIT does not provide assistance in diagnosing the problem further; it is up to you to see if the problem can be resolved. This may involve reconfiguring the communication software or hardware you are trying to use, reconfiguring the NAT, or upgrading or replacing the NAT. Some protocols are simply incompatible with NAT, and nothing may be done to make them function across a NAT. You are encouraged to familiarize yourself with the technical documents cited at the end of this document.
To summarize: if you chose to attach a device operating as a NAT to the campus network, you are "on your own" in making it function properly. While OIT permits the use of NATs, we do not support them. OIT support staff are not responsible for assisting you in configuring or troubleshooting your NAT.
OIT's experience is that most NATs attached by customers to the campus network have at one time or another caused serious network disruptions, interfering with many other customers. And many have exhibited bugs that cause them to transmit erroneous traffic onto the campus network in ways that degrade network service to other customers.
As with any device attached to the campus network and causing a serious disruption (or degrading service to other customers), we disable network service to the offending device in whatever way is necessary to restore service to the remainder of the network.
In the case of a misbehaving NAT, we typically disable network service at the point where the misbehaving NAT is attached to the campus network. As a result, that location (e.g. dormitory room, apartment, office) may lack network service for an extended time (days, not hours). If you choose to attach a NAT to the campus network, you should keep in mind that it is likely this will happen to you, perhaps repeatedly.
As with any device attached to the campus network, if the device repeatedly disrupts service, or repeatedly behaves in a way that degrades service to other customers, OIT may insist the device be permanently disconnected from the campus network. If the device is later re-attached and is again the source of a similar problem, your network service may be blocked, and the matter may be referred to appropriate University disciplinary staff.
All IP traffic sent to the campus by a correctly-functioning NAT will come from the campus IP address assigned to the NAT, regardless of whether the traffic originated at the NAT or at one of the NAT's clients (on the private network).
When any of this traffic causes a problem on the campus network, OIT will identify it as coming from the NAT. OIT will not be able to help you to determine if it was originated by the NAT or by one of the NAT's clients. You will have to determine that, and correct it.
Given the likelihood that a NAT will be the source of problems, before operating a NAT on the campus network, you should reconsider why you have chosen to use a NAT.
For example:
You can instead install your own bridge-based Wireless Access Point, instead of a NAT-based one. While that too has its own serious pitfalls and is not supported or recommended by OIT, it at least avoids the problems introduced by a NAT-based Wireless Access Point. See Connecting a Private Wireless Access Point to the Campus Network.
Or you can instead install your own Ethernet repeater, bridge, or switch. While this has a few pitfalls and is not supported or recommended by OIT, it at least avoids the problems introduced by a NAT. See Connecting a Private Ethernet Repeater, Bridge, or Switch to the Campus Network.
While cost-reduction is an admirable goal, if your NAT causes problems for others on the campus network, the result is that the University as a whole pays for your choice.
Besides avoiding the problems introduced by a NAT, a device that was designed from the start to be a firewall (and only a firewall) will typically provide better security than that provided incidentally by a NAT.
If the NAT is a software-only implementation running on a computer (as opposed to a standlone hardware device dedicated to functioning as a NAT), then no special Host Database registration is necessary. The computer should (already) be registered in the Host Database (or subscribed to Dormnet) like any other device attached to the campus network, and have an ENTRY-TYPE of HOST. The remainder of this section does not apply to software-only NATs.
A dedicated NAT (a hardware device, rather than software that runs on a host computer) requires some special treatment when registering it in the Host Database, as described below.
How you register a dedicated NAT in the Princeton University Host Database depends on whether the NAT is associated with a Dormnet subscription or is an office device.
If the dedicated NAT belongs to a student and will be attached to the Dormnet network, it should be registered in the Host Database as a Dormnet subscription. Otherwise, it should be registered in the Host Database as an office device. Follow the instructions in the applicable section below.
Your dedicated NAT counts as a Dormnet subscription. Like any Dormnet subscription, there is no fee.
Complete the Dormnet subscription form. When completing the form:
Your NAT is subject to the Tigernet Host Charge.
Complete the Add a New Entry to the Host Database, for non-Dormnet devices form. When completing the form:
Only use the ADD-ENET-ADDRESS field to specify these additional hardware addresses. I.e. do not attempt to register any of these additional hardware addresses as a "Wireless Interface" (even if one of them is indeed Wireless); that's only appropriate for a Wireless interface that will be used with OIT Wireless Service, and your NAT's wireless interface should never be attached to the campus network via OIT Wireless Service.
Devices attached to the private network (behind the NAT) normally do not need to be registered in the Host Database. However, if these devices sometimes will be attached to the campus network elsewhere, they must be registered as described below.
If the clients attached to the private network behind your NAT are never attached elsewhere to the campus network (e.g. via Ethernet or Wireless), then you do not need to subscribe those clients to Dormnet. From the point of view of the campus network, you have just a single device (the NAT).
However, if you sometimes disconnect those clients from your private network, and reconnect them to the campus network (e.g. via OIT Ethernet or Wireless service), then you must subscribe these clients to Dormnet as well. Use the Dormnet subscription form to register each device in its own separate Dormnet subscription.
If the clients attached to the private network behind your NAT are never attached elsewhere to the campus network (e.g. via Ethernet or Wireless), then you do not need to register those clients in the Host Database; the clients are not subject to the Tigernet Host Charge. From the point of view of the campus network, you have just a single device (the NAT).
However, if you sometimes disconnect those clients from your private network, and reconnect them to the campus network (e.g. via OIT Ethernet or Wireless Service), then you must register those clients in the Host Database as well. Use the Add a New Entry to the Host Database, for non-Dormnet devices. Each will be subject to the Tigernet Host Charge.
Frequently we are asked why OIT does not recommend specific NAT hardware or software that will work acceptably with the campus network.
We do not do so for several reasons:
Given that OIT does not support NATs, discourages their use, and there are almost always better solutions to the problem a NAT was intended to solve, devoting OIT labor to helping customers who insist on using NATs anyway does not seem prudent.
These bugs requiring significant labor to discover; there is no simple test we can run to discover all bugs in a particular NAT. Instead, some become apparent over time, as the NAT causes problems on the network. Sometimes these problem are not apparent until after the NAT has been in operation for months. For software-based NATs, sometimes they resurface each time the host's operating system is upgraded. Sometimes they are intermittent. Often the NAT vendor is unable or unwilling to fix them.
Trying to identify a single NAT that is problem-free (one that is "safe" to attach to the network) appears to be a difficult problem.
This varies widely as there are no hard-and-fast Internet standards describing exactly how a NAT should accomplish its goals, and will likely never be, given that they violate the "end-to-end" model. NAT vendor may take different approaches in how their models operate. Some applications will work across one NAT, but not across another; firmware updates to the NATs may change the behavior further.
So even if we were able to identify a NAT that does not interfere or degrade campus network service (i.e. one that is "safe"), it would not necessarily provide the functionality that every NAT customer might desire (i.e. one that is "effective").
Hardware-based NATs within the price range campus customers might purchase are very low-end devices, and the vendor rarely continues selling the same model for very long before discontinuing it and replacing it with a different model which behaves differently.
Even before a model is discontinued, its behavior may change each time the vendor releases a firmware update for the NAT. The same NAT model purchased six months from now may have different bugs than the one purchased today, due to firmware updates.
So even if somehow OIT were to identify a particular NAT model that was both safe and effective, it would soon be unavailable for purchase, or would no longer operate the same as it did when we identified it.
Similarly, NAT software is a moving target, with changes to the behavior (and bugs) changing as the vendor modifies it.
Even if our list were accompanied by a a disclaimer of OIT support, most customers would still insist that by publishing such a list, OIT has made a committment to support those NATs, regardless of any disclaimer.
A better solution is to have additional OIT Ethernet ports installed/activated.
Some customers resist this solution, because of the cost associated with additional OIT Ethernet ports. Given the network disruptions caused by NATs on the campus network and the labor expended in handling these problems, any cost-savings experienced by the NAT owner are easily offset by the additional costs to the University. It is OIT's position that "cost savings" is a poor justification for operating a NAT on the campus network.
In those locations where it is not possible to have additional OIT Ethernet ports installed/activated (e.g. dormitory rooms and apartments), installing a private repeater, bridge, or switch is a much better choice than installing a NAT. For dormitory rooms and apartments, the OIT Solutions Center will be happy to loan you an Ethernet repeater for the duration of the academic year.
Given the network disruptions caused by NATs on the campus network and the labor expended in handling these problems, any cost-savings experienced by the NAT owner are easily offset by the additional costs to the University. It is OIT's position that "cost savings" is a poor justification for operating a NAT on the campus network.
They could avoid the problems caused by the NAT by instead using a Wireless Access Point that is designed to function as a bridge instead of a NAT.
Note that OIT does not recommend or support private Wireless Access Points; see Connecting a Private Wireless Access Point to the Campus Network. A department wishing to have wireless service in its location would be better advised to contact OIT to discuss the costs to the department for extending OIT Wireless Service to its location.
NATs can be complicated, and interact with existing networks and services in complex ways. Some applications or protocols simply will not function through a NAT; others will only function through a NAT that includes special handling for them. We assume that the reader who has decided to deploy a NAT is already familiar with the complexities of NAT technology, and understands the difficulties a NAT introduces. If the reader is unfamiliar with NAT, the following technical documents may be helpful (all presuppose familiarity with IP):