skip to content

IT Help and Support

University Information Services

The UDN NAT (Network Address Translation) service extends the usefulness of UDN-wide private IP addresses, allowing them to make direct access to services on the internet without needing to explicitly configure proxies.

It is important to note that the NAT service is NOT a firewall and should not be used as an alternative to a firewall or to host-based security.



The NAT service translates the UDN-wide private source IP address into a public IP address just before it exits the UDN onto Janet (and the internet). When replies return from the remote host the destination address will be translated back to the private address, using the reverse of the mapping set up for the outbound portion of the traffic. As the number of public IP addresses available to the NAT is much smaller than the number of private IP addresses to be translated, the TCP and UDP port numbers are also translated. This allows a single public IP address to be used by multiple internal hosts with private IP addresses.

This service is exactly the same as that provided by most domestic broadband routers, except on a much larger scale. It is commonly called SNAT (Source NAT), to differentiate it from DNAT (Destination NAT), where the translation is done at the destination end.

Because NATing is done at the border of the UDN, hosts with private IP addresses will be visible across the UDN with those addresses but appear to have a public IP address when accessing a host outside the UDN. As such, an individual host may appear under two IP addresses when comparing internal to external logs. The UIS keeps logs of the translations used to correlate these.

Traffic flow

The NAT equipment is NOT configured in-line with the normal outbound path for traffic leaving the UDN. Instead, traffic from private IP addresses attempting to leave the UDN is redirected by the border router to the NAT to be translated. The NAT equipment then performs the required translation and sends the traffic back to the border router for forwarding on to JANET and the internet:

Flow for traffic leaving the CUDN

Return traffic is routed back to the NAT equipment to be de-translated and then forwarded back into the UDN as normal (the light green arrows on the diagram above).  On a traceroute, the two hops are visible through the border router (although not the NAT itself):

