[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

Examples: Configuring NAT Rules

This section provides the following configuration examples:

For additional examples that combine NAT configuration with other services and with virtual private network (VPN) routing and forwarding (VRF) tables, see Examples: Services Interfaces Configuration.

Example: Configuring Dynamic Source Translation

The following example configures dynamic source translation:

[edit services nat]
pool public {
address-range low 192.16.2.1 high 192.16.2.32;
port automatic;
}
rule Private-Public {
match-direction input;
term Translate {
then {
translated {
source-pool public;
translation-type source dynamic;
}
}
}
}

Example: Configuring Static Source Translation

The following configuration sets up one-to-one mapping between a private subnet and a public subnet:

[edit services nat]
pool mypool {
address 192.16.1.0/28; # public subnet
}
rule src-nat {
match-direction input;
term t1 {
from {
source-address 10.150.1.0/28; # private subnet
}
then {
translated {
source-pool mypool;
translation-type source static;
}
}
}
}

Example: Configuring Dynamic and Static Source Translation

In the following configuration, term1 configures source address translation for traffic from any private address to any public address. The translation is applied for all services. term2 performs destination address translation for Hypertext Transfer Protocol (HTTP) traffic from any public address to the server’s virtual IP address. The virtual server IP address is translated to an internal IP address.

[edit services nat]
rule my-nat-rule {
match-direction input;
term my-term1 {
from {
source-address private;
destination-address public;
}
then {
translated {
source-pool my-prefix-list; # pick address from a pool
translation-type source dynamic; # dynamic NAT with port translation
}
}
}
term my-term2 {
from {
destination-address 192.168.137.3; # my server’s virtual address
application http;
}
then {
translated {
destination-pool nat-pool-name;
translation-type destination static; # static destination NAT
}
}
}
}

Example: Configuring an Oversubscribed Pool with No Fallback

The following configuration shows dynamic address translation from a large prefix to a small pool, translating a /24 subnet to a pool of 10 addresses. Sessions from the first 10 host sessions are assigned an address from the pool on a first-come, first-served basis, and any additional requests are rejected. Each host with an assigned NAT addresses can participate in multiple sessions.

[edit nat services]
pool my-pool {
address-range low 10.10.10.1 high 10.10.10.10;
}
rule src-nat {
match-direction input;
term t1 {
from {
source-address 192.168.1.0/24;
}
then {
translated {
translation-type source dynamic;
source-pool my-pool;
}
}
}
}

Example: Configuring an Oversubscribed Pool with Fallback to NAPT

The following configuration shows dynamic address translation from a large prefix to a small pool, translating a /24 subnet to a pool of 10 addresses. When the addresses in the source pool (src-pool) are exhausted, network address translation is provided by the NAPT overload pool (pat-pool).

[edit services nat]
pool src-pool {
address-range low 192.16.2.1 high 192.16.2.10;
}
pool pat-pool {
address-range low 192.2.11 high 192.16.2.12;
port automatic;
}
rule myrule {
match-direction input;
term myterm {
from {
source-address 10.150.1.0/24;
}
then {
translated {
source-pool src-pool;
overload-pool pat-pool;
translation-type source dynamic;
}
}
}
}

Example: Configuring Static Source Translation with Multiple Prefixes and Address Ranges

The following configuration creates a static pool with an address prefix and an address range and uses static source NAT translation.

[edit services nat]
pool p1 {
address 30.30.30.252/30;
address-range low 20.20.20.1 high 20.20.20.2;
}
rule r1 {
match-direction input;
term {
from {
source-address {
10.10.10.252/30;
}
}
then {
translated {
source-pool p1;
translation-type source static;
}
}
}
}

Example: Assigning Addresses from a Dynamic Pool for Static Use

The following configuration statically assigns a subset of addresses that are configured as part of a dynamic pool (dynamic-pool) to two separate static pools (static-pool and static-pool2).

[edit services nat]
pool dynamic-pool {
address 20.20.10.0/24;
}
pool static-pool {
address-range low 20.20.10.10 high 10.20.10.12;
}
pool static-pool2 {
address 20.20.10.15/32;
}
rule src-nat {
match-direction input;
term t1 {
from {
source-address 30.30.30.0/24;
}
then {
translation-type source dynamic;
source-pool dynamic-pool;
}
}
term t2 {
from {
source-address 10.10.10.2;
}
then {
translation-type source static;
source-pool static-pool;
}
}
term t3 {
from {
source-address 10.10.10.10;
}
then {
translation-type source static;
source-pool static-pool2;
}
}
}

Example: Configuring NAT Rules Without Defining a Pool

The following configuration performs network address translation using the source prefix 20.20.10.0/24 without defining a pool.

[edit services nat]
rule src-nat {
match-direction input;
term t1 {
then {
translation-type source dynamic;
source-prefix 20.20.10.0/24;
}
}
}

The following configuration performs network address translation using the destination prefix 20.20.10.0/32 without defining a pool.

[edit services nat]
rule src-nat {
match-direction input;
term t1 {
from {
destination-address 10.10.10.10/32;
then {
translation-type destination static;
destination-prefix 20.20.10.0/32;
}
}
}
}

Example: Preventing Translation of Specific Addresses

The following configuration specifies that network address translation is not performed on incoming traffic from the source address 192.168.20.24/32. Dynamic NAT is performed on all other incoming traffic.

[edit services nat]
pool my-pool {
address-range low 10.10.10.1 high 10.10.10.16;
port-automatic;
}
rule src-nat {
match-direction input;
term t0 {
from {
source-address 192.168.20.24/32;
}
then {
no-translation;
}
}
term t1 {
then {
translated {
translation-type source dynamic;
source-pool my-pool;
}
}
}
}

Example: Configuring NAT for Multicast Traffic

Figure 2 illustrates the network setup for the following configuration, which allows IP multicast traffic to be sent to the Adaptive Services (AS) or MultiServices PIC.

Figure 2: Configuring NAT for Multicast Traffic

Image g017224.gif

Rendezvous Point Configuration

On the rendezvous point (RP), all incoming traffic from the multicast source at 192.168.254.0/27 is sent to the static NAT pool mcast_pool, where its source is translated to 20.20.20.0/27. The service set nat_ss is a next-hop service set that allows IP multicast traffic to be sent to the AS or MultiServices PIC. The inside interface on the PIC is sp-1/1/0.1 and the outside interface is sp-1/1/0.2.

[edit services]
nat {
pool mcast_pool {
address 20.20.20.0/27;
}
rule nat_rule_1 {
match-direction input;
term 1 {
from {
source-address 192.168.254.0/27;
}
}
then {
translated {
source-pool mcast_pool;
translation-type source static;
}
syslog;
}
}
}
service-set nat_ss {
allow-multicast;
nat-rules nat_rule_1;
next-hop-service {
inside-service-interface sp-1/1/0.1;
outside-service-interface sp-1/1/0.2;
}
}

The Gigabit Ethernet interface ge-0/3/0 carries traffic out of the RP to Router 1. The adaptive services interface sp-1/1/0 has two logical interfaces: unit 1 is the inside interface for next-hop services and unit 2 is the outside interface for next-hop services. Multicast source traffic comes in on the Fast Ethernet interface fe-1/2/1, which has the firewall filter fbf applied to incoming traffic.

[edit interfaces]
ge-0/3/0 {
unit 0 {
family inet {
address 10.10.1.1/30;
}
}
}
sp-1/1/0 {
unit 0 {
family inet;
}
unit 1 {
family inet;
service-domain inside;
}
unit 2 {
family inet;
service-domain outside;
}
}
fe-1/2/1 {
unit 0 {
family inet {
filter {
input fbf;
}
address 192.168.254.27/27;
}
}
}

Multicast packets can only be directed to the AS or MultiServices PIC using a next-hop service set. In the case of NAT, you must also configure a VRF. Therefore, the routing instance stage is created as a “dummy” forwarding instance. To direct incoming packets to stage, you configure filter-based forwarding through a firewall filter called fbf, which is applied to the incoming interface fe-1/2/1. A lookup is performed in stage.inet.0, which has a multicast static route that is installed with the next hop pointing to the PIC’s inside interface. All multicast traffic matching this route is sent to the PIC.

[edit firewall]
filter fbf {
term 1 {
then {
routing-instance stage;
}
}
}

The routing instance stage forwards IP multicast traffic to the inside interface sp-1/1/0.1 on the AS or MultiServices PIC:

[edit]
routing-instances stage {
instance-type forwarding;
routing-options {
static {
route 224.0.0.0/4 next-hop sp-1/1/0.1;
}
}
}

You enable OSPF and Protocol Independent Multicast (PIM) on the Fast Ethernet and Gigabit Ethernet logical interfaces over which IP multicast traffic enters and leaves the RP. You also enable PIM on the outside interface (sp-1/1/0.2) of the next-hop service set.

[edit protocols]
ospf {
area 0.0.0.0 {
interface fe-1/2/1.0 {
passive;
}
interface lo0.0;
interface ge-0/3/0.0;
}
}
pim {
rp {
local {
address 10.255.14.160;
}
}
interface fe-1/2/1.0;
interface lo0.0;
interface ge-0/3/0.0;
interface sp-1/1/0.2;
}

As with any filter-based forwarding configuration, in order for the static route in the forwarding instance stage to have a reachable next hop, you must configure routing table groups so that all interface routes are copied from inet.0 to the routing table in the forwarding instance. You configure routing tables inet.0 and stage.inet.0 as members of fbf_rib_group, so that all interface routes are imported into both tables.

[edit routing-options]
interface-routes {
rib-group inet fbf_rib_group;
}
rib-groups fbf_rib_group {
import-rib [ inet.0 stage.inet.0 ];
}
multicast {
rpf-check-policy no_rpf;
}

Reverse path forwarding (RPF) checking must be disabled for the multicast group on which source NAT is applied. You can disable RPF checking for specific multicast groups by configuring a policy similar to the one in the example that follows. In this case, the no_rpf policy disables RPF check for multicast groups belonging to 224.0.0.0/4.

[edit policy-options]
policy-statement no_rpf {
term 1 {
from {
route-filter 224.0.0.0/4 orlonger;
}
then reject;
}
}

Router 1 Configuration

The Internet Group Management Protocol (IGMP), OSPF, and PIM configuration on Router 1 is as follows. Because of IGMP static group configuration, traffic is forwarded out fe-3/0/0.0 to the multicast receiver without receiving membership reports from host members.

[edit protocols]
igmp {
interface fe-3/0/0.0 {
}
}
ospf {
area 0.0.0.0 {
interface fe-3/0/0.0 {
passive;
}
interface lo0.0;
interface ge-7/2/0.0;
}
pim {
rp {
static {
address 10.255.14.160;
}
}
interface fe-3/0/0.0;
interface lo0.0;
interface ge-7/2/0.0;
}
}

The routing option creates a static route to the NAT pool, mcast_pool, on the RP.

[edit routing-options]
static {
route 20.20.20.0/27 next-hop 10.10.1.1;
}

Example: Configuring Twice NAT

In the following configuration, term1 configures source address translation and destination address translation for traffic from a specific destination address to a source address in a range of source addresses. Both destination and source pools are configured.

[edit services nat]
rule twice-nat {
match-direction input;
term my-term1 {
from {
destination-address {
41.41.41.41/32;
}
source-address-range {
low 10.58.254.34 high 10.58.254.35;
}
}
then {
translated {
source-pool src-pool;
destination-pool dst_pool;
translation-type {
source static;
destination static;
}
}
}
}
}

Example: Configuring Full-Cone NAT

The following configuration example shows full-cone NAT with source static processing.

[edit services]
nat {
pool static_nat_range {
address-range low 10.200.253.1 high 10.200.253.5;
}
rule static_nat_rule {
term sample-term {
nat-type full-cone;
from {
source-address-range {
low 10.100.136.1 high 10.100.136.5;
}
}
then {
translated {
source-pool static_nat_range;
translation-type {
source static;
}
}
}
}
}
}
[ Contents] [ Prev] [ Next] [ Index] [ Report an Error]

[an error occurred while processing this directive]