Network Address Translation Overview


Network Address Translation Overview
 
 
This chapter provides an overview of Network Address Translation (NAT) in-line service feature.
The following topics are covered in this chapter:
 
 
Supported Platforms and Products
NAT is an in-line service feature supported on the Cisco ASR 5000 chassis running 3GPP, 3GPP2, and LTE core network services (PDSN, HA, GGSN, and P-GW).
Important: For information on ASR 5000, please refer to the Product Overview Guide.
 
Licenses
 
NAT is a licensed in-line service feature requiring the following licenses:
 
[ 600-00-7805 ] NAT/PAT With DPI
Important: For information on license requirements for any customer-specific features, please contact your local sales/service representative.
Important: For information on installing licenses, see the Managing License Keys chapter of the System Administration and Configuration Guide.
 
Supported Standards
The NAT feature supports the following RFCs:
 
 
 
NAT Feature Overview
This section provides an overview of the NAT in-line service feature.
NAT translates non-routable private IP address(es) to routable public IP address(es) from a pool of public IP addresses that have been designated for NAT. This enables to conserve on the number of public IP addresses required to communicate with external networks, and ensures security as the IP address scheme for the internal network is masked from external hosts, and each outgoing and incoming packet goes through the translation process.
NAT works by inspecting both incoming and outgoing IP datagrams and, as needed, modifying the source IP address and port number in the IP header to reflect the configured NAT address mapping for outgoing datagrams. The reverse NAT translation is applied to incoming datagrams.
NAT can be used to perform address translation for simple IP and mobile IP. NAT can be selectively applied/denied to different flows (5-tuple connections) originating from subscribers based on the flows' L3/L4 characteristics—Source-IP, Source-Port, Destination-IP, Destination-Port, and Protocol.
Important: NAT works only on flows originating internally. Bi-directional NAT is not supported.
Important: NAT is supported only for TCP, UDP, and ICMP flows. For other flows NAT is bypassed. For GRE flows, NAT is supported only if the PPTP ALG is configured. For more information on ALGs, please refer to the NAT Application Level Gateway section.
Important: If a subscriber is assigned with a public IP address, NAT is not applied.
Important: To get NATed, the private IP addresses assigned to subscribers must be from the following ranges: Class A 10.0.0.0 – 10.255.255.255, Class B 172.16.0.0 – 172.31.255.255, and Class C 192.168.0.0 – 192.168.255.255
NAT supports the following mappings:
 
When a private IP address (IP1:port1) is mapped to a public IP address (IP2:port1), any packets from IP1:port1 will be sent as though via IP2:port1. The external host can only send packets to IP2:port1, which are translated to IP1:port1. The NAT port number will be the same as the source private port.
 
Once a flow is marked to use a specific NAT IP address the same NAT IP address is used for all packets originating on that flow. The NAT IP address is released only when all flows and subscribers associated with it are released.
When all NAT IP addresses are in use, and a subscriber with a private IP address fails to get a NAT IP address for a specific flow, that specific flow will not be allowed and will fail.
All downlink—inbound from external networks—IP packets that do not match one of the existing NAT bindings are discarded by the system.
 
NAT Realms
A NAT realm is a pool of unique public IP addresses available for translation from private source IP addresses. IP addresses in a NAT IP pool are contiguous, and assignable as a subnet or a range that constitutes less than an entire subnet. IP addresses configured in NAT IP pools within a context must not overlap. At any time, within a context, a NAT IP address must be configured in any one NAT IP pool. IP addresses can be added to a NAT IP pool as a range of IP addresses.
Important: The minimum number of public IP addresses that must be allocated to each NAT IP pool must be greater than or equal to the number of Session Managers (SessMgrs) available on the system. On the ASR 5000, it is >= 84 public IP addresses. This can be met by a range of 84 host addresses from a single Class C. The remaining space from the Class C can be used for other allocations. Each address has available its port range ~64K ports.
Up to 2000 unique “IP pools + NAT IP pools” can be configured per context. A maximum of three NAT IP pools/NAT IP pool groups can be configured in a Firewall-and-NAT policy. At any time a subscriber can be associated with a maximum of three different NAT IP pools/NAT IP pool groups and can have NATed flows on three different NAT IP addresses at the same time.
Allocation of NAT IP addresses in NAT IP pools to subscriber traffic is based on the L3/L4 characteristics—IP addresses, ports, and protocol—of the subscriber flows. It is possible to configure the system to perform or not perform NAT based on one or more L3/L4 parameters. This feature is also known as Target-based NAT. For more information, see the Target-based NAT Configuration section.
NAT IP pools have the following configurable parameters. These parameters are applicable to all IP addresses in a NAT IP pool.
 
