Background: If you are required to have submitted a "Data Retention Implementation Plan" to ACMA, and CGNAT is featured in your solution as a way to identify a customer responsible for accessing a remote internet resource at a given time and date, this guide will help to respond to an official request for such information. To be useful, such a request for customer identification must include:
- source IP address of connection to remote resource
- source port (TCP/UDP) of connection to remote resource (note that only TCP/UDP can be traced in this way)
- date and time of access
About NAT: Network Address Translation is mechanism that allows use of private IP addresses on a LAN to be 'hidden' from remote hosts. A typical NAT implementation will take an IP packet with private source address (e.g. 192.168.0.50) and substitute the source address with public IP address of the NAT router (e.g. 203.21.76.17) and at the same time, substitute the source port of the outbound request with a randomly selected source port that is available on the outbound interface of the router. The diagram below shows an example of a typical NAT process:
When the NAT is applied by the router, the original source address and port are recorded in a lookup table together with the translated source address and port so that reply packets can be accurately re-translated back to the original client sender. IN MikroTik RouterOS, this information can be found in the Connection Tracking Table ( IP -> Firewall -> Connections in Winbox tool )
In the above example, a client host on the private side of the NAT router initiates a connection to a remote http server on host IP address 8.8.8.8 with destination port 80 (http). When the remote service responds with reply packet, with destination address and port of the received request source, the NAT router looks up the previously recorded source port to again re-translate the destination address and port to match the values of the original outbound packet.
NAT Traceability Problem: Originally designed simply to permit mass re-use of a set of IP address blocks to be used and re-used en-masse for many millions of local networks, allocation of the translated source address means that there is no reliable way to determine what internal source IP address was attributable to a randomly chosen external port after the TCP or UDP connection has been completed. This introduces a problem if permanent traceability of TCP connections is required.
About CGNAT: Carrier Grade NAT is a NAT implementation that delivers a statically defined set of source ports instead of purely random selection. With CGNAT, the complete range of possible source port values (1-65535) is divided evenly among all possible internal source addresses, and then the source port selected during NAT process is chosen from that pre-determined sub-range. An example of a CGNAT implementation allocating 100 source ports for each internal IP address might be as follows:
With this arrangement, a translated packet exiting the NAT router on the public interface can always be directly matched with an internal host address simply by cross referencing the source address of that packet with the table above. For example, referring to the original NAT shown above:
A translated packet with source port of 12345 must be initiated by the internal LAN host with IP address of 192.168.0.12
Responding to an official request for customer information: When a request from an authorised party (Australian Federal Police, ASIO, Australian Signal Directorate, ..) to identify your customer responsible for initiating a connection to a remote service, they will provide:
- a public IP address from a range that is formally allocated to your company or business
- a public IP address from a range that is formally allocated to your company or business
- the source port (TCP or UDP) used in the subject resource access event
- a timestamp (date, time, timezone) of the access event
ON receipt of such a request, you will be able to take the following steps to identify the customer responsible:
1. Identify the NAT router involved: This is relatively simple, assuming that all of your NAT routers have statically defined external IP addresses used to translate source addresses of outbound packets.
1. Identify the NAT router involved: This is relatively simple, assuming that all of your NAT routers have statically defined external IP addresses used to translate source addresses of outbound packets.
2. Identify the internal IP address involved: Refer to the CGNAT configuration on the identified NAT router. If you do not have an offline record documenting CGNAT source port range allocations for each NAT router, you can inspect the NAT table by logging on to the router identified and check the firewall configuration. In MikroTik Winbox, this detail can be found at IP -> Firewall -> NAT -> srcnat, for example:
3: Determine which customer was allocated that identified internal IP Address at the reported time: If your customers all have statically allocated internal IP addresses, this step is a simple matter of finding the customer that is allocated the private internal IP address identified. If, however, your customers are allocated an IP address that is dynamically allocated at the time of customer authentication to your network, you will need to discover which customer was allocated that address at the date and time reported by the requesting authority.
In most cases, an AAA solution like RADIUS will be employed for customer authentication, and the RADIUS accounting table data will contain a record of the dynamically allocated IP address for each connected session by every customer. To determine the customer, simply search through the radius accounting data to find which sessions have the reported IP address at the reported time.
If you are using the DuxTel Internet Commander, you can readily search for the customer session using Find Sessions tool under Tools and Reports menu:
Open the Find Sessions tool, enter the date of interest and IP address to search for (IPv4 and IPv6 addresses and address ranges are supported) then click on GO to search and display all matching sessions on the defined date. From this output, identifying the responsible customer will be apparent.
Open the Find Sessions tool, enter the date of interest and IP address to search for (IPv4 and IPv6 addresses and address ranges are supported) then click on GO to search and display all matching sessions on the defined date. From this output, identifying the responsible customer will be apparent.