CUDN NAT Service - Introduction

The University Computing Service has introduced a general NAT (Network Address Translation) service for CUDN-wide private IP addresses (host names ending .private.cam.ac.uk). The NAT service enables these systems to have direct access to hosts on the internet. Previously systems with CUDN-wide private IP addresses needed to make all accesses through proxy services, such as the UCS web proxy service (usually known as the web cache) or a local NAT or web proxy service in their institution.

With the NAT service, the source addresses of CUDN-wide private hosts are translated into public IP addresses from the CUDN ranges and forwarded on to the internet. When the replies return from the remote host, the destination address is translated to the CUDN-wide private address using the mapping set up for the outbound portion of the traffic (this is what many people have deployed at home with a small residential router, except on a larger scale!)

Essentially, this new service 'just works' for most services; hosts on CUDN-wide private IP addresses gain access to hosts on the internet directly, without needing to reconfigure anything.

The UCS will be logging all the translations and connections set up across the NAT service so abuse can be traced back. For network traffic charging, the internal CUDN-wide private IP addresses will be used to identify the host/institution making access and shouldn't be affected.

Further technical information about the operation of the CUDN NAT service is available. The older webcache service (which is redundant now the NAT service is active) has been shutdown; our intention is to leave http://www.cam.ac.uk/proxyconfig.pac (and the corresponding WPAD service) in place indefinitely, but to always return DIRECT once the NAT service is in place.

Caveats

There are a number of caveats which may cause issues with this change:

Effects on CUDN private IP address space

• many institutions are already using private IP addresses internally and have their own NAT service; the introduction of the CUDN NAT service will not affect these directly but institutions may choose to disable their NAT service or switch to CUDN-wide private IP addresses to take advantage of the CUDN NAT service
• putting hosts on CUDN-wide private IP addresses is likely to become more popular and hosts on public addresss, that have no reason to accept incoming connections, may be migrated across
• some devices are on CUDN-wide private IP addresses deliberately to stop them talking directly with the internet; the NAT service will not selectively handle traffic - ALL CUDN-wide private IP addresses from 172.16.0.0/12 (except 172.31.0.0/16) will be translated, so some devices may suddenly gain communication they didn't previously have (including things such as printers, photocopiers, etc.)

IP address based access control

Particular attention is drawn to institutions using IP address based access control. As stated above, this change is likely to see a large increase in the use of CUDN-wide private IP addresses - if you are not including those, you may cause problems for your users.

As such, it is a good idea to check what address ranges you consider to be 'inside Cambridge'. This is a more complex question than it first sounds (see the slides from the "What is this 'CAM domain' thing anyway?" techlink given by Jon Warbrick and Bob Franklin, on 27th February 2008).

The address ranges you should be using are listed here. Include both the 'Public IPv4 addresses' and the 'CUDN-wide private (RFC1918) IPv4 addresses' in your access control lists.

If in doubt, please contact Network Support with what you are trying to do and they will be able to advise on the correct range(s) to include.

At the present time several institutions have a NAT which translates CUDN-wide private addresses not only for internet access, but also to allow their clients to access some internal (CUDN) resources which are not correctly accepting CUDN-wide private IP addresses. With the CUDN service offering a NAT for internet access this equipment may not be included in future network upgrades and so may cause problems later. Providers of services may begin to see problems reported to them about their configuration, problems that were previously worked around by their client sites.