In case of on-demand pools, since the NAT IP address is not allocated to the subscriber at call setup, the subscriber may not have a NAT IP address allocated when the first packet is received. Until the successful allocation of a NAT IP address, based on the configuration, the packets can either be buffered or dropped. Once a free NAT IP address is available, it is allocated to the subscriber to be used for flows matching the pool.
Consider a case where a single TCP flow is active in a port-chunk. When this connection gets cleared, the TCP NAT port goes to Time Wait state. Since it is the last flow of the port-chunk, the NAT Binding Timer also gets started. Assume NAT Binding Timer >= TCP 2MSL Timer. Once the 2MSL Timer expires, the TCP port would go to Free state. However, the NAT Binding Timer keeps running. On NAT Binding Timer expiry, the port-chunk is deallocated. If this was the last port-chunk for that subscriber, the NAT IP address is also deallocated along with this port-chunk.
In case NAT Binding Timer < TCP 2MSL Timer, at NAT Binding Timer expiry, the TCP port is forcefully moved to Free state from Time Wait state and the port-chunk deallocated.
 
NAT IP Pool Groups
Similar NAT IP pools can be grouped into NAT IP pool groups. This enables to bind discontiguous IP address blocks in individual NAT IP pools to a single NAT IP pool group.
When configuring a NAT IP pool group, note that only those NAT IP pools that have similar characteristics can be grouped together. The similarity is determined by the NAT IP pool Type (One-to-One / Many-to-One), users configured per NAT IP address (applicable only to many-to-one NAT IP pools), NAT IP Address Allocation Mode (On-demand/Not-on-demand), and Port Chunk Size (applicable only to many-to-one NAT IP pools) parameters. Dissimilar NAT IP pools cannot be grouped together.
It is recommended that all the NAT IP pools in a NAT IP pool group be configured with the same values for the other parameters, so that the NAT behavior is predictable across all NAT IP pools in that NAT IP pool group.
The NAT IP pool from which a NAT IP address is assigned will determine the actual values to use for all parameters.
It is recommended that in a Firewall-and-NAT policy all the realms configured either be NAT IP pools or NAT IP pool groups. If both NAT IP pool(s) and NAT IP pool group(s) are configured, ensure that none of the NAT IP pool(s) are also included in the NAT IP pool group.
 
NAT IP Address Allocation and Deallocation
 
Cisco System’s implementation of NAPT is Endpoint-independent Mapping, wherein NAT reuses the same NAT source port mapping for subsequent packets sent from the same private IP address and port, and with the same protocol to any public destination host IP address and port.
That is, all flows coming from the subscriber for the current session with the same protocol and same source IP address and source port (X:x) would get the same NAT IP address and NAT port (X:x) irrespective of the destination IP address and port. NAT will not allow any inbound packets to the NAT IP address and NAT port (X:x) from an external host IP address and host port (Y:y), unless the internal host (MS) had previously sent a packet of the same protocol type to that external IP address and Port (Y:y). However, this behavior changes if NAT ALG is enabled. The ALG creates pin holes / dynamic routes in the NAT and allows downlink packets that match the pin holes / dynamic routes towards the internal host (MS) given that there was already a parent connection from MS towards the external host.
The advantage of endpoint-independent mapping is that applications are unaffected by NAT translations.
Inbound connection to the NAT IP address can be allowed in one-to-one pools based on configuration.
 
NAT IP Address Allocation
 
The NAT IP address is allocated based on the following parameters:
 
 
NAT IP Address Deallocation
Whenever a NAT IP address is deallocated, all the port-chunks associated with the subscriber are released back to the pool.
 
In case there is only one port-chunk associated with the subscriber:
 
 
NAT Port-chunk Allocation and Deallocation
This section describes the Port-chunk Allocation and Deallocation feature for many-to-one NAT.
 
NAT Port-chunk Allocation
Subscribers sharing a NAT IP address are allocated NAT ports in chunks. The ports in a port-chunk are always used for the subscriber to whom that port-chunk is allocated irrespective of the protocol.
Whenever a NAT IP address gets allocated to a subscriber, the first port-chunk gets allocated along with the NAT IP address. Thus, for not-on-demand pools, the first port-chunk gets allocated during call setup, and for on-demand pools during data flow.
A subscriber’s TCP and UDP data traffic is NATed with ports chosen in a random fashion from the port-chunk allocated to that subscriber. For other protocol traffic, the first available port is allocated. When all the ports in a port-chunk are in use, a free port-chunk is requested for. A new port-chunk is only allocated if the “Maximum Port-chunks Per User” limit is not reached.
 
NAT Port-chunk Deallocation
A port-chunk gets deallocated in the following cases:
 
 
NAT Binding Timer
When all flows using ports from a particular port-chunk get timed out/cleared, the port-chunk gets freed. When the last port of that port-chunk gets freed, the NAT Binding Timer starts counting. Before the NAT Binding Timer expires, if any new flows come up, ports are reallocated from the port-chunk, and the timer gets cancelled. The port-chunk cannot be deallocated as long as there are active flows using that port-chunk. But, if no new flows come and the NAT Binding Timer expires, the port-chunk gets deallocated.
In case of not-on-demand pools, the additional port-chunks that were allocated on demand will be deallocated based on the NAT binding timeout. However, the last port-chunk will not be deallocated even after the Binding Timer expires. This last port-chunk will only be deallocated when the NAT IP address is deallocated from the subscriber.
In case of on-demand pools, the port-chunks are deallocated based on the NAT binding timeout. When the last port-chunk gets freed, the NAT IP address also gets deallocated from the subscriber.
It is ensured that a port-chunk is associated with the subscriber as long as a valid NAT IP address is allocated to the subscriber.
 
Subscriber Session Disconnect
When a subscriber disconnects, all port-chunks associated with that subscriber are freed.
If the NAT Binding Timer has not expired, the port-chunks will not be usable immediately, only on NAT Binding Timer expiry will the port-chunks become available for new subscribers.
 
NAT IP Address/Port Allocation Failure
When a packet cannot be translated, the application can be notified by way of ICMP error messages, if configured. Translation failures may be due to no NAT IP address or port being available for translation.
Important: In the case of P-GW, NAT IP Address/Port Allocation Failure notification is not applicable.
 
TCP 2MSL Timer
NAT does port management only for many-to-one pools. Hence, The TCP 2MSL timer is only available for many-to-one NAT. It is necessary to ensure that a TCP NAT port in Time Wait state is not reused if there are other free ports available for the subscriber. If such a reuse happens, then there is a possibility that connections might get terminated by the server. To avoid such issues, whenever a many-to-one NAT TCP flow gets cleared, the NAT port goes to Time Wait state (2MSL started for that port). Once 2MSL timer expires, the NAT port becomes usable. The 2MSL timer is started for every TCP NAT port as soon as the TCP connection gets cleared. This ensures that a NAT TCP port gets reused only after expiry of the configured TCP 2MSL timer.
 
Consider a case where a single TCP flow is active in a port-chunk. When this connection gets cleared, the TCP NAT port goes to Time Wait state. Since this is the last flow of the port-chunk, the NAT Binding Timer also gets started. Assume NAT Binding timer >= TCP 2MSL timer. Once the 2MSL timer expires, the TCP port becomes usable. However, the NAT Binding Timer keeps counting, and on expiry, the port-chunk is released.
In case the NAT Binding Timer < TCP 2MSL Timer, on NAT Binding Timer expiry, the TCP port is forcefully moved to Free State (made usable) from Time Wait state and the port-chunk released.
 
NAT Binding Records
Whenever a NAT IP address or NAT port-chunk is allocated/deallocated to/from a subscriber, NAT Binding Records (NBR) can be generated. Generation of NBRs is configurable in the Firewall-and-NAT policy configuration.
 
NBRs are supported for both on-demand and not-on-demand NAT IP pools. For a one-to-one NAT IP pool, an NBR is generated whenever a NAT IP address is allocated/deallocated to/from a subscriber. For a many-to-one NAT IP pool, an NBR is generated when a port-chunk is allocated/deallocated to/from a subscriber for a NAT IP address. It is also possible to configure generation of NBRs only when a port-chunk is allocated, or deallocated, or in both cases.
The following is the list of attributes that can be present in NBRs. You can configure a subset of these attributes or all of them to be logged in NBRs. If an attribute is not available, while logging records that field is populated with NULL.
 
 
NAT Binding Updates
Whenever a NAT IP address or NAT port-chunk is allocated/deallocated to/from a subscriber, to update NAT binding information for that subscriber in the AAA, a NAT Binding Update (NBU) can be sent to the AAA server.
Important: In the case of P-GW, NBUs is not applicable since it does not use RADIUS.
Since port-chunk allocation/deallocation happens on a per-call basis, this ensures that AAA messaging is reduced to a great extent. NBUs are sent to the AAA server in accounting-interim messages. To send or not to send NBUs to the AAA server is configurable in the NAT IP pool configuration.
NBUs are supported for both one-to-one and many-to-one NAT IP pools.
An NBU contains the following attributes:
 
 
CoA NAT Query
If the NAT binding information is not available at the AAA, the AAA server can query the chassis for the information. This query uses the Change of Authorization (CoA) format, wherein the AAA sends a one-to-one NAT IP address as a query, and in the CoA query response the NBU is obtained if available at the time of query.
Important: In this release, CoA query for NAT binding information is only supported for one-to-one NAT.
The CoA query request must contain the following attributes:
 
Important: For SN1-NAT-IP-Address, this release supports VSA-Type values 0 and 1.
For a successful query, the CoA ACK response contains the following attributes:
 
Important: For information on the AVPs/VSAs, please refer to the AAA Interface Administration and Reference.
 
Firewall-and-NAT Policy
Firewall-and-NAT policies are configured in the CLI Firewall-and-NAT Policy Configuration Mode. Each policy contains a set of access ruledefs with priorities and actions, and the NAT configurations. On a system, multiple such policies can be configured, however at any point of time only one policy is associated to a subscriber.
 
Important: In StarOS 8.x, NAT for CDMA and early UMTS releases used rulebase-based configurations, whereas in later UMTS releases NAT used policy-based configurations. In StarOS 9.0 and later releases, NAT for UMTS and CDMA releases both use policy-based configurations. For more information, please contact your local service representative.
Important: In a Firewall-and-NAT policy, a maximum of three NAT IP pools/NAT IP pool groups can be configured. A subscriber can be allocated only one NAT IP address per NAT IP pool/NAT IP pool group, hence at anytime, there can only be a maximum of three NAT IP addresses allocated to a subscriber.
New NAT IP pools/NAT IP pool groups cannot be added to a policy if the maximum allowed is already configured in it. However, a pool/pool group can be removed and then a new one added. When a pool/pool group is removed and a new one added, the pool/pool group that was removed will stay associated with the subscriber as long as the subscriber has active flows using that pool/pool group. If the subscriber is already associated with three NAT IP pools (maximum allowed), any new flows from that subscriber for the newly added pool will be dropped. A deleted pool is disassociated from the subscriber on termination of all flows from that subscriber using that pool. The new pool/pool group is associated with the subscriber only when the subscriber sends a packet to the newly added pool.
In the Firewall-and-NAT policy configuration, the NAT policy must be enabled. Once NAT is enabled for a subscriber, the NAT IP address to be used is chosen from the NAT IP pools/NAT IP pool groups specified in matching access rules configured in the Firewall-and-NAT policy.
The Firewall-and-NAT policy used for a subscriber can be changed either from the command line interface, or through dynamic update of policy name in Diameter and RADIUS messages. In both the cases, NAT status on the active call remains unchanged.
The Firewall-and-NAT policy to be used for a subscriber can be configured in:
 
Important: The Firewall-and-NAT policy received from the AAA and OCS have the same priority. Whichever comes latest, either from AAA/OCS, is applied.
The Firewall-and-NAT policy to use can also be received from RADIUS during authentication.
 
Disabling NAT Policy
Important: By default, NAT processing for subscribers is disabled.
NAT processing for subscribers is disabled in the following cases:
 
 
Updating Firewall-and-NAT Policy in Mid-session
The Firewall-and-NAT policy can be updated mid-session provided the policy was enabled during call setup.
Important: When the firewall AVP contains “disable” during mid-session firewall policy change, there will be no action taken as the Firewall-and-NAT policy cannot be disabled dynamically. The policy currently applied will continue.
Important: For all NAT-enabled subscribers, when the Firewall-and-NAT policy is deleted, the call is dropped.
In a Firewall-and-NAT policy, you can change the NAT enabled/disabled status at any time. However, the updated NAT status will only be applied to new calls, active calls using that Firewall-and-NAT policy will remain unaffected.
 
Target-based NAT Configuration
A NAT IP pool can be selected based on the L3/L4 characteristics of a subscriber’s flows. NAT can be configured such that all subscriber traffic coming towards specific public IP address(es) always selects a specific NAT IP pool based on the L3/L4 traffic characteristics.
 
Important: A subscriber can be allocated only one NAT IP address per NAT IP pool/NAT IP pool group from a maximum of three NAT IP pools/NAT IP pool groups. Hence, at anytime, there can only be a maximum of three NAT IP addresses allocated to a subscriber.
This association is done with the help of access ruledefs configured in the Firewall-and-NAT policy. The NAT IP pool/NAT IP address to be used for a subscriber flow is decided during rule match. When packets match an access ruledef, NAT is applied using the NAT IP address allocated to the subscriber from the NAT IP pool/NAT IP pool group configured in that access ruledef.
If no NAT IP pool/NAT IP pool group name is configured in the access ruledef matching the packet, and if there is a NAT IP pool/NAT IP pool group configured for “no ruledef matches”, a NAT IP address from the NAT IP pool/NAT IP pool group configured for “no ruledef matches” is allocated to the flow.
If no NAT IP pool/NAT IP pool group is configured for “no ruledef matches” and if there is a default NAT IP pool/NAT IP pool group configured in the rulebase, a NAT IP address from this default NAT IP pool/NAT IP pool group is allocated to the flow.
If a NAT IP pool/NAT IP pool group is not configured in any of the above cases, no NAT will be performed for the flow. Or, if bypass NAT is configured in a matched access rule or for “no ruledef matches” then NAT will not be applied even if the default NAT IP pool/NAT IP pool group is configured. The order of priority is:
 
1.
2.
3.
4.
When a new NAT IP pool/NAT IP pool group is added to a Firewall-and-NAT policy, it is associated with the active subscriber (call) only if that call is associated with less than three (maximum limit) NAT IP pools/NAT IP pool groups. If the subscriber is already associated with three NAT IP pools/NAT IP pool groups, any new flows referring to the newly added NAT IP pool/NAT IP pool group will get dropped. The newly added NAT IP pool/NAT IP pool group is associated to a call only when one of the previously associated NAT IP pools/NAT IP pool groups is freed from the call.
 
NAT Application Level Gateway
Some network applications exchange IP/port information of the host endpoints as part of the packet payload. This information is used to create new flows, by server or client.
As part of NAT ALGs, the IP/port information is extracted from the payload, and the flows are allowed dynamically (through pinholes). IP and port translations are done accordingly. However, the sender application may not be aware of these translations since these are transparent, so they insert the private IP or port in the payload as usual.
For example, FTP NAT ALG interprets “PORT” and “PASV reply” messages, and NAT translates the same in the payload so that FTP happens transparently through NAT. This payload-level translation is handled by the NAT ALG module.
The NAT module will have multiple NAT ALGs for each individual application or protocol.
 
Supported NAT ALGs
This release supports NAT ALGs only for the following protocols:
 
For NAT ALG processing, in the rulebase, routing rules must be configured to route packets to the corresponding analyzers.
 
EDRs and UDRs
This section describes the NAT-specific attributes supported in EDRs and UDRs.
 
EDRs
The following NAT-specific attributes are supported in regular EDRs:
 
 
 
UDRs
The following NAT-specific attribute is supported in regular UDRs:
sn-subscriber-nat-flow-ip: NAT IP addresses that are being used by NAT-enabled subscribers. The NAT IP addresses assigned from each of the associated pool for the call are logged. A space is used as a separator between individual IP addresses.
 
Bulk Statistics
NAT bulkstats are per context and per NAT realm. The NAT realms are configured in a context and statistics are stored per context per realm. These statistic variables, both cumulative and snapshot, are available in the nat-realm schema.
Bulkstats are only generated for the first 100 NAT IP pools from an alphabetical list of all NAT IP pools, which is based on the context name and pool name. Therefore, to generate bulkstats for a specific NAT IP pool it must be named such that it gets selected in the first 100 bulkstats.
The following are cumulative statistics that can be part of NAT bulkstats:
 
The following are snapshot statistics that can be part of NAT bulkstats:
 
 
Alarms
Alert threshold values can be specified to generate alarms for NAT IP pools. To specify realm-specific threshold limits (pool-used, pool-free, pool-release, and pool-hold) “alert-threshold” NAT IP pool parameter can be used, or it can also be specified across context. These thresholds can be specified to any number of NAT IP pools.
In case of many-to-one NAT, it is possible to specify port-chunks usage threshold per NAT IP pool. This threshold value is applicable to all many-to-one NAT IP pools across the system. However, note that alarms are only generated for the first 100 many-to-one NAT IP pools from an alphabetical list of all NAT IP pools.
 
Session Recovery and ICSR
In session recovery, as part of the Private IP assigned to the subscriber:
 
To be recovered the NAT IP addresses need to be checkpointed. The checkpointing can be:
 
To recover the bypass NAT flow, the bypass flow needs to be checkpointed. The checkpointing of Bypass NAT flow can be:
 
In case of not-on-demand, the NAT IP address being used by the subscriber is known after call setup. This gets checkpointed as part of the normal full checkpoint. In case of on-demand NAT, the NAT IP address being used by the subscriber is known only in the data-path. This will be checkpointed as part of micro checkpoint.
In case of many-to-one NAT, the port-chunks being used will always be checkpointed as part of micro checkpoint.
In case of bypass NAT flow, in most cases the flow gets checkpointed as part of micro checkpoint.
Any information that is checkpointed as part of full checkpoint is always recovered. Data checkpointed through micro checkpoint cannot be guaranteed to be recovered. The timing of switchover plays a role for recovery of data done through micro checkpoint. If failover happens after micro checkpoint is completed, then the micro checkpointed data will get recovered. If failover happens during micro checkpoint, then the data recovered will be the one obtained from full checkpoint.
Once NAT IP/and Port-Chunks/Bypass NAT flow are recovered, the following holds good:
 
All of the above items is applicable for ICSR as well.
For more information, in the System Enhanced Feature Configuration Guide, see the Session Recovery and Interchassis Session Recovery chapters.
 
How NAT Works
 
The following steps describe how NAT works:
Step 1
 
Step 2
Important: The private IP addresses assigned to subscribers must be from the following ranges for them to get translated: Class A 10.0.0.0 – 10.255.255.255, Class B 172.16.0.0 – 172.31.255.255, and Class C 192.168.0.0 – 192.168.255.255
Important: A subscriber can be allocated only one NAT IP address per NAT IP pool/NAT IP pool group from a maximum of three pools/pool groups. Hence, at any point, there can be a maximum of three NAT IP addresses allocated to a subscriber.
Step 3
 
The following figures illustrate the flow of packets in NAT processing.
 
NAT Processing Flow
 
... NAT Processing Flow
 
... NAT Processing Flow
 
... NAT Processing Flow
 
 
 

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883