NAT service

The UDN NAT (Network Address Translation) service extends the usefulness of UDN-wide local 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.

Contents

• Operation
• Traffic flow
• Protocol support
• Double NATing
• Capacity considerations
  • Bandwidth
  • Timings and connection limits
• Outbound addresses and DNS names
  • Current configuration and mappings
  • Registering outbound addresses for access control
• Logging
• Comparison with a firewall
• Changes during summer 2024

Operation

The NAT service translates a UDN-local (formerly UDN-wide private) source IP address into a global 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 UDN-local address, using the reverse of that set up for the outbound portion of the traffic. As the number of global IP addresses available to the NAT is much smaller than the number of local IP addresses to be translated, the TCP and UDP port numbers are also translated. This allows a single global IP address to be used by multiple internal hosts with local 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. It is often also called PAT (Port Address Translation) as it involves adjusting the port numbers, as well as the addresses.

Because NATing is done at the border of the UDN, hosts with UDN-local IP addresses will be visible across the UDN with those addresses but appear to have a global 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.

For the sake of brevity in this page, the term "local" will be used to refer to UDN-local addresses, even though another type of local addresses ("institution-local") also exist; institution-local addresses are not handled by the UDN NAT service but can be translated by institutional NAT routers, if required.

Traffic flow

The NAT equipment is NOT configured in-line with the normal outbound path for traffic leaving the UDN. Instead, traffic from local 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:

nat_configuration.png

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):

xyz789@doraemon ~ % traceroute www.ja.net
traceroute to ja.net (13.248.198.253), 64 hops max, 40 byte packets
 1  gw-300.wl-a1.wl.net.private.cam.ac.uk (10.255.255.253)  4.784 ms  3.472 ms  3.804 ms
 2  wl.d-we.net.cam.ac.uk (128.232.195.161)  5.806 ms  3.390 ms  3.915 ms
 3  d-we.c-mi.net.cam.ac.uk (131.111.6.113)  5.835 ms  5.888 ms  3.397 ms
 4  c-mi.b-jc.net.cam.ac.uk (131.111.6.182)  4.003 ms  3.415 ms  3.963 ms
 5  in.n-2.net.cam.ac.uk (193.60.92.46)  3.975 ms  3.872 ms  3.952 ms
 6  gw-n2o.b-jw.net.cam.ac.uk (131.111.185.253)  3.837 ms  3.471 ms  3.852 ms
 7  ae8.londtw-ban1.ja.net (146.97.40.81)  7.850 ms  7.545 ms  7.768 ms
 8  ae26.londtw-sbr2.ja.net (146.97.35.217)  5.806 ms  7.447 ms  7.844 ms
 9  ae16.slouba-ban1.ja.net (146.97.35.182)  7.763 ms  7.033 ms  7.707 ms
10  99.82.180.146 (99.82.180.146)  7.959 ms  9.334 ms  7.651 ms
...

This arrangement leaves traffic that does not need to be translated (e.g. IPv4 global addresses, IPv6 global 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 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-local address is NATed onto a UDN-local 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 institution-local addresses, they should do so onto global addresses (as opposed to UDN-local 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.

Bandwidth

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 global 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 global 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 the UIS 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 global 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 131.111.0.0/16),
• a particular local host will use a consistent global address when talking to hosts outside the UDN, whilst it remains connected (it may receive a different global address, next time it connects out),
• the DNS name registered for the global address will end in ".cam.ac.uk" (although note that this should not be relied upon as IPv6 addresses and dynamic DHCP addresses are typically not registered).

Assumptions which must not be made include:

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

Current configuration and mappings

Important!  The following information is correct at the current time but is due to change during 2024, with the replacement of the legacy NAT equipment. Instead, the general information about assumptions, above, should be followed.

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

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

For UDN-local addresses in 10.128.0.0/9 (currently excluding the wireless subnets, described on a separate page), the global IP addresses are taken from a pool in 131.111.184.0/23 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 global 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 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 global 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 global addresses which may be used for NATed addresses). In this situation, the above limitations must be born in mind. In particular, the UIS may adjust the mappings or address ranges used by the NAT service from time to time, resulting in the global addresses seen changing, and other institutions are likely to share the same global 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 the global 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.

Logging

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

• the UDN-local IP address and TCP/UDP port number (if applicable) of the host originating the connection,
• the global IP address and TCP/UDP port number (if applicable) which the UDN-local address/port was translated into, for forwarding outside the UDN,
• the global 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, and
• the amount of data transferred.

Comparison with a firewall

Putting a host on a UDN-local 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. It must not be assumed 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-local 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-local 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-local IPv4 address may suddenly begin speaking and responding on a global IPv6 address, directly accessible from the public internet.

The use of a UDN-local 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.

Changes during summer 2024

When the NAT service was initially set up, individual blocks of UDN-local addresses were mapped to specific global addresses.  Since then, the number of UDN-local addresses has increased dramatically and alternative schemes have been put in place for the additional address blocks, resulting a complicated configuration that is difficult to expand.  Over the summer of 2024, the UDN NAT service hardware will be replaced for a new hardware and software platform and it will not be possible to retain these mappings.

At the present time, the final configuration and switchover date have not yet been determined, but the historic mappings are likely to change early in summer 2024 (June/July).  Instead, the more general rules described above will come into play, namely that translation will just be behind "a Cambridge IP address".  In particular, it must be noted that the global address used may change each time the user connects, even if the local address is the same (although the address should remain "sticky", whilst a host remains connected).

In most cases, users will be unaffected but, where a specific global address for a particular local address is relied upon, access may be blocked by the remote service, as the address the user is accessing it from may have changed.  There are three main solutions to this which are, in descending order of preference:

1. (Recommended) IP addresses are not used to control access but, instead, user authentication is performed.  In particular, this allows access to resources when users are not located on their home network at Cambridge, which is increasingly likely with flexible working practices.
2. Expand the range of addresses from which access is allowed to access the remote resource to the entire Cambridge global IP address ranges.
3. Where access must be more precisely controlled (perhaps to a sensitive resource), NAT should be performed by a site or institutional router/firewall for the required users, accessing that particular resource only.  Note that translation logs must be retained, as well as addresses other than those used by the link subnets with the UDN.

Where such access control is deployed, users are recommended to contact their local IT support to confirm that appropriate actions are performed.

Where an institution has this requirement and a Managed Firewall provided by the UIS, option (3) can be configured upon request and the UIS will supply the new global address(es) used to pass onto the remote party.

Last updated: 29th April 2024