Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ALG Overview

 

ALG Descriptions

This topic describes the Application Layer Gateways (ALGs) supported by Junos OS. ALG support includes managing pinholes and parent-child relationships for the supported ALGs.

Supported ALGs

Table 1 lists ALGs supported by Junos OS. For information about which ALGs are supported on MS-DPCs, MS-MPCs, MS-MICs, see ALGs Available for Junos OS Address Aware NAT.

Table 1: ALGs Supported by Junos OS

ALGs Supported

v4 - v4

v6 - v4

v6 - v6

DS-Lite (Support for ALGs with DS-lite on MS-MPC and MS-MIC starts in Junos OS Release 18.1R1)

Basic TCP ALG

Yes

Yes

Yes

Yes

Basic UPD ALG

Yes

Yes

Yes

Yes

BOOTP

Yes

No

No

No

DCE RPC Services

Yes

No

No

No

DNS

Yes

Yes

No

Yes

FTP

Yes

Yes (Starting in Junos OS Release 14.1R1)

No

Yes

Gatekeeper RAS

Yes (Starting in Junos OS Release 17.1R1)

Yes (Starting in Junos OS Release 17.2R1)

No

No

H323

Yes

Yes (Starting in Junos OS Release 17.2R1)

No

No

ICMP

Yes

Yes

Yes

Yes

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

Yes

Yes

No

No

IIOP

Yes

No

No

No

IP

Yes

No

No

No

NETBIOS

Yes

No

No

No

NETSHOW

Yes

No

No

No

PPTP

Yes

Yes (Starting in Junos OS Release 14.1R1)

No

Yes

REALAUDIO

Yes

No

No

No

Sun RPC and RPC Port Map Services

Yes

No

No

No

RTSP

Yes

Yes (Starting in Junos OS Release 14.1R1)

No

Yes

SIP

Yes

Yes (Starting in Junos OS Release 14.1R1)

No

SIP supported for DS-Lite on MS-MPC and MS-MIC starting in Junos OS Release 18.2R1.

SNMP

Yes

No

No

No

SQLNET

Yes

No

No

No

TFTP

Yes

Yes (Starting in Junos OS Release 14.1R1)

No

Yes

Traceroute

Yes

Yes

No

Yes

Unix Remote Shell Service

Yes

No

No

No

WINFrame

Yes

No

No

No

ALG Support Details

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

Basic TCP ALG

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 ALG

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.

BOOTP

The Bootstrap Protocol (BOOTP) client retrieves its networking information from a server across the network. It sends out a general broadcast message to request the information, which is returned by the BOOTP server. For the protocol specification, see ftp://ftp.isi.edu/in-notes/rfc951.txt.

Stateful firewall support requires that you configure the BOOTP ALG on UDP server port 67 and client port 68. If the client sends a broadcast message, you should configure the broadcast address in the from statement of the service rule. Network Address Translation (NAT) is not performed on the BOOTP traffic, even if the NAT rule matches the traffic. If the BOOTP relay feature is activated on the router, the remote BOOTP server is assumed to assign addresses for clients masked by NAT translation.

DCE RPC Services

Distributed Computing Environment (DCE) Remote Procedure Call (RPC) services are mainly used by Microsoft applications. The ALG uses well-known TCP port 135 for port mapping services, and uses the universal unique identifier (UUID) instead of the program number to identify protocols. The main application-based DCE RPC is the Microsoft Exchange Protocol.

Support for stateful firewall and NAT services requires that you configure the DCE RPC portmap ALG on TCP port 135. The DCE RPC ALG uses the TCP protocol with application-specific UUIDs.

DNS

The Domain Name System (DNS), which typically runs on port 53, handles the data associated with locating and translating domain names into IP addresses. The MX Series DNS ALG monitors the DNS query and reply packets, and supports UDP and TCP DNS traffic independently. The DNS ALG does not support payload translations for NAT, but an operator can use it to efficiently remove the NAT or stateful firewall DNS sessions from memory after the DNS server sends its response. The DNS ALG closes the session only when a reply is received or an idle timeout is reached.

