| Home Prev |  cOS Core 14.00.17 Administration Guide
|
Next |
|---|
Overview
Network Address Translation (NAT) provides a way to have multiple internal clients and hosts with unique private, internal IP addresses communicate to remote hosts through a single external public IPv4 address (this is discussed in depth in Section 8.2, NAT). When multiple public external IP addresses are available then a NAT Pool object can be used to allocate new connections across these public IPv4 addresses.NAT Pools are usually employed when there is a requirement for huge numbers of unique port connections. The cOS Core Port Manager has a limit of approximately 65,000 connections for a unique combination of source and destination IP addresses. Where large number of internal clients are using applications such as file sharing software, very large numbers of ports can be required for each client. The situation can be similarly demanding if a large number of clients are accessing the Internet through a proxy-server. The port number limitation is overcome by allocating extra external IP addresses for Internet access and using NAT Pools to allocate new connections across them.
Types of NAT Pools
A NAT Pool can be one of the following three types with each allocating new connections in a different way:The details of these three types are discussed next.
When the Stateful option is selected, cOS Core allocates a new connection to the external IP address that currently has the least number of connections routed through it with the assumption that it is the least loaded. cOS Core keeps a record in memory of all such connections. Subsequent connections involving the same internal client/host will then use the same external IP address.The advantage of the stateful approach is that it can balance connections across several external ISP links while ensuring that an external host will always communicate back to the same IP address which will be essential with protocols such as HTTP when cookies are involved. The disadvantage is the extra memory required by cOS Core to track the usage in its state table and the small processing overhead involved in processing a new connection.
To make sure that the state table does not contain dead entries for communications that are no longer active, a State Keepalive time can be specified. This time is the number of seconds of inactivity that must occur before a state in the state table is removed. After this period cOS Core assumes no more communication will originate from the associated internal host. Once the state is removed then subsequent communication from the host will result in a new state table entry and may be allocated to a different external IP address in the NAT Pool.
The state table itself takes up memory and it is possible to limit its size using the MaxStates property of a NAT Pool object. The state table is not allocated all at once but is incremented in size as needed. One entry in the state table tracks all the connections for a single host behind the Clavister firewall no matter which external host the connection concerns.
If the MaxStates value is reached, the state table entry with the longest idle time is replaced. If all entries in the table are active, a random entry is replaced. A max_states_reached log message is generated to indicate that the maximum has been reached.
As a rule of thumb, the MaxStates value should be at least the number of local hosts or clients that will be expected to connect to using the pool.
Stateless NAT Pools
The Stateless option means that no state table is maintained and the external IP address chosen for each new connection is the one that has the least connections already allocated to it. This means two connections between one internal host to the same external host may use two different external IP addresses.The advantage of a Stateless NAT Pool is that there is good spreading of new connections between external IP addresses with no requirement for memory allocated to a state table and there is also less processing time involved in setting up each new connection. The disadvantage is that it is not suitable for communication that requires a constant external IP address.
Fixed NAT Pools
The Fixed option means that each internal client or host is allocated one of the external IP addresses through a hashing algorithm. Although the administrator has no control over which of the external connections will be used, this scheme ensures that a particular internal client or host will always communicate through the same external IP address.The Fixed option has the advantage of not requiring memory for a state table and providing very fast processing for new connection establishment. Although explicit load balancing is not part of this option, there should be spreading of the load across the external connections due to the random nature of the allocating algorithm.
IP Pool Usage
When allocating external IP addresses to a NAT Pool it is not necessary to explicitly state these. Instead, an IP Pool object can be selected in cOS Core. IP Pools gather collections of IP addresses automatically through DHCP and can therefore supply external IP addresses automatically to a NAT Pool. See Section 5.5, IP Pools for more details about this topic.Proxy ARP Usage
Where an external router sends ARP queries to the Clavister firewall to resolve external IP addresses included in a NAT Pool, cOS Core will need to send the correct ARP replies for this resolution to take place through its Proxy ARP mechanism so the external router can correctly build its routing table.By default, the administrator must specify in NAT Pool setup which interfaces will be used by NAT pools. The option exists however to enable Proxy ARP for a NAT Pool on all interfaces but this can cause problems sometimes by possibly creating routes to interfaces on which packets should not arrive. It is therefore recommended that the interface(s) to be used for the NAT Pool Proxy ARP mechanism are explicitly specified.
Using NAT Pools
NAT Pools are used in conjunction with a normal NAT IP rule. When defining a NAT rule, the dialog includes the option to select a NAT Pool to use with the rule. This association brings the NAT Pool into use.Example 8.3. Using NAT Pools
This example creates a stateful NAT pool with the external IP address range 10.6.13.10 to 10.16.13.15. This is then used with a NAT IP rule for HTTP traffic on the wan interface originating from the lan_net.
Note that if a network such as 10.6.13.0/24 is used for the NAT pool IP range, the 0 and 255 addresses (10.6.13.0 and 10.6.13.255) are automatically excluded from the range.
Command-Line Interface
A. First, create an object in the address book for the address range:
Device:/> add Address IP4Address nat_pool_range
Address=10.6.13.10-10.16.13.15B. Next, create a stateful NAT Pool object called my_stateful_natpool :
Device:/> add NatPool my_stateful_natpool
Range=nat_pool_range
Type=Stateful
ProxyARPInterfaces=wanC. Finally, define the NAT rule in the IP rule set:
Device:/> add IPRule Action=NAT
SourceInterface=lan
SourceNetwork=lan_net
DestinationInterface=wan
DestinationNetwork=all-nets
Service=http-all
NATAction=UseNATPool
NATPool=my_stateful_natpool
Name=NAT_HTTPInControl
Follow similar steps to those used for the Web Interface below.
Web Interface
A. First, create an object in the address book for the address range:
B. Next, create a stateful NAT Pool object called my_stateful_natpool :
C. Finally, define the NAT rule in the IP rule set:
