Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Network Address Translation Overview

Junos Address Aware Network Addressing Overview

Junos Address Aware Network Addressing provides Network Address Translation (NAT) functionality for translating IP addresses. This is particularly important because the Internet Assigned Numbers Authority (IANA) allocated the last large block of IPv4 addresses in early 2011.

This topic includes the following sections:

Benefits of NAT

NAT supports a wide range of networking goals, including:

  • Concealing a set of host addresses on a private network behind a pool of public addresses to protect the host addresses from direct targeting in network attacks and to avoid IPv4 address exhaustion

  • Providing the tools to transition to IPv6 based on business requirements and to ensure uninterrupted subscriber and service growth

  • Providing IPv4–IPv6 coexistence

NAT Concept and Facilities Overview

Junos Address Aware Network Addressing provides carrier-grade NAT (CGN) for IPv4 and IPv6 networks, and facilitates the transit of traffic between different types of networks.

Junos Address Aware Network Addressing supports a diverse set of NAT translation options:

  • Static-source translation—Allows you to hide a private network. It features a one-to-one mapping between the original address and the translated address; the mapping is configured statically. For more information, see Basic NAT .

  • Deterministic NAPT—Eliminates the need for address translation logging by ensuring that the original source IPv4 or IPv6 address and port always map to the same post-NAT IPv4 address and port range.

  • Dynamic-source translation— Includes two options: dynamic address-only source translation and Network Address Port Translation (NAPT):

    • Dynamic address-only source translation— mdash;A NAT address is picked up dynamically from a source NAT pool and the mapping from the original source address to the translated address is maintained as long as there is at least one active flow that uses this mapping. For more information, see Dynamic NAT.

    • NAPT—Both the original source address and the source port are translated. The translated address and port are picked up from the corresponding NAT pool. For more information, see NAPT .

  • Static destination translation—Allows you to make selected private servers accessible. It features a one-to-one mapping between the translated address and the destination address; the mapping is configured statically. For more information, see Static Destination NAT.

  • Protocol translation—Allows you to assign addresses from a pool on a static or dynamic basis as sessions are initiated across IPv4 or IPv6 boundaries. For more information, see Configuring NAT-PT, NAT-PT with DNS ALG, and Stateful NAT64.

  • Encapsulation of IPv4 packets into IPv6 packets using softwires—Enables packets to travel over softwires to a carrier-grade NAT endpoint where they undergo source-NAT processing to hide the original source address. For more information, see Tunneling Services for IPv4-to-IPv6 Transition Overview.

Junos Address Aware Network Addressing supports NAT functionality described in IETF RFCs and Internet drafts, as shown in “ Supported NAT and SIP Standards” in Standards Reference.

Note:

Not all types of NAT are supported on all interface types. See Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface Card, which lists features available on supported interfaces.

IPv4-to-IPv4 Basic NAT

Basic Network Address Translation or Basic NAT is a method by which IP addresses are mapped from one group to another, transparent to end users. Network Address Port Translation or NAPT is a method by which many network addresses and their TCP/UDP ports are translated into a single network address and its TCP/UDP ports. Together, these two operations, referred to as traditional NAT, provide a mechanism to connect a realm with private addresses to an external realm with globally unique registered addresses.

Traditional NAT, specified in RFC 3022, Traditional IP Network Address Translator, is fully supported by Junos Address Aware Network Addressing. In addition, NAPT is supported for source addresses.

Basic NAT

With Basic NAT, a block of external addresses is set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, Basic NAT translates source IP addresses and related fields such as IP, TCP, UDP, and ICMP header checksums. For inbound packets, Basic NAT translates the destination IP address and the checksums listed above.

Hairpinning is supported for basic NAT.

NAPT

Use NAPT to enable the components of the private network to share a single external address. NAPT translates the transport identifier (for example, TCP port number, UDP port number, or ICMP query ID) of the private network into a single external address. NAPT can be combined with Basic NAT to use a pool of external addresses in conjunction with port translation.

For packets outbound from the private network, NAPT translates the source IP address, source transport identifier (TCP/UDP port or ICMP query ID), and related fields, such as IP, TCP, UDP, and ICMP header checksums. For inbound packets, NAPT translates the destination IP address, the destination transport identifier, and the IP and transport header checksums.

On MX Series routers with MS-MICs and MS-MPCs, if you configure a NAPT44 NAT rule and the source IP address of a spoofed packet is equal to the NAT pool and the NAT rule match condition fails, the packet is continuously looped between the services PIC and the Packet Forwarding Engine. We recommend that you manually clear the session and create a filter to block NAT pool IP spoofing under such conditions.

Hairpinning is supported for NAPT.

Deterministic NAPT

Use deterministic NAPT44 to ensure that the original source IPv4 address and port always map to the same post-NAT IPv4 address and port range, and that the reverse mapping of a given translated external IPv4 address and port are always mapped to the same internal IP address. This eliminates the need for address translation logging. Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported on the MS-MPC and MS-MIC. Deterministic NAPT64 ensures that the original source IPv6 address and port always map to the same post-NAT IPv4 address and port range, and that the reverse mapping of a given translated external IPv4 address and port are always mapped to the same internal IPv6 address.

Static Destination NAT

Use static destination NAT to translate the destination address for external traffic to an address specified in a destination pool. The destination pool contains one address and no port configuration.

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

Twice NAT

In Twice NAT, both the source and destination addresses are subject to translation as packets traverse the NAT router. The source information to be translated can be either address only or address and port. For example, you would use Twice NAT when you are connecting two networks in which all or some addresses in one network overlap with addresses in another network (whether the network is private or public). In traditional NAT, only one of the addresses is translated.

To configure Twice NAT, you must specify both a destination address and a source address for the match direction, pool or prefix, and translation type.

You can configure application-level gateways (ALGs) for ICMP and traceroute under stateful firewall, NAT, or class-of-service (CoS) rules when Twice NAT is configured in the same service set. These ALGs cannot be applied to flows created by the Packet Gateway Control Protocol (PGCP). Twice NAT does not support other ALGs. By default, the Twice NAT feature can affect IP, TCP, and UDP headers embedded in the payload of ICMP error messages.

Twice NAT, specified in RFC  2663, IP Network Address Translator (NAT) Terminology and Considerations, is fully supported by Junos Address Aware Network Addressing.

IPv6 NAT

IPv6-to-IPv6 NAT (NAT66), defined in Internet draft draft-mrw-behave-nat66-01, IPv6-to-IPv6 Network Address Translation (NAT66), is fully supported by Junos Address Aware Network Addressing.

Application-Level Gateway (ALG) Support

Junos Address Aware Network Addressing supports a number of ALGs. You can use NAT rules to filter incoming traffic based on ALGS. For more information, see Network Address Translation Rules Overview.

NAT-PT with DNS ALG

NAT-PT and Domain Name System (DNS) ALG are used to facilitate communication between IPv6 hosts and IPv4 hosts. Using a pool of IPv4 addresses, NAT-PT assigns addresses from that pool to IPv6 nodes on a dynamic basis as sessions are initiated across IPv4 or IPv6 boundaries. Inbound and outbound sessions must traverse the same NAT-PT router so that it can track those sessions. RFC 2766, Network Address Translation - Protocol Translation (NAT-PT), recommends the use of NAT-PT for translation between IPv6-only nodes and IPv4-only nodes, and not for IPv6-to-IPv6 translation between IPv6 nodes or IPv4-to-IPv4 translation between IPv4 nodes.

DNS is a distributed hierarchical naming system for computers, services, or any resource connected to the Internet or a private network. The DNS ALG is an application-specific agent that allows an IPv6 node to communicate with an IPv4 node and vice versa.

When DNS ALG is employed with NAT-PT, the DNS ALG translates IPv6 addresses in DNS queries and responses to the corresponding IPv4 addresses and vice versa. IPv4 name-to-address mappings are held in the DNS with “A” queries. IPv6 name-to-address mappings are held in the DNS with “AAAA” queries.

Note:

For IPv6 DNS queries, use the do-not-translate-AAAA-query-to-A-query statement at the [edit applications application application-name] hierarchy level.

Dynamic NAT

Dynamic NAT flow is shown in Figure 1.

Figure 1: Dynamic NAT FlowDynamic NAT Flow

With dynamic NAT, you can map a private IP address (source) to a public IP address drawing from a pool of registered (public) IP addresses. NAT addresses from the pool are assigned dynamically. Assigning addresses dynamically also allows a few public IP addresses to be used by several private hosts, in contrast with an equal-sized pool required by source static NAT.

For more information about dynamic address translation, see RFC 2663, IP Network Address Translator (NAT) Terminology and Considerations.

Stateful NAT64

Stateful NAT64 flow is shown in Figure 2.

Figure 2: Stateful NAT64 FlowStateful NAT64 Flow

Stateful NAT64 is a mechanism to move to an IPv6 network and at the same time deal with IPv4 address depletion. By allowing IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP, several IPv6-only clients can share the same public IPv4 server address. To allow sharing of the IPv4 server address, NAT64 translates incoming IPv6 packets into IPv4 (and vice versa).

When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. DNS64 is out of scope of this document because it is normally implemented as an enhancement to currently deployed DNS servers.

Stateful NAT64, specified in RFC 6146, Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers, is fully supported by Junos Address Aware Network Addressing.

464XLAT

Starting in Junos OS Release 17.1R1, you can configure a 464XLAT Provider-Side Translater (PLAT). This is supported only on MS-MICs and MS-MPCs. 464XLAT provides a simple and scalable technique for an IPv4 client with a private address to connect to an IPv4 host over an IPv6 network. 464XLAT only suports IPv4 in the client-server model, so it does not support IPv4 peer-to-peer communication or inbound IPv4 connections.

A customer-side translator (CLAT), which is not a Juniper Networks product, translates the IPv4 packet to IPv6 by embedding the IPv4 source and destination addresses in IPv6 /96 prefixes, and sends the packet over an IPv6 network to the PLAT. The PLAT translates the packet to IPv4, and sends the packet to the IPv4 host over an IPv4 network (see Figure 3).

Figure 3: 464XLAT Wireline Flow464XLAT Wireline Flow

XLAT464 provides the advantages of not having to maintain an IPv4 network and not having to assign additional public IPv4 addresses.

The CLAT can reside on the end user mobile device in an IPv6-only mobile network, allowing mobile network providers to roll out IPv6 for their users and support IPv4-only applications on mobile devices (see Figure 4).

Figure 4: 464XLAT Wireless Flow464XLAT Wireless Flow

Dual-Stack Lite

Dual-stack lite (DS-Lite) flow is shown in Figure 5.

Figure 5: DS-Lite FlowDS-Lite Flow

DS-Lite employs IPv4-over-IPv6 tunnels to cross an IPv6 access network to reach a carrier-grade IPv4-IPv4 NAT. This facilitates the phased introduction of IPv6 on the Internet by providing backward compatibility with IPv4.

DS-Lite is supported on MX series routers with MS-DPCs and on M Series routers with MS-100, MS-400, and MS-500 MultiServices PICS. Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.Starting in Junos OS release 19.2R1, DS-Lite is supported on MX Virtual Chassis and MX Broadband Network Gateway (BNG) routers.

Junos Address Aware Network Addressing Line Card Support

Junos Address Aware Network Addressing technologies are available on the following line cards:

  • MultiServices Dense Port Concentrator (MS-DPC)

  • MS-100, MS-400, and MS-500 MultiServices PICS

  • MultiServices Modular Port Concentrator (MS-MPC) and MultiServices Modular Interface Card (MS-MIC)

  • Modular Port Concentrators (inline NAT).

For a listing of the specific NAT types supported on each type of card, see Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface Card.

Sample IPv6 Transition Scenarios

The Junos OS supports many IPv6 transition scenarios required by Junos OS customers. The following are selected examples:

Example 1: IPv4 Depletion with a Non-IPv6 Access Network

Figure 6 depicts a scenario in which the Internet service provider (ISP) has not significantly changed its IPv4 network. This approach enables IPv4 hosts to access the IPv4 Internet and IPv6 hosts to access the IPv6 Internet. A dual-stack host can be treated as an IPv4 host when it uses the IPv4 access service, and as an IPv6 host when it uses the IPv6 access service.

Figure 6: IPv4 Depletion Solution - IPv4 Access NetworkIPv4 Depletion Solution - IPv4 Access Network

Two new types of devices must be deployed in this approach: a dual-stack home gateway and a dual-stack carrier-grade Network Address Translation (NAT). The dual-stack home gateway integrates IPv4 forwarding and v6-over-v4 tunneling functions. It can also integrate a v4-v4 NAT function. The dual-stack carrier-grade NAT (CGN) integrates v6-over-v4 tunneling and carrier-grade v4-v4 NAT functions.

Example 2: IPv4 Depletion with an IPv6 Access Network

In the scenario shown in Figure 7, the ISP network is IPv6-only.

Figure 7: IPv4 Depletion Solution - IPv6 Access NetworkIPv4 Depletion Solution - IPv6 Access Network

The dual-stack lite (DS-Lite) solution accommodates IPv6-only ISPs. The best business model for this approach is that the customer premises equipment (CPE) has integrated the functions for tunneling IPv6 to an IPv4 backbone, tunneling IPv4 to an IPv6 backbone, and can automatically detect which solution is required.

Not all customers of a given ISP must switch from IPv4 access to IPv6 access simultaneously; in fact, transition can be managed better by switching groups of customers (for example, all those connected to a single point of presence) on an incremental basis. Such an incremental approach should prove easier to plan, schedule, and execute than an across-the-board conversion.

Example 3: IPv4 Depletion for Mobile Networks

The complexity of mobile networks necessitates a flexible migration approach to ensure minimal disruption and maximum backward compatibility during transition. NAT64 can be used to enable IPv6 devices to communicate to IPv4 hosts without modifying the clients.

Junos OS Carrier-Grade NAT Implementation Overview

Junos OS enables you to implement and scale a Carrier-Grade Network Address Translation (CGNAT) solution based on the type of services interfaces used for your implementation:

  • MultiServices Denser Port Concentrator (MS-DPC)—The layer 3 services package is used to configure NAT for MS-DPC adaptive services PICs. This solution provides the NAT functionality described in Junos Address Aware Network Addressing Overview.

  • MS-100, MS-400, and MS-500 MultiServices PICS—The layer 3 services package is used to configure NAT for multiservices PICs. This solution provides the NAT functionality described in Junos Address Aware Network Addressing Overview.

  • MultiServices Modular Port Concentrator (MS-MPC) and MultiServices Modular Interface Card (MS-MIC)—MS-MPCs and MS-MICs are pre-configured to enable configuration of carrier-grade NAT. This solution provides the NAT functionality described in Junos Address Aware Network Addressing Overview.

  • Inline NAT for Modular Port Concentrator (MPC) Line Cards)—Inline NAT leverages the services capabilities of MPC line cards, allowing a cost-effective implementation of NAT functionality on the data plane, as described in Inline Network Address Translation Overview.

Carrier-Grade NAT Feature Comparison for Junos Address Aware by Type of Interface Card

Table 1 summarizes feature differences among the Junos OS carrier-grade NAT implementations.

Starting in Junos OS release 17.2R1, inline NAT is supported on the MPC5E and MPC6E.

Starting in Junos OS release 17.4R1, inline NAT is supported on the MPC7E, MPC8E, and MPC9E.

Table 1: Carrier-Grade NAT—Feature Comparison by Platform

Feature

MS-DPC

MS-100

MS-400

MS-500

MS-MPC

MS-MIC

MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E, and MPC9E

Inline NAT

Static Source NAT

yes

yes

yes

Dynamic Source NAT - Address Only

yes

yes

no

Dynamic Source NAT - NAPT Port Translation with Secured Port Block Allocation

yes

yes (Dynamic Source NAT - NAPT Port Translation with Secured Port Block Allocation supported for MS-MPC and MS-MIC starting in Junos OS Release 14.2R2)

no

Dynamic Source NAT - NAPT44 Port Translation with Deterministic Port Block Allocation

yes

yes (Dynamic Source NAT - NAPT44 Port Translation with Deterministic Port Block Allocation supported for MS-MPC and MS-MIC starting in Junos OS release 17.3R1, in Junos OS release 14.2R7 and later 14.2 releases, in 15.1R3 and later 15.1 releases, and in 16.1R5 and later 16.1 releases)

no

Dynamic Source NAT - NAPT64 Port Translation with Deterministic Port Block Allocation

No

yes (Dynamic Source NAT - NAPT64 Port Translation with Deterministic Port Block Allocation supported for MS-MPC and MS-MIC starting in Junos OS release 17.4R1)

No

Static Destination NAT

yes

yes

yes

Note:

Destination NAT can be implemented indirectly. See Inline Network Address Translation Overview

Twice NAT

yes

yes (Twice NAT supported for MS-MPC and MS-MIC starting in Junos OS Release 15.1R1)

yes

Note:

Twice NAT can be implemented indirectly. See Inline Network Address Translation Overview

NAPT - Preserve Parity and Range

yes

yes (NAPT - Preserve Parity and Range supported for MS-MPC and MS-MIC starting in Junos OS release 15.1R1)

no

NAPT - APP/EIF/EIM

yes

yes

no

IKE ALG

no

yes (Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1)

no

Stateful NAT64

yes

yes

no

Stateful NAT64 with APP/EIM/EIF

no

yes

no

Stateful NAT64 with ALGs

  • FTP

  • IKE

  • TFTP

  • SIP

  • RTSP

  • PPPT

no

yes

no

DS-Lite

yes

yes (DS-Lite supported for MS-MPC and MS-MIC starting in Junos OS release 17.4R1)

no

6rd

yes

no

no

6to4

yes

no

no

464XLAT

no

yes (starting in Junos OS Release 17.1R1)

no

Overlap Address Across NAT Pool

yes

yes

no

Overload Pool

yes

no

no

Port Control Protocol

yes

yes (Port Control Protocol with NAPT44 is supported for MS-MPC and MS-MIC starting in Junos OS Release 17.4R1. Starting in Junos OS Release 18.2R1, Port Control Protocol on the MS-MPC and MS-MIC supports DS-Lite. PCP provides a mechanism to control the forwarding of incoming packets by upstream devices such as NAT44 and firewall devices, and a mechanism to reduce application keepalive traffic).

no

CGN-PIC

yes

no

no

AMS Support

no

yes

no

Port forwarding

yes

yes (Port forwarding is supported for MS-MPC and MS-MIC starting in Junos OS Release 17.4R1.)

no

No translation

yes

yes (No translation supported for MS-MPC and MS-MIC starting in Junos OS Release 15.1R1)

yes

Table 2 summarizes availability of translation types by type of line card.

Table 2: Carrier-Grade NAT Translation Types

Translation Type

MS-DPC

MS-100

MS-400

MS-500

MS-MPC

MS-MIC

MPC1, MPC2, MPC3, MPC5E, MPC6E, MPC7E, MPC8E, and MPC9E

Inline NAT

basic-nat44

yes

yes

yes

basic-nat66

yes

no

no

basic-nat-pt

yes

no

no

deterministic-napt44

yes

yes (deterministic-napt44 supported for MS-MPC and MS-MIC starting in Junos OS release 17.3R1, in Junos OS release 14.2R7 and later 14.2 releases, in 15.1R3 and later 15.1 releases, and in 16.1R5 and later 16.1 releases)

no

deterministic-napt64

no

yes (deterministic-napt64 supported for MS-MPC and MS-MIC starting in Junos OS release 17.4R1)

no

dnat-44

yes

yes

no

dynamic-nat44

yes

yes

no

napt-44

yes

yes

no

napt-66

yes

no

no

napt-pt

yes

no

no

stateful-nat464

no

yes (starting in Junos OS Release 17.1R1)

no

stateful-nat64

yes

yes

no

twice-basic-nat-44

yes

yes (twice-dynamic-nat-44 supported for MS-MPC and MS-MIC starting in Junos OS Release 15.1R1)

yes (twice-basic-nat-44 supported for inline NAT starting in Junos OS Release 15.1R1)

twice-dynamic-nat-44

yes

yes (twice-dynamic-nat-44 supported for MS-MPC and MS-MIC starting in Junos OS Release 15.1R1)

no

twice-dynamic-napt-44

yes

yes (twice-dynamic-napt-44 supported for MS-MPC and MS-MIC starting in Junos OS Release 15.1R1)

no

ALGs Available for Junos OS Address Aware NAT

The following Application Level Gateways (ALGs) listed in Table 3 are supported for NAT processing on the listed platforms.

To view the implementation details (port, protocol, and so on) for these Junos OS default applications, locate the Junos OS Default ALG Name in the table and then look up the listed name in the groups. For example, for details about TFTP, look up junos-tftp as shown.

Tip:

The Junos OS provides the junos-alg, which enables other ALGs to function by handling ALG registrations, causing slow path packets to flow through registered ALGs, and transferring ALG events to the ALG plug-ins. The junos-alg ALG is automatically available on the MS-MPC and MS-MIC platforms and does not require further configuration.

Note:

The remote shell (RSH) and remote login (rlogin) application layer gateways (ALGs) are not supported with network address port translation (NAPT) on MX Series routers with MS-MICs and MS-MPCs.

Table 3 summarizes the ALGs available for Junos OS Address Aware NAT for services interfaces cards.

Table 3: ALGs Available for NAT by Type of Interface Card

ALG

MS-DPC

MS-MPC, MS-MIC

Junos OS Default ALG Name

Basic TCP ALG

yes

yes

Note:

Specific Junos OS ALGs are not supported. However, a feature called TCP tracker, available by default, performs segment ordering and retransmit and connection tracking, validations for TCP connections.

Basic UDP ALG

yes

yes

Note:

TCP tracker performs limited integrity and validation checks for UDP.

BOOTP

yes

no

  • junos-bootpc

  • junos-bootps

DCE RPC Services

yes

yes

  • junos-dce-rpc-portmap

  • junos-dcerpc-endpoint-mapper-service

  • junos-dcerpc-msexchange-directory-nsp

  • junos-dcerpc-msexchange-directory-rfr

  • junos-dcerpc-msexchange-information-store

DNS

yes

yes

  • junos-dns-udp

DNS

no

no

  • junos-dns-tcp

FTP

yes

yes

  • junos-ftp

Gatekeeper RAS (Starting in Junos OS Release 17.1R1)

no

yes

  • junos-h323-ras

H323

no

yes

  • junos-h323

ICMP

yes

yes

Note:

In Junos OS Release 14.1 and earlier, ICMP messages are handled by default, but PING ALG support is not provided. Starting In Junos OS 14.2, ICMP messages are handled by default and PING ALG support is provided.

  • junos-icmp-all

  • junos-icmp-ping

IIOP

yes

no

  • junos-iiop-java

  • junos-iiop-orbix

IKE ALG

no

yes

Note:

Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG ALG is supported on MS-MPCs and MS-MICs.

  • junos-ike

IP

yes

The TCP tracker, available by default on these platforms, performs limited integrity and validation checks.

  • junos-ip

NETBIOS

yes

no

  • junos-netbios-datagram

  • junos-netbios-name-tcp

  • junos-netbios-name-udp

  • junos-netbios-session

NETSHOW

yes

no

  • junos-netshow

PPTP

yes

yes

  • junos-pptp

REALAUDIO

yes

no

  • junos-realaudio

Sun RPC and RPC Port Map Services

yes

yes

  • junos-rpc-portmap-tcp

  • junos-rpc-portmap-udp

RTSP

yes

yes

  • junos-rtsp

SIP

yes

Yes

  • junos-sip

The SIP callid is not translated in register messages.

Note:

SIP sessions are limited to 12 hours (720 minutes) for NAT processing on the MS-MIC and MS-MPC interface cards. SIP sessions on the MS-DPC have no time limits.

SNMP

yes

No

  • junos-snmp-get

  • junos-snmp-get-next

  • junos-snmp-response

  • junos-snmp-trap

SQLNET

yes

yes

  • junos-sqlnet

TFTP

yes

yes

  • junos-tftp

Traceroute

yes

yes

  • junos-traceroute

Unix Remote Shell Service

yes

yes

Note:

Remote Shell (RSH) ALG is not supported for network address port translation (NAPT).

  • junos-rsh

WINFrame

yes

No

  • junos-citrix-winframe

  • junos-citrix-winframe-udp

TALK-UDP

No

Yes

  • junos-talk-udp

MS RPC

No

Yes

  • junos-rpc-portmap-tcp

  • junos-rpc-portmap-udp

  • junos-rpc-services-tcp

  • junos-rpc-services-udp

ALGs Available by Default for Junos OS Address Aware NAT on ACX500 Router

The following Application Level Gateways (ALGs) listed in Table 4 are supported for NAT processing on ACX500 routers.

To view the implementation details (port, protocol, and so on) for these Junos OS default applications, locate the Junos OS Default ALG Name in the table and then look up the listed name in the groups. For example, for details about TFTP, look up junos-tftp as shown.

Note:

The ALG for NAT is supported only on the ACX500 indoor routers.

Tip:

The Junos OS provides the junos-alg, which enables other ALGs to function by handling ALG registrations, causing slow path packets to flow through registered ALGs, and transferring ALG events to the ALG plug-ins. The junos-alg ALG is automatically available on the ACX500 router and does not require further configuration.

Note:

The remote login (rlogin) application layer gateways (ALGs) are not supported with network address port translation (NAPT) on ACX500 router.

Table 4: ALGs Available by Default

ALG

ACX500 Router

Junos OS Default ALG Name

Basic TCP ALG

yes

Note:

Specific Junos OS ALGs are not supported. However, a feature called TCP tracker, available by default, performs segment ordering and retransmit and connection tracking, validations for TCP connections.

Basic UDP ALG

yes

Note:

TCP tracker performs limited integrity and validation checks for UDP.

DNS

yes

  • junos-dns-tcp

  • junos-dns-udp

FTP

yes

  • junos-ftp

ICMP

yes

Note:

ICMP messages are handled by default, but PING ALG support is not provided.

  • junos-icmp-all

TFTP

yes

  • junos-tftp

Unix Remote Shell Service

yes

Note:

Remote Shell (RSH) ALG is not supported for network address port translation (NAPT).

  • junos-rsh

ALG Support Details

This section includes details about the ALGs. It includes the following:

Basic TCP

This ALG performs basic sanity checking on TCP packets. If it finds errors, it generates the following anomaly events and system log messages:

  • TCP source or destination port zero

  • TCP header length check failed

  • TCP sequence number zero and no flags are set

  • TCP sequence number zero and FIN/PSH/RST flags are set

  • TCP FIN/RST or SYN(URG|FIN|RST) flags are set

The TCP ALG performs the following steps:

  1. When the router receives a SYN packet, the ALG creates TCP forward and reverse flows and groups them in a conversation. It tracks the TCP three-way handshake.

  2. The SYN-defense mechanism tracks the TCP connection establishment state. It expects the TCP session to be established within a small time interval (currently 4 seconds). If the TCP three-way handshake is not established in that period, the session is terminated.

  3. A keepalive mechanism detects TCP sessions with nonresponsive endpoints.

  4. ICMP errors are allowed only when a flow matches the selector information specified in the ICMP data.

Basic UDP

This ALG performs basic sanity checking on UDP headers. If it finds errors, it generates the following anomaly events and system log messages:

  • UDP source or destination port 0

  • UDP header length check failed

The UDP ALG performs the following steps:

  1. When it receives the first packet, the ALG creates bidirectional flows to accept forward and reverse UDP session traffic.

  2. If the session is idle for more than the maximum allowed idle time (the default is 30 seconds), the flows are deleted.

  3. ICMP errors are allowed only when a flow matches the selector information specified in the ICMP data.

DNS

The Domain Name System (DNS) ALG handles data associated with locating and translating domain names into IP addresses. The ALG typically runs on port 53. The ALG monitors DNS query and reply packets and supports only UDP traffic. The ALG does not support payload translations. The DNS ALG closes the session only when a reply is received or an idle timeout is reached.

The following is an example for configuring DNS ALG:

  1. Creating NAT interface.

  2. Configuring NAT pool.

  3. Defining NAT rules for DNS ALG.

  4. Binding service sets to the interface.

FTP

FTP is the File Transfer Protocol, specified in RFC 959. In addition to the main control connection, data connections are also made for any data transfer between the client and the server; and the host, port, and direction are negotiated through the control channel.

For non-passive-mode FTP, Junos OS stateful firewall service scans the client-to-server application data for the PORT command, which provides the IP address and port number to which the server connects. For passive-mode FTP, Junos OS stateful firewall service scans the client-to-server application data for the PASV command and then scans the server-to-client responses for the 227 response, which contains the IP address and port number to which the client connects.

There is an additional complication: FTP represents these addresses and port numbers in ASCII. As a result, when addresses and ports are rewritten, the TCP sequence number might be changed, and thereafter the NAT service needs to maintain this delta in SEQ and ACK numbers by performing sequence NAT on all subsequent packets.

Support for stateful firewall and NAT services requires that you configure the FTP ALG on TCP port 21 to enable the FTP control protocol. The ALG performs the following tasks:

  • Automatically allocates data ports and firewall permissions for dynamic data connection

  • Creates flows for the dynamically negotiated data connection

  • Monitors the control connection in both active and passive modes

  • Rewrites the control packets with the appropriate NAT address and port information

On ACX500, for passive FTP to work properly without FTP application layer gateway (ALG) enabled (by not specifying the application junos-ftp statement at the [edit services nat rule rule-name term term-name from] hierarchy level), you must enable the address pooling paired (APP) functionality enabled (by including the address-pooling statement at the [edit services nat rule rule-name term term-name then translated] hierarchy level). Such a configuration causes the data and control FTP sessions to receive the same NAT address.

The following is an example for configuring FTP ALG:

  1. Creating NAT interface.

  2. Configuring NAT pool.

  3. Defining NAT rules for FTP ALG.

  4. Binding service sets to the interface.

ICMP

The Internet Control Message Protocol (ICMP) is defined in RFC 792. The Junos OS allows ICMP messages to be filtered by specific type or specific type code value. ICMP error packets that lack a specifically configured type and code are matched against any existing flow in the opposite direction to check for the legitimacy of the error packet. ICMP error packets that pass the filter matching are subject to NAT translation.

The ICMP ALG always tracks ping traffic statefully using the ICMP sequence number. Each echo reply is forwarded only if there is an echo request with the corresponding sequence number. For any ping flow, only 20 echo requests can be forwarded without receiving an echo reply. When you configure dynamic NAT, the PING packet identifier is translated to allow additional hosts in the NAT pool to use the same identifier.