There might be issues with TCP DNS traffic when the TCP-DNS-ALG is used if the DNS traffic is not just the standard request and reply type. For example, the TCP-DNS-ALG might break DNS server-to-server communication that uses TCP, such as DNS Replication or Zone transfers. This type of traffic might get dropped by the NAT or stateful firewall plugins because the TCP-DNS-ALG closes the session after the TCP handshake is complete and after each server has sent one packet to the other. In these instances do not use the TCP-DNS-ALG.

Note

The TCP-DNS-ALG is not supported on the MS-DPC service cards.

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 MS-MPCs, MS-MICs, 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 stateful-firewall rule rule-name term term-name from] and the [edit services nat rule rule-name term term-name from] hierarchy levels), 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.

Gatekeeper RAS

Starting in Junos OS Release 17.1R1, the gatekeeper registration, administration, and status (RAS) ALG allows full support of gatekeeper mode for H.323 calls. An endpoint registers to a gatekeeper and asks for its management. Before making a call, an endpoint asks its gatekeeper for permission to place the call. In both registration and admission phases, the RAS channel is used. Use the gatekeeper RAS ALG and the H323 ALG in IPv4 and IPv6 stateful-firewall rules or NAPT-44 rules. Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported. The Junos default application set junos-h323-suite includes the H323 ALG and the gatekeeper RAS ALG.

H323

H323 is a suite of ITU protocols for audio and video conferencing and collaboration applications. H323 consists of H.225 call signaling protocols and H.245 control protocol for media communication. During H.225 negotiation, the endpoints create a call by exchanging call signaling messages on the control channel and negotiate a new control channel for H.245. A new control connection is created for H.245 messages. Messages are exchanged on the H.245 control channel to open media channels.

Stateful firewall monitors the H.225 control channel to open the H.245 control channel. After the H.245 channel is created, stateful firewall also monitors this channel for media channel information and allows the media traffic through the firewall.

H323 ALG supports static destination, static and dynamic source NAT by rewriting the appropriate addresses and ports in the H.225 and H.245 messages.

To support gatekeeper mode for H.323 calls, use the H323 ALG and the gatekeeper RAS ALG in IPv4 and IPv6 stateful-firewall rules or NAPT-44 rules. Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported. The Junos default application set junos-h323-suite includes the H323 ALG and the gatekeeper RAS ALG.

ICMP

The Internet Control Message Protocol (ICMP) is defined in RFC 792. The Junos OS stateful firewall service 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 stateful firewall and 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.

IIOP

The Oracle Application Server Name Server Internet Inter-ORB Protocol (IIOP). This ALG is used in Common Object Request Broker Architecture (CORBA) based on distributed computing. Even though CORBA and IIOP are Object Management Group (OMG) standards, no fixed port is assigned for IIOP. Each vendor implementing CORBA chooses a port. Java Virtual machine uses port 1975 by default, while ORBIX uses port 3075 as a default.

Stateful firewall and NAT require ALG IIOP be configured for TCP port 1975 for Java VM IIOP, and 3075 for CORBA applications ORBIX, a CORBA framework from Iona Technologies.

IKE ALG

Before Junos OS Release 17.4R1, Network Address Translation-Traversal (NAT-T) is not supported for the Junos VPN Site Secure suite of IPsec features on the MX Series routers. Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG enables the passing of IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec peers that are not NAT-T compliant. This ALG supports only ESP tunnel mode.

Use this ALG in NAT rules and specify the UDP protocol and port 500.

This ALG performs the following:

  • Tracks IKEv1 connection-initiation requests to determine whether NAT processing is required.

  • Performs NAT translation on outgoing and incoming IKEv1 requests and creates IKE sessions.

  • Identifies IPsec packets related to the established IKE session and establishes security association between peers.

  • Performs NAT translation on IPsec packets.

IP

The IP ALG is used to create unidirectional flows only. In case of TCP traffic, it does not check the 3-way handshake process. This ALG is useful in case of stateful firewall only service sets, where it allows traffic to flow uni-directionally only. When configuring in conjunction with match-direction input-output it allows the return traffic to flow through the stateful firewall as well. Typical scenarios are static NAT, destination NAT or scenarios where traffic is expected to traverse the stateful firewall in the presence of asymmetric routing. The Junos IP ALG is not intended for use with NAPT, which causes matching traffic to be discarded through the creation of a drop flow.

NetBIOS

A NetBIOS ALG translates NetBIOS IP addresses and port numbers when NAT is used.

NetBIOS supports the TCP and UDP transport protocols. Support for stateful firewall and NAT services requires that you configure the NetBIOS ALG on UDP port 138 and TCP port 139.

NetShow

The Microsoft protocol ms-streaming is used by NetShow, the Microsoft media server. This protocol supports several transport protocols: TCP, UDP, and HTTP. The client starts a TCP connection on port 1755 and sends the PORT command to the server. The server then starts UDP on that port to the client. Support for stateful firewall and NAT services requires that you configure the NetShow ALG on UDP port 1755.

ONC RPC Services

Open Networks Computing (ONC) RPC services function similarly to DCE RCP services. However, the ONC RPC ALG uses TCP/UDP port 111 for port mapping services, and uses the program number to identify protocols rather than the UUID.

Support for stateful firewall and NAT services requires that you configure the ONC RPC portmap ALG on TCP port 111. The ONC RPC ALG uses the TCP protocol with application-specific program numbers.

PPTP

The Point-to-Point Tunneling Protocol (PPTP) ALG is a TCP-based ALG. PPTP allows the Point-to-Point Protocol (PPP) to be tunneled through an IP network. PPTP defines a client-server architecture, a PPTP Network Server, and a PPTP Access Concentrator. The PPTP ALG requires a control connection and a data tunnel. The control connection uses TCP to establish and disconnect PPP sessions, and runs on port 1723. The data tunnel carries PPP traffic in generic routing encapsulated (GRE) packets that are carried over IP.

RealAudio

Real Networks PNA protocol RealVideo is not a separate service. It is part of the RealPlayer and most likely uses another channel for video. The RealPlayer versions G2, 7, and 8 use PNA and RTSP. For this version to work, the ALG must allow both PNA(7070) and RTSP(554). For the media, the server selects from a range of UDP ports(6970 through 7170), or TCP port 7071, or HTTP. The client can be configured to use a particular port. The RealPlayer versions 4.0 and 5.0 use control channel 7070 media UDP ports 6970 through 7170, or TCP port 7071, or HTTP. RealAudio player version 3.0 uses control channel 7070 media, UDP ports 6770-7170, or TCP port 7071.

Real products use the ports and ranges of ports shown in Table 2.

Table 2: RealAudio Product Port Usage

Real Product

Port Usage

4.0 and 5.0 Servers/Players

Control channel (bidirectional) on TCP port 7070. Data channel from server to player on TCP port 7070 or UDP port 6970-7170.

4.0 and 5.0 Servers/Encoders

Control channel (bidirectional) on TCP port 7070. Data channel from encoder or server on TCP port 7070.

G2 Servers/Players

Control channel (bidirectional) on TCP port 80, 554, 7070, or 8080. Data channel from server to player on TCP port 80, 554, 7070, 8080 or UDP port 6970-32,000.

G2 Server/3.1, and 5.x Encoders

Control channel (bidirectional) on TCP port 7070. Data channel from encoder to server on TCP port 7070.

G2 Server/G2 Producer

Control channel (bidirectional) on TCP port 4040. Data channel from encoder to server on TCP port 4040 and UDP port 6970-32,000.

2 Server/G2 Producer (TCP ONLY)

Control channel (bidirectional) on TCP port 4040 Data channel from encoder to server on TCP port 4040. Note: TCP-ONLY option available in version 6.1 or above.

Note

RealAudio was the original protocol by RealPlayers. Newer versions of RealPlayer use RTSP. Stateful firewall and NAT require ALG RealAudio to be programmed on TCP port 7070.

Sun RPC and RPC Portmap Services

The Remote Procedure Call (RPC) ALG uses well-known ports TCP 111 and UDP 111 for port mapping, which dynamically assigns and opens ports for RPC services. The RPC Portmap ALG keeps track of port requests and dynamically opens the firewall for these requested ports. The RPC ALG can further restrict the RPC protocol by specifying allowed program numbers.

The ALG includes the RPC services listed in Table 3.

Table 3: Supported RPC Services

Name

Description

Comments

rpc-mountd

Network File Server (NFS) mount daemon; for details, see the UNIX man page for rpc.mountd(8).

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050).

rpc-nfsprog

Used as part of NFS. For details, see RFC 1094. See also RFC1813 for NFS v3.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050).

rpc-nisplus

Network Information Service Plus (NIS+), designed to replace NIS; it is a default naming service for Sun Solaris and is not related to the old NIS. No protocol information is available.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050).

rpc-nlockmgr

Network lock manager.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-nlockmgr service can be allowed or blocked based on RPC program 100021.

rpc-pcnfsd

Kernel statistics server. For details, see the UNIX man pages for rstatd and rpc.rstatd.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-rstat service can be allowed or blocked based on RPC program 150001.

rpc-rwall

Used to write a message to users; for details, see the UNIX man page for rpc.rwalld.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-rwall service can be allowed or blocked based on RPC program 150008.

rpc-ypbind

NIS binding process. For details, see the UNIX man page for ypbind.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-ypbind service can be allowed or blocked based on RPC program 100007.

rpc-yppasswd

NIS password server. For details, see the UNIX man page for yppasswd.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-yppasswd service can be allowed or blocked based on RPC program 100009.

rpc-ypserv

NIS server. For details, see the UNIX man page for ypserv.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-ypserv service can be allowed or blocked based on RPC program 100004.

rpc-ypupdated

Network updating tool.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-ypupdated service can be allowed or blocked based on RPC program 100028.

rpc-ypxfrd

NIS map transfer server. For details, see the UNIX man page for rpc.ypxfrd.

The base support is RPC v2 and the port mapper service on port 111 (see RFC 1050). Once the RPC program table is built, rpc-ypxfrd service can be allowed or blocked based on RPC program 100069.

Support for stateful firewall and NAT services that use port mapping requires that you configure the RPC portmap ALG on TCP/UDP destination port 111 and the RPC ALG for both TCP and UDP. You can specify one or more rpc-program-number values to further restrict allowed RPC protocols.

RTSP

The Real-Time Streaming Protocol (RTSP) controls the delivery of data with real-time properties such as audio and video. The streams controlled by RTSP can use RTP, but it is not required. Media can be transmitted on the same RTSP control stream. This is an HTTP-like text-based protocol, but client and server maintain session information. A session is established using the SETUP message and terminated using the TEARDOWN message. The transport (the media protocol, address, and port numbers) is negotiated in the setup and the setup-response.

Support for stateful firewall and NAT services requires that you configure the RTSP ALG for TCP port 554.

The ALG monitors the control connection, opens flows dynamically for media (RTP/RTSP) streams, and performs NAT address and port rewrites.

SIP

The Session Initiation Protocol (SIP) is an application layer protocol that can establish, maintain, and terminate media sessions. It is a widely used voice over IP (VoIP) signaling protocol. The SIP ALG monitors SIP traffic and dynamically creates and manages pinholes on the signaling and media paths. The ALG only allows packets with the correct permissions. The SIP ALG also performs the following functions:

  • Manages parent-child session relationships.

  • Enforces security policies.

  • Manages pinholes for VoIP traffic.

The SIP ALG supports the following features:

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 limit.

SNMP

SNMP is a communication protocol for managing TCP/IP networks, including both individual network devices and aggregated devices. The protocol is defined by RFC 1157. SNMP runs on top of UDP.

The Junos OS stateful firewall service implements the SNMP ALG to inspect the SNMP type. SNMP does not enforce stateful flow. Each SNMP type needs to be specifically enabled. Full SNMP support of stateful firewall services requires that you configure the SNMP ALG on UDP port 161. This enables the SNMP get and get-next commands, as well as their response traffic in the reverse direction: UDP port 161 enables the SNMP get-response command. If SNMP traps are permitted, you can configure them on UDP port 162, enabling the SNMP trap command.

SQLNet

The SQLNet protocol is used by Oracle SQL servers to execute SQL commands from clients, including load balancing and application-specific services.

Support of stateful firewall and NAT services requires that you configure the SQLNet ALG for TCP port 1521.

The ALG monitors the control packets, opens flows dynamically for data traffic, and performs NAT address and port rewrites.

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 stateful firewall and NAT services requires that you configure the TFTP ALG for UDP destination port 69.

Traceroute

Traceroute is a tool for displaying the route that packets take to a network host. It uses the IP time-to-live (TTL) field to trigger ICMP time-exceeded messages from routers or gateways. It sends UDP datagrams to destination ports that are believed to be not in use; destination ports are numbered using the formula: + nhops – 1. The default base port is 33434. To support traceroute through the firewall, two types of traffic must be passed through:

  1. UDP probe packets (UDP destination port > 33000, IP TTL < 30)

  2. ICMP response packets (ICMP type time-exceeded)

When NAT is applied, the IP address and port within the ICMP error packet also must be changed.

Support of stateful firewall and NAT services requires you to configure the Traceroute ALG for UDP destination port 33434 to 33450. In addition, you can configure the TTL threshold to prevent UDP flood attacks with large TTL values.

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.

Support of stateful firewall services requires that you configure the Exec ALG on TCP port 512, the Login ALG on TCP port 513, and the Shell ALG on TCP port 514. 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.

WinFrame

WinFrame application server software provides access to virtually any Windows application, across any type of network connection to any type of client.

This protocol is mainly used by Citrix Windows applications.

Stateful firewall and NAT require the ALG Winframe to be configured on TCP destination port 1494 and UDP port 1604.

Juniper Networks Defaults

The Junos OS provides a default, hidden configuration group called junos-defaults that is automatically applied to the configuration of your router. The junos-defaults group contains preconfigured statements that contain predefined values for common applications. Some of the statements must be referenced to take effect, such as applications like FTP or Telnet. Other statements are applied automatically, such as terminal settings. All of the preconfigured statements begin with the reserved name junos-.

Note

You can override the Junos OS default configuration values, but you cannot delete or edit them. If you delete a configuration, the defaults return when a new configuration is added.

You cannot use the apply-groups statement with the Junos OS defaults group.

To view the full set of available preset statements from the Junos OS default group, issue the show groups junos-defaults configuration mode command. The following example displays the list of Junos OS default groups that use application protocols (ALGs):

To reference statements available from the junos-defaults group, include the selected junos-default-name statement at the applicable hierarchy level. To configure application protocols, see Configuring Application Properties; for details about a specific protocol, see ALG Descriptions.

Examples: Referencing the Preset Statement from the Junos OS Default Group

The following example is a preset statement from the Junos OS default groups that is available for FTP in a stateful firewall:

To reference a preset Junos OS default statement from the Junos OS default groups, include the junos-default-name statement at the applicable hierarchy level. For example, to reference the Junos OS default statement for FTP in a stateful firewall, include the junos-ftp statement at the [edit services stateful-firewall rule rule-name term term-name from applications] hierarchy level.

The following example shows configuration of the default Junos IP ALG:

If you configure the IP ALG in the stateful firewall rule, it is matched by any IP traffic, but when any other more specific application matches the same traffic, the IP ALG is not matched. For example, in the following configuration, both the ICMP ALG and the IP ALG are configured, but traffic is matched for ICMP packets, because it is the more specific match.

ICMP, Ping, and Traceroute ALGs for MS-MICs and MS-MPCs

Starting with Junos OS Release 14.2, Junos OS extension-provider packages that are preinstalled and preconfigured on the MS-MIC and MS-MPC offer support for ping, traceroute, and ICMP ALGs in a consistent manner that is identical to the support that the uKernel service provides. Parity and uniformity of support is established for these ALGs between MS-MICs/MS-MPCs and the uKernel service. Until Junos OS Release 14.1, ICMP ALGs, ping ALGs, and traceroute ALGs were not entirely supported on MX Series routers with MS-MICs and MS-MPCs in comparison with the uKernel service that enables Network Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC. Support was available for handling of ICMP error response packets that match any existing flow in the opposite direction and NAT processing of ICMP packets with NAT processing of ping packets.

On MX Series routers with MS-MICs and MS-MPCs, tracking of ping traffic states wholly using the ICMP sequence numbers (for example, forwarding an echo reply only if the echo request with the corresponding sequence number is identified) is supported. ICMP application layer gateway (ALG) is enhanced to provide detailed logging information. Also, the traceroute ALGs enable UDP probe packets to be processed with the UDP destination port number greater than 33000 and the IP time-to-live (TTL) is less than 30 seconds. Traceroute ALGs enable ICMP response packets for which the ICMP type is time-exceeded to be processed and support a traceroute TTL threshold value, which controls the acceptable level of network penetration for trace routing.

You can configure ICMP and ping messages with the application junos-icmp-all, application junos-icmp-ping, and application icmp-code statements at the [edit services stateful-firewall rule rule-name term term-name from] and the [edit services nat rule rule-name term term-name from] hierarchy levels to define the match condition for the stateful firewall and NAT rules. Until Junos OS Release 14.1, a restriction or a validation on the applications that you could define for ICMP messages was not present. MS-MICs and MS-MPCs function the same way as the uKernel service, which causes the ping traffic to be tracked statefully using the ICMP sequence numbers (an echo reply is forwarded only if echo request with the corresponding sequence number matches). Also, MS-MICs and MS-MPCs impose a limit on the outstanding ping requests and drop the subsequent ping requests when the limit is reached.

Similarly, for traceroute messages, you can configure the application junos-traceroute and application junos-traceroute-ttl-1 statements at the [edit services stateful-firewall rule rule-name term term-name from] and the [edit services nat rule rule-name term term-name from] hierarchy levels to define the match condition for traceroute messages for the stateful firewall and NAT rules.

Traceroute and ICMP messages are supported for both IPv4 and IPv6 packets. For the traceroute functionality to work, you only need to ensure that the user-defined applications are working as expected with the inactivity timeout period and the TTL threshold values are configured to be the same period of time as configured by using the session-timeout seconds statement at the [edit services application-identification application application-name] hierarchy level. During the logging of ICMP messages, the ALG information for ping and ICMP utilities is displayed in the output of the relevant show commands, such as show sessions and show conversations, in the same manner as displayed for uKernel logging.

Release History Table
Release
Description
SIP supported for DS-Lite on MS-MPC and MS-MIC starting in Junos OS Release 18.2R1.
Support for ALGs with DS-lite on MS-MPC and MS-MIC starts in Junos OS Release 18.1R1
(Starting in Junos OS Release 17.2R1)
(Starting in Junos OS Release 17.2R1)
Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported.
Starting in Junos OS Release 17.2R1, NAT-64 rules are also supported.
(Starting in Junos OS Release 17.1R1)
Starting in Junos OS Release 17.1R1, the gatekeeper registration, administration, and status (RAS) ALG allows full support of gatekeeper mode for H.323 calls.
IKE ALG (Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1)
Starting in Junos OS Release 14.2R7, 15.1R5, 16.1R2, and 17.1R1, the IKE ALG enables the passing of IKEv1 and IPsec packets through NAPT-44 and NAT64 rules between IPsec peers that are not NAT-T compliant.