8.2. NAT

Home Prev	cOS Core 14.00.15 Administration Guide	Next

Dynamic Network Address Translation (NAT) provides a mechanism for translating original source IP addresses to a different address. Outgoing packets then appear to come from a different IP address and incoming packets back to that address have their IP address translated back to the original IP address.

Methods of Configuring NAT in cOS Core

There are two ways of configuring NAT in the cOS Core IP rule set:

Using IP Policies

An IP Policy object can be added to the IP rule set with its Source Address Translation property set to NAT. This is the recommended method and makes it simpler to add other security mechanisms on the same IP rule set entry.

An alternative to setting the Source Translation property of an IP policy to NAT is to leave it at the default value of Auto. What this will do is perform NAT translation automatically if the source IPs are private addresses and the destination IPs are public addresses. The Auto option will not be discussed further in this section but a detailed description can be found in Section 8.5, Automatic Translation.
Using IP Rules

An IP Rule object can be added to the IP rule set with its Action property set to NAT. This method can be useful for compatibility with older cOS Core versions but does not provide any advantages over using an IP policy.

Examples of both these methods are included in this section.

NAT Benefits

NAT can have two important benefits:

The IP addresses of individual clients and hosts can be "hidden" behind the firewall's IP address.
Only the firewall needs a public IPv4 address for Internet access. Hosts and networks behind the firewall can be allocated private IPv4 addresses but can still have access to the Internet through the public IPv4 address.
In an Internet where there are ever fewer public IPv4 addresses available, NAT provides a way to multiplex multiple connections over a single IPv4 address. This is important at the enterprise level but also at the ISP level where two levels of NAT can be used to enable Carrier Grade NAT (CG-NAT).

NAT Provides many-to-one IP Address Translation

NAT provides many-to-one translation. This means that each NATing IP rule set entry can translate between several source IP addresses and a single source IP address.

To maintain session state information, each connection from dynamically translated addresses uses a unique port number and IP address combination as its sender. cOS Core performs automatic translation of the source port number as well as the IP address. In other words, the source IP addresses for connections are all translated to the same IP address and the connections are distinguished from one another by the allocation of a unique port number to each connection.

The diagram below illustrates the concept of NAT.

Figure 8.1. NAT IP Address Translation

In the illustration above, three connections from IP addresses A, B and C are NATed through a single source IP address N. The original port numbers are also changed.

The next source port number allocated for a new NAT connection will be the first free port selected randomly by cOS Core. Ports are allocated randomly to increase security.

Limitations on the Number of NAT Connections

Approximately 64,500 simultaneous NAT connections are possible if a "connection" is considered to be a unique pair of IP addresses and different port numbers are not used or the same destination port is used.

However, since there is a possible range of 64,500 source ports and the same number for destination ports, it is theoretically possible to have over 4 billion connections between two IP addresses if all ports are used.

Using NAT Pools Can Increase the Connections

To increase the number of NAT connections that can exist between the Clavister firewall and a particular external host IP, the cOS Core NAT pools feature can be used which can automatically make use of additional IP addresses on the firewall.

This is useful in situations where a remote server requires that all connections are to a single port number. In such cases, the 64,500 limit for unique IP address pairs will apply.

See Section 8.3, NAT Pools for more information about this topic.

The Source IP Address Used for Translation

There are three options for how cOS Core determines the source IP address that will be used for NAT:

Use the IP Address of the Interface

When a new connection is established, the routing table is consulted to resolve the outbound interface for the connection. The IP address of that resolved interface is then used as the new source IP address when cOS Core performs the address translation. This is the default way that the IP address is determined.
Specify a Specific IP Address

A specific IP address can be specified as the new source IP address. The specified IP address needs to have a matching ARP Publish entry configured for the outbound interface. Otherwise, the return traffic will not be received by the Clavister firewall. This technique might be used when the source IP is to differ based on the source of the traffic. For example, an ISP that is using NAT, might use different IP addresses for different customers.
Use an IP Address from a NAT Pool

A NAT Pool, which is a set of IP addresses defined by the administrator, can be used. The next available address from the pool can be used for NAT. There can be one or many NAT pools and a single pool can be used in more than one NAT rule. This topic is discussed further in Section 8.3, NAT Pools.

The NAT Translation Process

To explain the NAT process in a simple example, consider a protected client behind the firewall which has the private IP address 192.168.1.5. It wants to make an HTTP connection on port 80 of a server with the public IP 203.0.113.10.

The public IP of the cOS Core Ethernet interface connected to the Internet is 203.0.113.5 (for simplicity, assume that the interface and the server are on the same network). NAT translation is applied to connections originating on this interface by specifying a NATing IP rule set entry that allows connections from the client to the server.

The sequence of these events in the NAT process is illustrated in the diagram below and the description of steps that follows.

Figure 8.2. The NAT Translation Process

The sender at IP address 192.168.1.5 sends a packet from a dynamically assigned port number (assume port 1038) to the server at 203.0.113.10 on port 80.
```
		 => 
```
Assume that the IP policy NAT Outgoing Interface IP option is used. cOS Core will change the source port to a random unused port on its interface which is above port 1024. In this example, assume port 32,789 is chosen. The packet is then sent to its destination with this source port and the source IP of the interface.
```
		 => 
```
The server then processes the packet and sends its response back to the source IP and port.
```
		 => 
```
cOS Core receives the packet and looks up the destination IP and port in its list of open connections. If it finds the connection, it restores the original source IP address and port number and forwards the packet.
```
		 => 
```
The original sender has now received the response without needing a public IP address of its own.

Example 8.1. Setting Up NAT with an IP Policy

This example adds a NAT IP policy that will perform address translation for all HTTP traffic originating from the internal network lan flowing to the Internet on the wan interface. The IP address of the wan interface will be used as the NATing address for all connections.

Command-Line Interface

Device:/> add IPPolicy Name=nat_http
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=wan
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

The NATAction option could be left out since the default value is to use the interface address. The alternative is to specify UseSenderAddress and use the NATSenderAddress option to specify the IP address to use. The sender address will also need to be explicitly ARP published on the interface.

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Go to: Policies > Firewalling > Main IP Rules > Add > IP Policy
Now enter:
- Name: nat_http
- Action: Allow
Under Filter enter:
- Source Interface: lan
- Source Network: lan_net
- Destination Interface: wan
- Destination Network: all-nets
- Service: http
Under Source Translation enter:
- Address Translation: NAT
- Address Action: Outgoing Interface IP
Click OK

Logging is enabled by default.

Example 8.2. Setting Up NAT with an IP Rule

This example replicates the scenario in Example 8.1, “Setting Up NAT with an IP Policy” but this time uses an IP Rule object. This is included here to show an IP rule can be used. Using an IP Policy is the recommended method as it can provide more options that can be configured directly on the IP policy.

Command-Line Interface

Device:/> add IPRule Action=NAT
			SourceInterface=lan
			SourceNetwork=lan_net
			DestinationInterface=wan
			DestinationNetwork=all-nets
			Service=http-all
			NATAction=UseInterfaceAddress
			Name=NAT_HTTP

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Go to: Policies > Firewalling > Main IP Rules > Add > IP Rule
Specify a suitable name for the rule, for example NAT_HTTP
Now enter:
- Action: NAT
- Service: http-all
- Source Interface: lan
- Source Network: lan_net
- Destination Interface: wan
- Destination Network: all-nets
Under the NAT tab, make sure that the Use Interface Address option is selected
Click OK

Logging is enabled by default.

Protocols Handled by NAT

Dynamic address translation is able to deal with the TCP, UDP and ICMP protocols with a good level of functionality since the algorithm knows which values can be adjusted to become unique in the three protocols. For other IP level protocols, unique connections are identified by their sender addresses, destination addresses and protocol numbers.

This means that:

An internal machine can communicate with several external servers using the same IP protocol.
An internal machine can communicate with several external servers using different IP protocols.
Several internal machines can communicate with different external servers using the same IP protocol.
Several internal machines can communicate with the same server using different IP protocols.
Several internal machines cannot communicate with the same external server using the same IP protocol.

	Note: Restrictions only apply to IP level protocols
These restrictions apply only to IP level protocols other than TCP, UDP and ICMP, such as OSPF and L2TP. They do not apply to the protocols transported by TCP, UDP and ICMP such as telnet, FTP, HTTP and SMTP. cOS Core can alter port number information in the TCP and UDP headers to make each connection unique, even though such connections have had their sender addresses translated to the same IP.

Note: Restrictions only apply to IP level protocols

These restrictions apply only to IP level protocols other than TCP, UDP and ICMP, such as OSPF and L2TP. They do not apply to the protocols transported by TCP, UDP and ICMP such as telnet, FTP, HTTP and SMTP.

cOS Core can alter port number information in the TCP and UDP headers to make each connection unique, even though such connections have had their sender addresses translated to the same IP.

Some protocols, regardless of the method of transportation used, can cause problems during address translation.

Anonymizing Internet Traffic with NAT

A useful application of the NAT feature in cOS Core is for anonymizing service providers to anonymize traffic between clients and servers across the Internet so that the client's public IP address is not present in any server access requests or peer to peer traffic.

The typical case will be examined, where the firewall acts as a PPTP server and terminates the PPTP tunnel for PPTP clients. Clients that wish to be anonymous, communicate with their local ISP using PPTP. The traffic is directed to the anonymizing service provider where the firewall is installed to act as the PPTP server for the client, terminating the PPTP tunnel. This arrangement is illustrated in the diagram below.

Figure 8.3. Anonymizing with NAT

cOS Core is set up with NATing IP rule set entries so it takes communication traffic coming from the client and NATs it back out onto the Internet. Communication with the client is with the PPTP protocol but the PPTP tunnel from the client terminates at the firewall. When this traffic is relayed between the firewall and the Internet, it is no longer encapsulated by PPTP.

When an application, such as a web server, now receives requests from the client it appears as though they are coming from the anonymizing service provider's external IP address and not the client's IP. The application therefore sends its responses back to the firewall which relays the traffic back to the client through the PPTP tunnel. The original IP address of the client is not revealed in traffic as it is relayed beyond the termination of the PPTP tunnel at the cOS Core.

Typically, all traffic passes through the same physical interface and that interface has a single public IP address. Multiple interfaces could be used if multiple public IPv4 addresses are available. There is clearly a small processing overhead involved with anonymizing traffic but this need not be an issue if sufficient hardware resources are employed to perform the anonymizing.

This same technique can also be used with L2TP instead of PPTP connections. Both protocols are discussed further in Section 10.4.4, PPTP/L2TP Clients.