xyz@doraemon ~ % traceroute
traceroute to (, 64 hops max, 52 byte packets
 1 (  6.637 ms  4.099 ms  3.668 ms
 2 (  2.553 ms  1.669 ms  2.036 ms
 3 (  2.332 ms  1.848 ms  2.082 ms
 4 (  2.044 ms  2.774 ms  2.090 ms
 5 (  2.807 ms  4.181 ms  3.633 ms
 6 (  2.003 ms  3.544 ms  2.610 ms
 7 (  7.923 ms  6.954 ms  6.318 ms
 8 (  30.294 ms  8.376 ms  9.782 ms
 9 (  7.450 ms  5.530 ms  6.507 ms
10 (  7.448 ms  7.806 ms  7.541 ms
11 (  7.151 ms  7.978 ms  6.719 ms
In this case, hop 4 ( is the first pass through the border router; hop 5 ( is the NAT router; hop 6 ( is the traffic returning to the border router, after being NATed; hop 7 is the first router on Janet/EastERN, outside the UDN.  Different internal UDN-wide private addresses may use slightly different addresses and hosts, as they pass through different parts of the NAT service.

This arrangement leaves traffic that does not need to be translated (e.g. IPv4 public addresses, IPv6 public addresses and multicast) to flow straight through the border router without passing through the NAT equipment (the orange arrow on the above diagram). As such, the introduction of the NAT service should not have any impact (either in terms of path or performance) on traffic which does not need to be translated.

Protocol support

There are no restrictions on which destination ports will be translated. Most applications should 'just work' through the NAT without need for configuration on the client, as long as the protocol is not affected by having the source address and port(s) translated or requires inbound connections back to the client. Protocols affected by this are typically those where the IP addresses or port numbers of the endpoints are carried in the payload of the protocol itself. Examples of such protocols include FTP, SIP and RTSP.

However the NAT equipment has the ability to 'fix-up' some common protocols as they pass through it, changing the addresses carried inside the payload to reflect the translated addresses and (in some cases) allow the corresponding inbound connection. Such protocols include:

  • FTP - File Transfer Protocol
  • H.323 with H.225 and RAS - typically used for video conferencing
  • PPTP - Point-to-Point Tunneling Protocol used for VPNs
  • RSH - Remote SHell

Protocols other than the above may work if they are NAT-aware, or after making changes to their configuration either at the client or server end. Since most consumer broadband installations use NAT to share a single residential connection amongst multiple internal hosts many protocols include support for working through NATs.

In some cases applications do not work through the NAT; this can be reported to the UIS, but no guarantees are made for any particular protocol if it requires additional support to work. In particular, note that unlike many consumer NAT devices, the UDN NAT service does NOT support UPnP (Universal Plug-and-Play) or NAT-PMP (NAT Port Mapping Protocol) - often used for on-line gaming, video conferencing or instant messaging - to allow the client to instruct the NAT to allow arbitrary inbound connections.

Double NATing

Double-NATing — where an institution-private address is NATed onto a UDN-wide private address (probably by an institutional NAT) and then NATed again by the UDN NAT Service is NOT supported and should not be attempted.  This may work but unpredictable behaviour can occur and it makes tracing access difficult.  The per-client connection limits are more likely to be reached as all clients behind the inner NAT will be considered to be a single client by the UDN NAT Service.

If institutions need to NAT institutional private addresses, they should do so only public addresses that will not pass through the UDN NAT.

Capacity considerations

Traffic using the NAT service is passing through a much more complex device than simple routers and switches.  In most situations, this does not cause any issues, but there are some things to consider, when transferring a large amount of data or making lots of connections in a short space of time.


The NAT equipment has sufficient bandwidth to cope with regular use, even by a very large number of devices on the UDN at the same time.

However, hosts which are transferring large amounts of data outside the UDN regularly should consider using a public IP address (either IPv4 or IPv6) to avoid saturating the links of the NAT service and impacting other users.

The amounts of data being referred to here are not the sort encountered in regular usage (even uploading files of several gigabytes), but more large research data sets to hosts with fast connections that would saturate a multi-gigabit link.

Timings and connection limits

As the NAT has a finite limit on the number of connections through it that can be tracked for translation, there are two basic limits imposed to avoid clients consuming excessive resources:

  • Connection limits - an individual host may be limited to a maximum number of connections through the NAT to avoid them filling the translation table. This limit is likely to be set high enough that only machines with unusual traffic patterns (e.g. malware) would encounter it; servers may hit this and can be moved to public addresses to resolve the issue
  • Timeouts - connections are monitored to see if they are still active and will be expired if they appear to be dead; this is most likely to affect TCP connections with no activity on them for an extended period, such as unused SSH sessions

The limits imposed above will be reviewed periodically against the capacity of the equipment and adjusted as appropriate. Comments on particular issues can be reported to Network Support for analysis. In most cases, connections can be maintained through the use of keepalives, at either the TCP/UDP level or in the higher protocols.

Outbound addresses and DNS names

Over time the configuration of the translations used by the NAT service may be changed for operational reasons. However, it can be assumed that:

  • the public addresses used will come from ranges assigned to the UDN for the University and associated institutions which are listed as being 'in Cambridge' (most likely
  • a particular private host will use a consistent public address when talking to a particular host outside the UDN
  • the DNS name registered for the public address will end in

Assumptions which must not be made include:

  • the ranges of addresses used by the NAT service
  • the public address used for any particular private address
  • what other private addresses may use the same public address; these may include those of other institutions
  • that all private addresses used by an institution will have the same public address
  • that the DNS name registered for the public address will identify the institution making the connection through the NAT

Current configuration and mappings

At the time of writing, the address range used for the outside of the NAT service is with the additional block at used solely for University Wireless Service clients (see the technical information pages for UniOfCam and eduroam for details, of how this is used).

For addresses in, contiguous /20 blocks of UDN-wide private IP addresses are translated behind a single public IP address in the above range, regardless of how many active hosts or connections are using that particular public address.

For addresses in (currently excluding the wireless subnets, described on a separate page), the public IP addresses are taken from a pool in and are not necessarily consistent (i.e. the particular address that might be used will change frequently).  The mapping should be "sticky", however: whilst a particular IP address has connections active through the NAT, the same public address should be used, although this cannot be guaranteed.

This configuration may change without warning or notice.

Registering outbound addresses for access control

It is strongly recommended that IP address-based authentication and authorisation is not used to control access to resources; user-based authentication (such as Raven or Shibboleth) allows access to the correct people, regardless of whether they are on the University network or not and prevents visitors using the University network from gaining access to resources to which they are not entitled. It also allows for changes in the ranges of IP addresses used by the University and associated institutions, or even between institutions within the university.

However, sometimes this is not possible and institutions may need to register public address ranges with external organisations to permit access to journals or other services. In this situation, it is strongly recommended that the entire UDN address space is used, to allow for changes in the ranges used both by the institution and the NAT service.

If this is unacceptable to the external organisation, as it will permit wider use of a restricted resource from within the UDN, it may be necessary to restrict the ranges to those addresses which may be used by a particular institution (including the public addresses which may be used for NATed addresses). In this situation, the above limitations must be born in mind. In particular, UIS Networks may adjust the mappings or address ranges used by the NAT service from time to time, resulting in the public addresses seen changing, and other institutions are likely to share the same public addresses.

It is likely major changes will be preceded by an advisory being circulated, but this is not guaranteed and there is likely to be little time between this notice and the change taking effect, requiring a rapid update of the addresses registered with the external service.

If any of these limitations are a problem (in particular, that outbound addresses may change without notice, or that an outbound address may be shared with another institution), an institution may have to consider running its own NAT or proxy service for traffic from its own IP addresses to all or just the service which depends on a fixed, exclusive address.  The Managed Firewall Service offered by the UIS can achieve this.


The NAT service keeps a log of all connections made through it for audit and security purposes. This information includes:

  • the UDN-wide private IP address and TCP/UDP port number (if applicable) of the host originating the connection
  • the public IP address and TCP/UDP port number (if applicable) which the private address/port was translated into for forwarding outside the UDN
  • the public IP address and TCP/UDP port number (if applicable) to which the connection was made
  • the protocol used (TCP/UDP/ICMP/etc.)
  • the start and end times of this connection
  • the amount of data transferred

Comparison with a firewall

Putting a host on a UDN-wide private IP address and relying on the NAT for connections to hosts outside the UDN could be considered to be a kind of firewall in that it prevents inbound connections from arbitrary hosts on the internet. While this is true to a certain extent, it must be noted that the UDN is large and has a wide mixture of users and devices in different states of health - the NAT only prevents connections from outside the UDN and not from elsewhere inside the UDN. Do not assume that all attackers are outside the UDN (and, even if the attacker is outside, they can gain access to the UDN through a vulnerable machine elsewhere on it).

As the NAT service will allow all outbound connections, hosts which have previously used UDN-wide private IP addresses deliberately to avoid being able to make such connections will find that is no longer the case. If a host should be isolated, institution-wide private addresses are probably more appropriate (although an institutional router would be needed to access them, unless it is done solely through hosts dual-homed onto both networks, such as a print server with a connection to an internal, private VLAN with printers on it).

In addition, as IPv6 becomes more prevalent and will usually automatically activate, when it is enabled on an institutional network, a host which has a UDN-wide private IPv4 address may suddenly begin speaking and responding on an global IPv6 address, directly accessible from the public internet.

The use of a UDN-wide private IP address does not provide an excuse to avoid taking all the normal security precautions, including disabling unused services, filtering the addresses from which inbound connections are accepted, and generally running systems in a secure manner.

Last updated: 15th January 2021