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 Concept and Facilities Overview
- IPv4-to-IPv4 Basic NAT
- Deterministic NAPT
- Static Destination NAT
- Twice NAT
- IPv6 NAT
- Application-Level Gateway (ALG) Support
- NAT-PT with DNS ALG
- Dynamic NAT
- Stateful NAT64
- 464XLAT
- Dual-Stack Lite
- Junos Address Aware Network Addressing Line Card Support
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.
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.
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.
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.
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).
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).
Dual-Stack Lite
Dual-stack lite (DS-Lite) flow is shown in Figure 5.
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.
See Also
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
- Example 2: IPv4 Depletion with an IPv6 Access Network
- Example 3: IPv4 Depletion for Mobile Networks
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.
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.
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.
See Also
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.
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
|
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.
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 |
|---|---|---|---|
|
yes |
yes |
yes |
|
yes |
no |
no |
|
yes |
no |
no |
|
yes |
yes ( |
no |
|
no |
yes ( |
no |
|
yes |
yes |
no |
|
yes |
yes |
no |
|
yes |
yes |
no |
|
yes |
no |
no |
|
yes |
no |
no |
|
no |
yes (starting in Junos OS Release 17.1R1) |
no |
|
yes |
yes |
no |
|
yes |
yes ( |
yes ( |
|
yes |
yes ( |
no |
|
yes |
yes ( |
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.
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.
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.
user@host# show groups junos-defaults applications application junos-tftp application-protocol tftp; protocol udp; destination-port 69;
Table 3 summarizes the ALGs available for Junos OS Address Aware NAT for services interfaces cards.
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 |
|
DCE RPC Services |
yes |
yes |
|
DNS |
yes |
yes |
|
DNS |
no |
no |
|
FTP |
yes |
yes |
|
Gatekeeper RAS (Starting in Junos OS Release 17.1R1) |
no |
yes |
|
H323 |
no |
yes |
|
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. |
|
IIOP |
yes |
no |
|
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. |
|
IP |
yes |
The TCP tracker, available by default on these platforms, performs limited integrity and validation checks. |
|
NETBIOS |
yes |
no |
|
NETSHOW |
yes |
no |
|
PPTP |
yes |
yes |
|
REALAUDIO |
yes |
no |
|
Sun RPC and RPC Port Map Services |
yes |
yes |
|
RTSP |
yes |
yes |
|
SIP |
yes |
Yes |
The SIP 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 |
|
SQLNET |
yes |
yes |
|
TFTP |
yes |
yes |
|
Traceroute |
yes |
yes |
|
Unix Remote Shell Service |
yes |
yes Note:
Remote Shell (RSH) ALG is not supported for network address port translation (NAPT). |
|
WINFrame |
yes |
No |
|
TALK-UDP |
No |
Yes |
|
MS RPC |
No |
Yes |
|
See Also
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.
The ALG for NAT is supported only on the ACX500 indoor routers.
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.
The remote login (rlogin) application layer gateways (ALGs) are not supported with network address port translation (NAPT) on ACX500 router.
|
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 |
|
|
FTP |
yes |
|
|
ICMP |
yes Note:
ICMP messages are handled by default, but PING ALG support is not provided. |
|
|
TFTP |
yes |
|
|
Unix Remote Shell Service |
yes Note:
Remote Shell (RSH) ALG is not supported for network address port translation (NAPT). |
|
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:
-
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.
-
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.
-
A keepalive mechanism detects TCP sessions with nonresponsive endpoints.
-
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:
-
When it receives the first packet, the ALG creates bidirectional flows to accept forward and reverse UDP session traffic.
-
If the session is idle for more than the maximum allowed idle time (the default is 30 seconds), the flows are deleted.
-
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:
-
Creating NAT interface.
[edit] services { service-set set-dns { nat-rules nat-dns; interface-service { service-interface ms-0/2/0; } } -
Configuring NAT pool.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Defining NAT rules for DNS ALG.
[edit] services { nat { rule nat-dns { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-dns-udp;; } then { translated { source-pool p-napt; translation-type { basic-nat44; } } } } } } -
Binding service sets to the interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-dns; } output { service-set set-dns; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
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:
-
Creating NAT interface.
[edit] services { service-set set-ftp { nat-rules nat-ftp; interface-service { service-interface ms-0/2/0; } } -
Configuring NAT pool.
[edit] services { nat { pool p-napt { address 10.30.30.0/24; port { range low 9000 high 9010; } } } -
Defining NAT rules for FTP ALG.
[edit] services { nat { rule nat-ftp { match-direction input; term term1 { from { source-address { 10.10.10.0/24; } applications junos-ftp; } then { translated { source-pool p-napt; translation-type { napt-44; } } } } } } -
Binding service sets to the interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-ftp; } output { service-set set-ftp; } } address 10.10.10.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.10.10.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
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:
-
Creating NAT interface.
[edit] services { service-set set-tftp { nat-rules nat-tftp; interface-service { service-interface ms-0/2/0; } } -
Configuring NAT pool.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Defining NAT rules for TFTP ALG.
[edit] services { nat { rule nat-tftp { match-direction input; term term1 { from { source-address { 10.50.50.2/32; } applications junos-tftp; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Binding service sets to the interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-tftp; } output { service-set set-tftp; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
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 ofrcmd. 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 ofrcmd. 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:
-
Creating NAT interface.
[edit] services { service-set set-rsh { nat-rules nat-rsh; interface-service { service-interface ms-0/2/0; } } -
Configuring NAT pool.
[edit] services { nat { pool p-napt { address 10.1.1.1/32; } } } -
Defining NAT rules for RSH ALG.
[edit] services { nat { rule nat-rsh { match-direction input; term term1 { from { source-address { 510.0.50.2/32; } applications junos-rsh; } then { translated { source-pool p-napt; translation-type { dynamic-nat44; } } } } } } -
Binding service sets to the interface.
[edit] interfaces { ge-0/1/0 { media-type copper; unit 0 { family inet { service { input { service-set set-rsh; } output { service-set set-rsh; } } address 10.50.50.1/24; } } } ge-0/1/1 { media-type copper; unit 0 { family inet { address 10.60.60.1/24; } } } ms-0/2/0 { unit 0 { family inet; } } }
See Also
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.
deterministic-napt64 supported for MS-MPC and MS-MICstateful-nat464twice-dynamic-nat-44 supported for MS-MPC and MS-MICtwice-basic-nat-44 supported for inline NATtwice-dynamic-nat-44 supported for MS-MPC and MS-MICtwice-dynamic-napt-44 supported for MS-MPC and MS-MICdeterministic-napt44 supported for MS-MPC and MS-MIC