Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Inline NAT

 

Inline Network Address Translation Overview

Inline NAT uses the capabilities of the MPC line card, eliminating the need for a services card for NAT. Consequently, you can achieve line-rate, low-latency address translations (up to 120 Gbps per slot). The current implementation provides:

  • 1:1 static address mapping.

  • Bidirectional mapping - source NAT for outbound traffic and destination NAT for inbound traffic.

  • No limit on number of flows.

  • Support for Source, destination, and twice NAT, as shown in Figure 1. Inline NAT supports the translation type basic-nat44. Starting in Junos OS Release 15.1R1, inline NAT also supports twice-basic-nat-44.

  • Support for hairpinning.

Figure 1: Supported Inline NAT Types
Supported Inline
NAT Types

To configure inline NAT, you define your service interface as type si- (service-inline) interface. You must also reserve adequate bandwidth for the inline interface. This enables you to configure both interface or next-hop service-sets used for NAT. The si- interface serves as a “virtual service PIC”.

Note
  • Only static NAT is supported. Port translation, dynamic NAT, and ALGs are not supported. Hence, applications such as SIP or FTP Active Mode which require advanced processing for NAT do not function. An MS-MPC, MS-MIC, MS-DPC, or MS-PIC is still needed for any stateful-firewall processing, ALG support, and dynamic port translation.

  • Inline NAT does not support sampling or logging of packets.

Benefits of Inline NAT

  • Eliminates the need for a services card

  • Supports more NAT flows than a services card

Example: Configuring Inline Network Address Translation—Interface-Based Method

This configuration example illustrates how to configure interface-based inline network address translation (NAT) on MX Series devices using si- (service-inline) interfaces with interface-style service-sets.

This topic covers:

Requirements

This example uses the following hardware and software components:

  • MX Series router with a Modular Port Concentrator (MPC) line card

  • Junos OS Release 11.4R1 or higher

Overview and Topology

As of Junos OS Release 11.4R1, MPC line cards can perform some services without the need of a dedicated services card, such as an MS-MPC. Inline services generally provide better performance than using a services card, however their functionality tends to be more basic. For example, inline NAT supports only static NAT.

In this example, an MX Series device with an MPC line card provides inline source NAT services to traffic flowing between two end hosts. The topology for this scenario is shown in Figure 2

Figure 2: Inline Source NAT Using an MX Series Device with an MPC
Inline Source NAT Using an MX
Series Device with an MPC

As shown in the figure, host H1 sends traffic towards server S1. The MX Series device performs source NAT to translate H1’s source IP address from 10.1.1.2 to 192.0.2.2. Server S1 then sends return traffic to host H1 using the destination IP address 192.0.2.2, and the MX Series device reverts H1’s IP address back to 10.1.1.2.

The following configuration elements are used in this scenario:

  • Inline service interface—a virtual interface that resides on the Packet Forwarding Engine of the MPC. To access services, traffic flows in and out of these si- (service-inline) interfaces.

  • Service set—defines the service(s) to be performed, and identifies which inline interface(s) will feed traffic into and out of the service set. There are two ways to implement service sets:

    • Interface-style—an interface-based method, where packets arriving at an interface are forwarded through the inline service.

    • Next-hop-style—a route-based method, where static routes are used to forward packets destined for a specific destination through the inline service.

    This example uses the interface-style service set.

  • NAT rule—uses an if-then structure (similar to firewall filters) to define matching conditions and then apply address translation to the matching traffic.

  • NAT pool—a user-defined set of IP addresses that are used by the NAT rule for translation.

These elements come together as shown in Figure 3

Figure 3: Interface-Based Inline Source NAT
Interface-Based Inline
Source NAT

Configuration

To configure inline NAT using an interface-style service set, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Enable Inline Services and Create an Inline Interface

Step-by-Step Procedure

  1. Enable inline services for the relevant FPC slot and PIC slot, and define the amount of bandwidth to dedicate for inline services.

    The FPC and PIC settings here will create and map to an si- interface.

  2. On the si- interface, specify the protocol family (or families) that will need NAT services.Note

    The FPC and PIC settings here must match the settings defined above.

Configure NAT Rule and Pool

Step-by-Step Procedure

  1. Configure a NAT rule that matches on traffic arriving at the MX device from H1’s subnet (10.1.1.0/24), translates it using basic IPv4 NAT, and uses an IP address from pool p1.
  2. Configure the NAT pool.

Configure the (Interface-style) Service Set

Step-by-Step Procedure

  1. Configure a service set that uses the inline NAT service (nat-rules), and the inline interface defined above. Use the interface-service parameter to specify that this is an interface-style service set.

    Traffic will flow into and out of the si- interface to access the inline NAT service.

Configure Physical Interfaces

Step-by-Step Procedure

  1. Configure the physical interfaces.
  2. On the ’inside’ interface, specify that traffic will be sent through the service set defined above.

Results

Verification

Confirm that the configuration is working properly.

Verifying Reachability from Host H1 to Server S1

Purpose

Verify reachability between H1 and S1.

Action

On host H1, verify that the host can ping server S1.

user@H1> ping 192.168.1.2 count 5

Meaning

H1 can successfully reach S1.

Verifying Address Translation

Purpose

Verify that address translation is working correctly.

Action

  1. On the MX device, verify that the inline NAT configuration details have been applied correctly.

    user@MX> show services inline nat pool
  2. On server S1, verify that the server is receiving the pings from H1’s NAT-translated source IP address (192.0.2.2).

    Issue the command below, and send pings again from H1.

    Note

    For this setup, another MX device is used to represent server S1 to enable monitoring of the inbound traffic.

    user@S1> monitor traffic interface xe-1/1/1 no-resolve

