CUDN NAT Service - Technical information

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.

Contents

• Operation
• Traffic flow
• Protocol support
• Timings and connection limits
• Outbound addresses and DNS names
  • Registering outbound addresses for access control
• Logging and charging
• Comparison with a firewall

Operation

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 UCS 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 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). The NAT is visible in a traceroute, as are the two trips through the border router - for example:

root@gorobei:~# traceroute www.ja.net
traceroute to www.ja.net (193.60.199.196), 30 hops max, 40 byte packets
 1  gw-810.net.cam.ac.uk (131.111.10.62)  1.390 ms  1.342 ms  1.298 ms
 2  route-cent.route-enet.net.cam.ac.uk (192.153.213.193)  1.244 ms  1.201 ms  1.151 ms
 3  nat-2-outside.net.cam.ac.uk (131.111.185.250)  1.099 ms  1.056 ms  1.009 ms
 4  gw-1983.net.cam.ac.uk (131.111.185.254)  0.968 ms  0.924 ms  1.594 ms
 5  gi5-0-0.camb-rbr3.eastnet.ja.net (193.63.107.157)  0.830 ms  0.787 ms  0.744 ms
 6  po2-0.chel-rbr1.eastnet.ja.net (193.63.107.30)  3.321 ms  4.116 ms  4.052 ms
 7  lond-sbr1.ja.net (146.97.40.45)  4.272 ms  4.231 ms  4.189 ms
 ...

In this case, hop 2 (route-cent.route-enet.net.cam.ac.uk) is the first pass through the border router; hop 3 (nat-2-outside.net.cam.ac.uk) is the NAT equipment; hop 4 (gw-1983.net.cam.ac.uk) is the traffic returning to the border router and hop 5 is the first router into JANET/EastNET. Different internal CUDN-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 UCS, 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.

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 CUDN for the University and associated institutions which are listed as being 'in Cambridge' (most likely 131.111.0.0/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

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 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 preceeded 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.

Logging and charging

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.

Comparison with a firewall

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.

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.