Support for NAT services requires that you configure the ICMP ALG if the protocol is needed. You can configure the ICMP type and code for additional filtering.

TFTP

The Trivial File Transfer Protocol (TFTP) is specified in RFC 1350. The initial TFTP requests are sent to UDP destination port 69. Additional flows can be created to get or put individual files. Support of NAT services requires that you configure the TFTP ALG for UDP destination port 69.

The following is an example for configuring TFTP ALG:

  1. Creating NAT interface.

  2. Configuring NAT pool.

  3. Defining NAT rules for TFTP ALG.

  4. Binding service sets to the interface.

UNIX Remote-Shell Services

Three protocols form the basis for UNIX remote-shell services:

  • Exec—Remote command execution; enables a user on the client system to execute a command on the remote system. The first command from client (rcmd) to server (rshd) uses well-known TCP port 512. A second TCP connection can be opened at the request of rcmd. The client port number for the second connection is sent to the server as an ASCII string.

  • Login—Better known as rlogin; uses well-known TCP port 513. For details, see RFC 1282. No special firewall processing is required.

  • Shell—Remote command execution; enables a user on the client system to execute a command on the remote system. The first command from client (rcmd) to server (rshd) uses well-known TCP port 514. A second TCP connection can be opened at the request of rcmd. The client port number for the second connection is sent to the server as an ASCII string.

NAT remote-shell services require that any dynamic source port assigned be within the port range 512 to 1023. If you configure a NAT pool, this port range is reserved exclusively for remote shell applications.

The following is an example for configuring RSH ALG:

  1. Creating NAT interface.

  2. Configuring NAT pool.

  3. Defining NAT rules for RSH ALG.

  4. Binding service sets to the interface.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
19.2R1
Starting in Junos OS release 19.2R1, DS-Lite is supported on MX Virtual Chassis and MX Broadband Network Gateway (BNG) routers.
17.4R1
Starting in Junos OS Release 17.4R1, deterministic NAPT64 is supported on the MS-MPC and MS-MIC.
17.4R1
Starting in Junos OS release 17.4R1, DS-Lite is supported on MX Series routers with MS-MPCs and MS-MICs.
17.4R1
Starting in Junos OS release 17.4R1, inline NAT is supported on the MPC7E, MPC8E, and MPC9E.
17.4R1
Dynamic Source NAT - NAPT64 Port Translation with Deterministic Port Block Allocation supported for MS-MPC and MS-MIC
17.4R1
DS-Lite supported for MS-MPC and MS-MIC
17.4R1
deterministic-napt64 supported for MS-MPC and MS-MIC
17.4.R1
Port forwarding is supported for MS-MPC and MS-MIC
17.2R1
Starting in Junos OS release 17.2R1, inline NAT is supported on the MPC5E and MPC6E.
17.1R4
Port Control Protocol with NAPT44 is supported for MS-MPC and MS-MIC
17.1R1
Starting in Junos OS Release 17.1R1, you can configure a 464XLAT Provider-Side Translater (PLAT).
17.1R1
464XLAT
17.1R1
stateful-nat464
17.1R1
Gatekeeper RAS (Starting in Junos OS Release 17.1R1)
15.1R1
Twice NAT supported for MS-MPC and MS-MIC
15.1R1
NAPT - Preserve Parity and Range supported for MS-MPC and MS-MIC
15.1R1
No translation supported for MS-MPC and MS-MIC
15.1R1
twice-dynamic-nat-44 supported for MS-MPC and MS-MIC
15.1R1
twice-basic-nat-44 supported for inline NAT
15.1R1
twice-dynamic-nat-44 supported for MS-MPC and MS-MIC
15.1R1
twice-dynamic-napt-44 supported for MS-MPC and MS-MIC
14.2R7
Dynamic Source NAT - NAPT44 Port Translation with Deterministic Port Block Allocation supported for MS-MPC and MS-MIC
14.2R7
IKE ALG
14.2R7
deterministic-napt44 supported for MS-MPC and MS-MIC
14.2R7
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG ALG is supported on MS-MPCs and MS-MICs.
14.2R2
Dynamic Source NAT - NAPT Port Translation with Secured Port Block Allocation supported for MS-MPC and MS-MIC
14.2
Starting In Junos OS 14.2, ICMP messages are handled by default and PING ALG support is provided.