Meaning

Step 1 above confirms that the inline NAT service parameters and interface-style service set are correctly implemented. Step 2 above confirms that server S1 is correctly receiving H1’s pings from its NAT-translated source IP address.

Example: Configuring Inline Network Address Translation—Route-Based Method

This configuration example illustrates how to configure route-based inline network address translation (NAT) on MX Series devices using si- (service-inline) interfaces with next-hop style service-sets.

This topic covers:

Requirements

This example uses the following hardware and software components:

  • MX Series router with a Modular Port Concentrator (MPC) line card

  • Junos OS Release 11.4R1 or higher

Overview and Topology

As of Junos OS Release 11.4R1, MPC line cards can perform some services without the need of a dedicated services card, such as an MS-MPC. Inline services generally provide better performance than using a services card, however their functionality tends to be more basic. For example, inline NAT supports only static NAT.

In this example, an MX Series device with an MPC line card provides inline source NAT services to traffic flowing between two end hosts. The topology for this scenario is shown in Figure 4

Figure 4: Inline Source NAT Using an MX Series Device with an MPC
Inline Source NAT Using an MX Series
Device with an MPC

As shown in the figure, host H1 sends traffic towards server S1. The MX Series device performs source NAT to translate H1’s source IP address from 10.1.1.2 to 192.0.2.2. Server S1 then sends return traffic to host H1 using the destination IP address 192.0.2.2, and the MX Series device reverts H1’s IP address back to 10.1.1.2.

The following configuration elements are used in this scenario:

  • Inline service interface—a virtual interface that resides on the Packet Forwarding Engine of the MPC. To access services, traffic flows in and out of these si- (service-inline) interfaces.

  • Service set—defines the service(s) to be performed, and identifies which inline interface(s) will feed traffic into and out of the service set. There are two ways to implement service sets:

    • Interface-style—an interface-based method, where packets arriving at an interface are forwarded through the inline service.

    • Next-hop-style—a route-based method, where static routes are used to forward packets destined for a specific destination through the inline service.

    This example uses the next-hop-style service set.

  • NAT rule—uses an if-then structure (similar to firewall filters) to define matching conditions and then apply address translation to the matching traffic.

  • NAT pool—a user-defined set of IP addresses that are used by the NAT rule for translation.

  • Routing instance—a collection of routing tables, interfaces, and routing protocol parameters that run separate from the main (default) routing instance.

    Route-based inline NAT is typically used in scenarios that involve routing instances.

These elements come together as shown in Figure 5.

Figure 5: Route-Based Inline Source NAT
Route-Based Inline Source
NAT

Configuration

To configure inline NAT using a next-hop-style service set, perform these tasks:

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configure Physical Interfaces

Step-by-Step Procedure

  1. Configure the physical interfaces.

Enable Inline Services and Create an Inline Interface

Step-by-Step Procedure

  1. Enable inline services for the relevant FPC slot and PIC slot, and define the amount of bandwidth to dedicate for inline services.

    The FPC and PIC settings here will create and map to an si- interface.

  2. On the si- interface, create two logical units. For each unit, specify the protocol family (or families) that will need NAT services, and the ’inside’ or ’outside’ interfaces for the service domain.Note

    The FPC and PIC settings here must match the settings defined above.

Configure Routing Instance and Identify Traffic to Send Through Inline NAT Service

Step-by-Step Procedure

  1. Configure a routing instance that includes the 'ínside' physical and si- interfaces, as well as a static route that identifies traffic to forward into the inline NAT service through the si- interface.

    For simplicity, the static route used here simply identifies server S1.

Configure NAT Rule and Pool

Step-by-Step Procedure

  1. Configure a NAT rule that matches on traffic arriving at the MX device from H1’s subnet (10.1.1.0/24), translates it using basic IPv4 NAT, and uses an IP address from pool p1.
  2. Configure the NAT pool.

Configure the (Next-hop-style) Service Set

Step-by-Step Procedure

  1. Configure a service set that uses the inline NAT service (nat-rules), and the inline interfaces defined above. Use the next-hop-service parameter to specify that this is a next-hop-style service set, and assign the si- interfaces as ’inside’ and ’outside’ based on their settings above.

    Traffic will flow into and out of the si- interfaces to access the inline NAT service.

Results

Verification

Confirm that the configuration is working properly.

Verifying Reachability from Host H1 to Server S1

Purpose

Verify reachability between H1 and S1.

Action

On host H1, verify that the host can ping server S1.

user@H1> ping 192.168.1.2 count 5

Meaning

H1 can successfully reach S1.

Verifying Address Translation

Purpose

Verify that address translation is working correctly.

Action

  1. On the MX device, verify that the inline NAT configuration details have been applied correctly.

    user@MX> show services inline nat pool
  2. On server S1, verify that the server is receiving the pings from H1’s NAT-translated source IP address (192.0.2.2).

    Issue the command below, and send pings again from H1.

    Note

    For this setup, another MX device is used to represent server S1 to enable monitoring of the inbound traffic.

    user@S1> monitor traffic interface xe-1/1/1 no-resolve

Meaning

Step 1 above confirms that the inline NAT service parameters and next-hop-style service set are correctly implemented. Step 2 above confirms that server S1 is correctly receiving H1’s pings from its NAT-translated source IP address.

Release History Table
Release
Description
Starting in Junos OS Release 15.1R1, inline NAT also supports twice-basic-nat-44