The CUDN NAT (Network Address Translation) service extends the usefulness of CUDN-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. More information on this is given below.
- Traffic flow
- Protocol support
- Double NATing
- Timings and connection limits
- Outbound addresses and DNS names
- Logging and charging
- Comparison with a firewall
The NAT service translates the CUDN-wide private source IP address into a public IP address just before it exits the CUDN 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 callled SNAT (Source NAT).
Because NATing is done at the border of the CUDN, hosts with private IP addresses will be visible across the CUDN with those addresses but appear to have a public IP address when accessing a host outside the CUDN. 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.
The NAT equipment is NOT configured in-line with the normal outbound path for traffic leaving the CUDN. Instead, traffic from private IP addresses attempting to leave the CUDN 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:
Return traffic is routed back to the NAT equipment to be de-translated and then forwarded back into the CUDN 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):
C:\Users\rcf>tracert -4 www.ja.net
Tracing route to www.ja.net [22.214.171.124]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms gw-810.route-nms.net.cam.ac.uk [126.96.36.199]
2 <1 ms <1 ms <1 ms route-nms.route-mill.net.cam.ac.uk [188.8.131.52]
3 <1 ms <1 ms <1 ms route-mill.route-enet.net.cam.ac.uk [184.108.40.206]
4 <1 ms <1 ms <1 ms gw-nat-2-outside.route-enet.net.cam.ac.uk [220.127.116.11]
5 <1 ms <1 ms <1 ms xe-11-3-0.camb-rbr1.eastern.ja.net [18.104.22.168]
6 99 ms 79 ms 4 ms ae1.leed-sbr1.ja.net [22.214.171.124]
7 5 ms 5 ms 5 ms ae12.manc-sbr1.ja.net [126.96.36.199]
8 5 ms 5 ms 5 ms po11.manc-ban1.ja.net [188.8.131.52]
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.
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 CUDN 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 — where an institution-private address is NATed onto a CUDN-wide private address (probably by an institutional NAT) and then NATed again by the CUDN 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 CUDN NAT Service.
If institutions need to NAT institutional private addresses, they should do so only public addresses that will not pass through the CUDN NAT.
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.
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 CUDN for the University and associated institutions which are listed as being 'in Cambridge' (most likely 184.108.40.206/16)
- a particular private host will use a consistent public address when talking to a particular host outside the CUDN
- the DNS name registered for the public address will end in .cam.ac.uk
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
At the time of writing, the address range used for the outside of the NAT service is 220.127.116.11/23.
Contiguous /20 blocks of CUDN-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.
This configuration may change without warning.
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 CUDN 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 CUDN, 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, the Computing Service 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 NAT service keeps a log of all connections made through it for audit and security purposes. This information includes:
- the CUDN-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 CUDN
- 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
For traffic charging purposes, the information is captured before translation, so sees the CUDN-wide private IP addresses used and thus associates this with the corresponding institution. Traffic through the NAT service is charged at the same rate as non-NATed traffic.
Putting a host on a CUDN-wide private IP address and relying on the NAT for connections to hosts outside the CUDN 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 CUDN is large and has a wide mixture of users and devices in different states of health - the NAT only prevents connections from outside the CUDN and not from elsewhere inside the CUDN. Do not assume that all attackers are outside the CUDN.
As the NAT service will allow all outbound connections, hosts which have previously used CUDN-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.
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 CUDN-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 CUDN-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.