skip to primary navigationskip to content

Firewalls and Network Address Translation

firewall is a device that is placed between a network and 'the outside world' to enhance the security of a network in various ways:

  1. It can block traffic to/from particular hosts, internal or external - the existence of those hosts can therefore be hidden from the other side of the firewall.
  2. It can block certain identifiable protocol classes, e.g. ICMP.
  3. It can block traffic to certain identifiable ports, thereby blocking certain types of traffic.1

The usual practice for using a firewall is to allow only necessary traffic and to block everything else.

Although a firewall can provide a useful enhancement to the security of a network, it is no substitute for rigorous attention to the security of equipment behind the firewall. If a firewall is to be justified at all, it can be justified only as an additional measure, not as a replacement for others.

Network Address Translation (NAT) is a facility whereby the actual IP addresses and, possibly, ports used within an organisation's network, generally a LAN, are translated to other IP addresses and ports seen outside the organisation's network.

It is current UIS policy that each host that emits network traffic onto the CUDN, i.e. outside the institutional LAN, must use a unique IP address assigned and maintained by IP-register. There are many good reasons for this policy, mostly to do with ensuring integrity, security, traceability and manageability. To this end, UIS maintains a central database of this information in support of the DNS service. In particular, the matching of IP addresses to particular machines is used for traffic accounting and for the identification of victims and miscreants when an incident occurs.

Questions relating to Dynamic Host Configuration Protocol2 (DHCP) are not addressed here.

The issues

Many firewall vendors promote the use of NAT to conceal the internal details of a network protected by a firewall on the grounds that it is more difficult to attack a host if one does not know its address or the topology of the local network. Its use is also seen as a way of reducing the number of IP addresses required by an organisation, because of the perceived shortage of IPv4 addresses. Unfortunately, many firewall products require NAT to be used and do not permit a one-to-one mapping of addresses or a policy of non-translation. The difficulties caused by the use of NAT between the boundary of an institution and the CUDN are:

  1. In the event of a network or security incident, UIS would not have a means of determining which was the actual machine and its owner. Time is of the essence in such circumstances and, if a timely response from the institution were not forthcoming, UIS would have to resort to disconnecting the whole institution as blocking the apparently problematic address would not be adequate.
  2. It would, in practice, become impossible to provide meaningful traffic statistics broken down to the individual machine (as is currently being requested by colleges) as all traffic would be attributed as being to/from the firewall. Even if firewall logs of address mappings were made available to UIS for processing traffic statistics in a timely manner (i.e. contemporaneously), the number and diverse format of these logs would mean that it would be impractical for UIS to process them. It would, in practice, be up to individual institutions to do their own traffic monitoring and analysis, or possibly their own analysis of traffic data collected by UIS.
  3. The Data Protection Registrar has advised the University that IP addresses and associated host names should be considered to be personal data when they identify machines associated with individual users. Therefore, logs from a firewall will contain personal data. An institution needs to take this into account when planning for dealing with a data subject request. This issue is not considered further here.


Use of NAT by firewalls within institutions connected to the CUDN is permitted subject to the following:

  1. The firewall shall be managed and operated by the institution's in-house staff - delegation to students or an external contractor is not appropriate.
  2. The firewall shall produce an address-mapping log sufficient to identify the internal address of a station that was generating external traffic, given
    1. the externally visible IP address,
    2. the date and time,
    3. the IP protocol and externally visible port, if mapping depends on these.
    The log shall be machine-readable and in a format which facilitates subsequent processing. Timestamps in the log must be NTP-synchronised.
  3. The address-mapping log shall be available to the Cambridge CERT at 15 minutes notice within the normal working day. The availability should preferably not require human interaction within the institution, i.e. the Cambridge CERT should have authenticated, automated access and it should be able to extract the data by straightforward means, e.g. FTP. If human interaction within the institution is necessary, there shall be someone available at all times during the normal working day, including lunch and tea/coffee breaks, and cover for absences shall be arranged by the institution; adequate arrangements for out-of-hours access to the log must be made in consultation with the Cambridge CERT. Note that responsibility for access to the data must be in-house - delegation to students or an external contractor is not appropriate.
  4. UIS will be unable to provide itemised traffic statistics down to the level of identifying individual machines, as it has done in the past. At best, UIS can provide raw data relating to IP address ranges allocated to an institution; this data is timestamped only at 10-minute intervals which is too gross for the data to be related to individual machines using a firewall's log.
  5. The institution shall provide3 UIS's IP register with details of all connected machines and their corresponding internal IP addresses - these allocations must be as rigorously controlled as the current IP addresses and, in particular, unregistered machines shall not be allowed access to the CUDN.
  6. RFC1918 private addresses cannot be freely used by an institution as their use must be coordinated across the University. UIS's IP register shall allocate relevant address ranges and institutions shall use only those local address ranges that have been allocated to them by UIS. It is likely that certain local address ranges will be allocated uniquely across the institutions connected to the CUDN and that certain other local address ranges will be allocated non-uniquely.
  7. Network access for network management and fault diagnosis purposes shall be provided by the institution. In particular, the external firewall interface shall respond to ping and traceroute from at least certain sources specified from time to time by UIS.
  8. Friendly probing of an institution's local machines by UIS would not be possible. This would mean that UIS would not be able to detect vulnerabilities in hosts connected to that institution's network and then warn an institution's Computer Officers as is done at present. The additional security gained by installing the firewall must be balanced against the probable consequential loss of security through not having the friendly probing. The institution's staff must therefore be even more security-conscious.
  9. Static addresses (needed for network servers and for access to those subscription-based services that use the source address for authentication) are for future study. Use of a firewall with NAT would, at least initially, prevent use of those facilities.
  10. The institution shall be aware that, in the event of a serious incident where the detailed information is not available and appropriate action cannot be taken within the institution, UIS will disconnect or disable the institution's network from the CUDN until it is satisfied that the incident has been adequately dealt with. This is not something that is specific to an institution with a firewall; however, the presence of a firewall substantially increases the likelihood of this happening.

1Note, however, that it may be possible for hosts to configure alternative ports and thereby circumvent particular blocks.

2DHCP (RFC2131) is often used to allocate IP addresses dynamically from a pool. However, DHCP can also be used to allocate static addresses, i.e. fixed IP addresses that have been configured to correspond to the MAC addresses of the attaching devices. The logging burden when static allocations are used with DHCP is considerably reduced compared to when dynamic addresses are used. Such static DHCP may be of particular use for connecting laptop computers.

3It is envisaged that the transfer of address information shall be by automated means that would routinely extract the data for the central IP database. Sanity checks against firewall address-mapping logs would be made.


If you have any enquiries regarding UIS network services, or other University network topics, please send an email to: