Contents

1   Overview

This document provides an overview of the Network Address Translation (NAT) policy features supported by the SmartEdge® router and describes the tasks used to configure, monitor, and administer NAT policy. This document also provides configuration examples of NAT policy.

Through NAT, hosts using unregistered IP addresses on an internal, private network can connect to hosts on the Internet, and conversely. NAT translates the private (not globally unique) addresses in the internal network into public IP addresses before packets are forwarded onto another network. Network Address and Port Translation (NAPT) translates a private network and its Transmission Control Protocol/User Datagram Protocol (TCP/UDP) port on the internal network into a public address and its TCP/UDP ports. By using port multiplexing, NAPT enables multiple hosts on a private network to simultaneously access remote networks through a single IP address.

NAT policies can contain a combination of static and dynamic translation actions as well as drop and ignore actions, and can be applied to all packets traveling across a circuit, or to a particular class of packets using policy access control list (ACL). The default NAT policy action is drop.

Note:  

NAT policies are not supported for subscriber sessions that use the Layer 2 Tunneling Protocol (L2TP) and that are terminated at the SmartEdge router when it is acting as an L2TP network server (LNS). If you inadvertently apply a NAT policy to such a subscriber, the session comes up because the policy has no effect on it.

Figure 1 illustrates how NAT translates private source IP addresses to public addresses.

The SmartEdge 800 router supports traditional NAT. In traditional NAT, sessions are unidirectional, outbound from the private network. Sessions in the opposite direction may be allowed on an exception basis, using static address maps for preselected hosts. It is assumed that NAT policies are applied on private interfaces only because applying them on public interfaces would profoundly affect performance.

Note:  

Traditional NAT is also known as source NAT or SNAT.

Note:  

In this document, the terms, incoming and outgoing, refer to the direction of the packets passing through the interface. The terms, outbound and inbound, refer to the direction of the packet flow from the private network to the public network, and from the public network to the private network, respectively.

The SmartEdge router implementation of NAT is described in the following sections.

1.1   Static Translation

With static translation, the private source IP addresses and TCP or UDP ports and the NAT addresses and the ports to which they are translated are fixed numbers.

Note:  

When just the IP address is translated, static NAT is referred to as basic static NAT. Static NAT includes both basic static NAT and static NAPT.

Note:  

Static translations require manual configuration of the static IP routes and the static IP ARP entries for the NAT addresses.

1.2   Dynamic Translation

With dynamic translation, the SmartEdge router translates the private source IP addresses and TCP or UDP ports to the NAT addresses and ports. At runtime, the SmartEdge router selects the NAT addresses and ports from a pool of global IP addresses (referred to as a NAT pool). With dynamic translation, you can also modify the period after which translations time out.

NAPT also supports dynamic translation of subsets of TCP/UDP ports, referred to as port blocks. The port number space of the TCP/UDP ports is divided into 16 port blocks, numbered 0 to 15; each port block consists of 4,096 port numbers. Port block granularity allows the sharing of a single IP address between NAT pools, and thus between NAT policies and traffic cards, with each pool having the IP address with a unique subset of TCP/UDP port blocks assigned to it.

Note:  

When just the IP address is translated, dynamic NAT is referred to as basic dynamic NAT. Dynamic NAT includes both basic dynamic NAT and dynamic NAPT.

1.3   Policy ACLs

A policy ACL defines classes of packets using classification statements (rules). Each policy ACL supports up to eight unique classes. You can classify a packet according to its IP precedence value, protocol number, IP source and destination address, Internet Control Message Protocol (ICMP) attributes, Internet Group Management Protocol (IGMP) attributes, TCP attributes, and UDP attributes.

When you include the destination, drop, ignore, pool, admission-control, and timeout commands (in NAT policy configuration mode) in a NAT policy, the specified action is applied to all packets traveling across the interface or subscriber circuit or, if an ACL is referenced, to packets that do not belong to the classes specified by the ACL and by the NAT policy. These packets are referred to as belonging to the default class.

When you include the destination, drop, ignore, pool, admission-control, and timeout commands (in class configuration mode) in a policy ACL, the specified action is applied only to packets belonging to the specified class.

Note:  

The pool and timeout commands apply only to dynamic NAT. The admission-control and destination commands apply only to dynamic NAPT.

To configure class-based actions for a circuit, you apply a policy ACL to a NAT policy, specify the action for each class that you want the policy to take, and then attach the NAT policy to the circuit. For more information about policy ACLs, see Configuring ACLs.

1.4   Destination IP Address Translation

The SmartEdge router allows you to configure a NAT policy or its class to use a specified destination IP address instead of the original destination IP address. Using the destination command, you can configure Destination NAT (DNAT) to redirect traffic destined for the original address to a different specified address. On the return path, the source address of the incoming traffic is translated to the original destination address of the outgoing packet, so the returning traffic appears to be sent from the original destination address.

You can enable DNAT with or without the SmartEdge router having to perform NAT.

You can use DNAT both with and without NAT in the same configuration.

1.5   NAT DMZ

The SmartEdge router also provides support for the demilitarized zone (DMZ) feature in NAT policies. You can configure a DMZ rule in a NAT policy to translate traffic returning to the SmartEdge router that does not satisfy any of the conditions for static or dynamic NAT that you have specified in that NAT policy. The basic NAT specified by the DMZ rule changes the destination IP address of the packet to a fixed private IP address of a DMZ host server without changing the TCP/UDP port number.

Three types of applications might require a DMZ host server:

• You use your own tools to do extensive logging and analysis of the packets that would be dropped by the NAT policy.
• You do not know the exact TCP/UDP port numbers, or there are too many ports, that need to be opened by static NAPT rules to allow access to applications.
• You need a work around for applications that do not work with NAPT, because they use protocols other than UPD or TCP, or require IP packet fragmentation.

The following differences apply to a private network with a DMZ host server:

• A DMZ rule in a NAT policy does not affect non-DMZ hosts on the internal network that use static or dynamic NAPT, except that returning traffic for dynamic UDP sessions are now subject to source IP address verification.
• Non-DMZ hosts can use basic static or basic dynamic NAT, although such configurations might not seem practical.
• The DMZ host server cannot use basic static NAT, basic dynamic NAT, and dynamic NAPT, but can still use static NAPT.

1.6   Session Limit Control

Session limit control allows you to set session limits independently for TCP, UDP, and ICMP sessions from the subscriber to the network. The SmartEdge 800 router does not limit sessions from the network to the subscriber.

Note:  

In this document, the terms, session and connection, refer to a request to establish a connection between a subscriber port (that is, an IP address and port tuple) and a host port (represented by an IP address and port tuple). These requests can be initiated from a subscriber or from a host, but you can only enable the SmartEdge router to limit the requests initiated by the subscriber or initiated on another system, sent to the subscriber, and accepted by that subscriber.

When multiple sessions are initiated from the same IP address and port number on the subscriber side, they are counted as a single connection by the operating system.

The following restrictions apply to the NAT implementation of session limit control:

• Session limit control is a modification of a NAT policy; it applies to any circuit that has that NAT policy attached.
• Session limit control is supported on Ethernet, Gigabit Ethernet, and ATM OC-3 traffic cards.
• The SmartEdge router applies the session limit at the IP level; it is available for LNS circuits, but not when the SmartEdge router is configured as an L2TP access concentrator (LAC).
• You can set a session limit to support up to 65,535 sessions on a circuit.

  Note:  

  The sum of the configured session limit control numbers for a traffic card can exceed the maximum number of sessions (approximately one million) allowed by the amount of memory on the traffic card. In that case, some circuits might be unable to reach their configured maximum session limit.

  
  

1.7   NAT and Point-to-Multipoint UDP Traffic

The SmartEdge router supports point-to-multipoint (P2MP) scenarios using Endpoint-Independent Filtering, as described in RFC 4787, Network Address Translation (NAT) Behavioral Requirements for Unicast UDP, REQ 8. P2MP traffic is common in many applications, such as multimedia communications and online gaming: in these scenarios, an internal host initiates multiple simultaneous sessions from a single endpoint (which is defined by its private IP address, private port, and UDP port) and sends it to multiple distinct endpoints on the external network.

The SmartEdge router allows Endpoint-Independent Filtering to be applied at the class level within a NAT policy, so that P2MP traffic can be enabled for selected UDP traffic streams. Alternatively, Endpoint-Independent Filtering can be applied to the default class, at the policy level. Endpoint-Independent Filtering is not supported for TCP traffic.

To enable Endpoint-Independent Filtering on UDP traffic, issue the endpoint-independent filtering udp command (in NAT policy or NAT policy class configuration mode), specifying either an existing address pool (using the pool command) or the "ignore" action (using the ignore command).

You cannot enable Endpoint-Independent Filtering with an action of "drop"; if you configure an action of "drop" for the class, the system returns a warning. If you do configure an action of "drop" for the class, the system disables Endpoint-Independent Filtering.

Similarly, you cannot use Endpoint-Independent Filtering together with destination NAT (DNAT). If you try to configure DNAT when Endpoint-Independent Filtering is enabled, or vice versa, the system issues a warning.

When P2MP mode is enabled, it is applied to all UDP traffic in the class. This can make the private host initiating UDP traffic from a given port susceptible to UDP traffic from any host through that port; care should be taken to protect the initiating host from a Denial of Service (DoS) attack.

When you enable Endpoint-Independent Filtering , the change applies only to new NAPT sessions; P2MP functionality is not added for existing sessions. Similarly, when you disable Endpoint-Independent Filtering, the change applies only to new NAPT sessions; P2MP functionality is not removed for existing sessions.

When Endpoint-Independent Filtering is used together with a DMZ, it limits the DMZ functionality. If the P2MP NAT IP addresses configured for the class overlap with those in the DMZ rules, then return traffic to the private host (from which the UDP traffic initiated) is treated differently. In cases where return NAPT traffic would be dropped because the return source destination does not match the original outgoing destination IP address ( "destination address mismatch"), traffic is not dropped as expected, but is translated and sent to the private host from which the UDP traffic originated. (If the return traffic is dropped for other reasons than destination address mismatch, it is dropped as expected and redirected to the DMZ server.)

1.8   Summary

The order in which the conditions in a NAT policy are checked to determine the action for a packet is as follows:

1. The conditions set by the policy static translations.
2. The conditions set by the policy ACL.
3. If the conditions in step 1 and step 2 are not satisfied, the action for the packet is determined by the default class action, if the policy ACL exists, or by the NAT policy action.

For more information about NAT, see RFC 3022, Traditional IP Network Address Translator (NAT) and RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.

2   Configuration and Operations Tasks

Note:  

In this section, the command syntax in the task tables displays only the root command; for the complete command syntax, see the Command List.

To configure NAT policies, perform the tasks described in the following sections.

2.1   Configure a NAT Policy with Static Translations

To configure a NAT policy with static translations, perform the tasks described in Table 1.

Note:  

For information about configuring interfaces and subscribers, see Configuring Contexts and Interfaces and Configuring Subscribers.

2.2   Configure a NAT Policy with a DMZ Host Server

To configure a NAT policy with a DMZ host server, perform the tasks described in Table 2.

2.3   Configure a NAT Policy with Dynamic Translations

To configure a NAT policy with dynamic translations, perform the tasks described in Table 3; enter all commands in NAT policy configuration mode, unless otherwise noted.

2.4   Apply a Policy ACL to a NAT Policy

To apply a policy ACL to packets associated with a dynamic NAT policy and complete the configuration of the policy, perform the tasks described in Table 4; enter all commands in policy group class configuration mode, unless otherwise noted.

2.5   Operations Tasks

To monitor, troubleshoot, and administer NAT policies, perform the NAT operations tasks described in Table 5. Enter the clear and debug commands in exec mode; enter the show commands in any mode.

3   Configuration Examples

This section provides NAT configuration examples.

3.1   NAT Policy with Static Translation

The following example configures a NAT policy with static translations:

[local]Redback(config-ctx)#nat policy p2

[local]Redback(config-policy-nat)#ip static in source 10.1.1.3 100.1.1.3

[local]Redback(config-policy-nat)#exit

[local]Redback(config-ctx)#interface pos2

[local]Redback(config-if)#ip nat p2

3.2   NAT Policy with Static NAPT

The following example configures a static NAPT policy:

[local]Redback(config-ctx)#nat policy p2

[local]Redback(config-policy-nat)#ip static in tcp source 10.1.1.3 80 100.1.1.3 8080

[local]Redback(config-policy-nat)#exit

[local]Redback(config-ctx)#interface pos2

[local]Redback(config-if)#ip nat p2

3.3   NAT Policy with Static Translation and a DMZ Host Server

The following example configures a NAT policy with static translation, two internal hosts, and a DMZ host server:

!Configure context, NAT policy, and interface for private network

[local]Redback(config)#context local

[local]Redback(config-ctx)#nat policy p2

[local]Redback(config-policy-nat)#ip dmz source 10.1.1.1 100.1.1.1 context local

[local]Redback(config-policy-nat)#ip static in source 10.1.1.2 100.1.1.2

[local]Redback(config-policy-nat)#ip static in source 10.1.1.3 100.1.1.3

[local]Redback(config-policy-nat)#exit

[local]Redback(config-ctx)#interface if-private

[local]Redback(config-if)#ip address 10.1.1.1/24

[local]Redback(config-if)#ip nat p2

[local]Redback(config-if)#exit

local]Redback(config-ctx)#exit

!Configure context, NAT policy, and interface for public network

[local]Redback(config)#context public

[local]Redback(config-ctx)#interface if-public

[local]Redback(config-if)#ip address 100.1.1.1/24

!Configure an Ethernet port for the private network

[local]Redback(config)#port ethernet 3/1 

[local]Redback(config-port)#bind interface if-private local

[local]Redback(config-port)#no shutdown

!Configure an Ethernet port for the public network

[local]Redback(config)#port ethernet 5/1 

[local]Redback(config-port)#bind interface if-public public

[local]Redback(config-port)#no shutdown

[local]Redback(config-port)#exit

Figure 2 illustrates the network configuration for the example.

3.4   NAT Policy with Dynamic Translation and an Ignore Action

The following example creates a policy ACL and applies it to a NAT policy with dynamic translations in which all packets except those classified as CLASS3 are ignored (that is, the NAT policy is not applied to them). All source IP addresses for incoming packets classified as CLASS3 are translated using IP addresses from the pool_dyn pool:

!Create the NAT pool

[local]Redback(config-ctx)#ip nat pool pool_dyn

[local]Redback(config-nat-pool)#address 11.11.11.0/24

[local]Redback(config-nat-pool)#exit

!Create the policy ACL

[local]Redback(config-ctx)#policy access-list NAT-ACL

[local]Redback(config-access-list)#seq 10 permit ip 10.10.10.0 0.0.0.255 class CLASS3

[local]Redback(config-access-list)#exit

!Create the NAT policy and apply the policy ACL

[local]Redback(config-ctx)#nat policy pol1

[local]Redback(config-nat-pool)#ignore

[local]Redback(config-nat-pool)#access-group NAT-ACL

[local]Redback(config-policy-group)#class CLASS3

[local]Redback(config-policy-group-class)#pool pool_dyn local

3.5   NAT Policy with Dynamic NAPT and a Drop Action

The following example configures a NAPT policy with dynamic translations in which all packets, except those classified as CLASS3, are dropped. Source IP addresses and their TCP/UDP ports for packets classified as CLASS3 are translated using the IP address and its TCP/UDP port blocks 1 to 15 from the pool_dyn_napt pool:

[local]Redback(config-ctx)#ip nat pool pool_dyn_napt napt

[local]Redback(config-nat-pool)#address 11.11.11.1/32 port-block 1 to 15

[local]Redback(config-nat-pool)#exit

[local]Redback(config-ctx)#nat policy pol1

[local]Redback(config-policy-nat)#drop

[local]Redback(config-policy-nat)#access-group NAT_ACL

[local]Redback(config-policy-group)#class CLASS3

[local]Redback(config-policy-group-class)#pool pool_dyn_napt local

3.6   NAT Policy with Static and Dynamic Translations

The following example configures a NAT policy that uses a combination of static and dynamic, basic NAT and NAPT, and applies a policy ACL:

[local]Redback(config-ctx)#ip nat pool pool_dyn 

[local]Redback(config-nat-pool)#address 100.1.2.0/24

[local]Redback(config-nat-pool)#exit

[local]Redback(config-ctx)#ip nat pool pool_dyn_napt napt

[local]Redback(config-nat-pool)#address 100.1.1.2/32 port-block 1

[local]Redback(config-nat-pool)#exit

[local]Redback(config-ctx)#nat policy pol1

[local]Redback(config-policy-nat)#pool pool_dyn local

[local]Redback(config-policy-nat)#access-group NAT-ACL

[local]Redback(config-policy-group)#class CLASS3

[local]Redback(config-policy-group-class)#pool pool_dyn_napt local

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#exit

[local]Redback(config-policy-nat)#ip static in tcp source 10.1.1.2 80 100.1.1.2 8080

[local]Redback(config-policy-nat)#ip static in source 10.1.1.3 100.1.1.3

3.7   NAT Policy with DNAT

The following example configures a NAT policy that uses DNAT, both with and without NAT, within a single NAT policy. A predefined destination address is configured for the NAT-CLASS1 and NAT-CLASS2 classes within the NAT policy NAT-POLICY . For all packets from class NAT-CLASS1, the destination address of each packet is replaced by 64.233.267.100 so that all packets from class NAT-CLASS1 are forwarded to that address. On the return path, a reverse translation from 64.233.267.100 to the original destination address is performed so that the returning traffic appears to be sent from the original destination address. For the NAT-CLASS2 class, the destination address of each packet is translated exactly the same way as for class NAT-CLASS1, but the source address is not translated:

[local]Redback(config-ctx)#nat policy NAT-POLICY

!Default class

[local]Redback(config-policy-nat)#pool NAT-POOL-DEFAULT local

!Named classes

[local]Redback(config-policy-nat)#access-group NAT-ACL

[local]Redback(config-policy-acl)#class NAT-CLASS1

[local]Redback(config-policy-acl-class)#pool NAT-POOL1 local

[local]Redback(config-policy-acl-class)#destination 64.233.167.100

[local]Redback(config-policy-acl)#class NAT-CLASS2

[local]Redback(config-policy-acl-class)#ignore

[local]Redback(config-policy-acl-class)#destination 64.233.167.100

3.8   NAT Policy with Session Limit Control

The following example configures a NAT policy that uses session limit control for both the default class and a subset of named classes. Assuming that packets are not satisfied by both static rules (those are of higher priority), the following processing takes place:

• Packets classified into CLASS2 are NAT-translated with the use of pool2 addresses and no session limit control is applied (the default state).
• Packets classified into CLASS3 are unchanged and session limit control is applied to TCP sessions with a maximum number of TCP sessions set to 100.
• All other packets (that is, those of the default class) are translated with the use of pool1 addresses and session limit control is applied to TCP sessions with a maximum number of TCP sessions set to 100.

  Note:  

  Specify the connections command (in NAT policy configuration mode) for the policy; then specify the admission-control command for each class (including the default one) for which you want the session limit to be enforced.

  
  

[local]Redback(config)#context local

[local]Redback(config-ctx)#nat policy pol1

[local]Redback(config-policy-nat)#ip static in tcp source 10.1.3.3 80 100.1.3.3 8080

[local]Redback(config-policy-nat)#ip static in tcp source 10.1.4.3 80 100.1.3.4 8080

[local]Redback(config-policy-nat)#connections tcp 100



! Default class

[local]Redback(config-policy-nat)#pool pool1 local

[local]Redback(config-policy-nat)#timeout tcp

[local]Redback(config-policy-nat)#admission-control tcp

! Named classes

[local]Redback(config-policy-nat)#access-group NAT-ACL

[local]Redback(config-policy-group)#class CLASS2

[local]Redback(config-policy-group-class)#pool pool2

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class CLASS3

[local]Redback(config-policy-group-class)#ignore

[local]Redback(config-policy-group-class)#admission-control tcp

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#exit

[local]Redback(config-policy-nat)#exit

[local]Redback(config-ctx)#exit

3.9   NAT Policy for Point-to-Multipoint UDP Traffic

The following example enables P2MP mode for all UDP traffic in the class yes_p2mp:

[local]Redback(config)#context nat_context

[local]Redback(config-ctx)#nat policy basic_nat

[local]Redback(config-policy-nat)#drop

[local]Redback(config-policy-nat)#access group basic_nat_rules

[local]Redback(config-policy-group)#class yes_p2mp

[local]Redback(config-policy-group-class)#pool NAPT_POOL local

[local]Redback(config-policy-group-class)#endpoint-independent filtering udp

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class firewall

[local]Redback(config-policy-group-class)#pool NAPT_POOL local

[local]Redback(config-policy-group-class)#exit

[local]Redback(config-policy-group)#class no_NAT

[local]Redback(config-policy-group-class)#ignore

The following example enables P2MP mode for UDP traffic in the default class without employing an access group in the policy:

[local]Redback(config)#context nat_context

[local]Redback(config-ctx)#nat policy basic_nat

[local]Redback(config-policy-nat)#pool NAPT_POOL local

[local]Redback(config-policy-nat)#endpoint-independent filtering udp