Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

ALG Overview

 

An Application Layer Gateway (ALG) enables the gateway to parse application layer payloads and take decisions whether to allow or deny traffic to the application server. ALGs supports the applications such as Transfer Protocol (FTP) and various IP protocols that use the application layer payload to communicate the dynamic Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports on which the applications open data connections.

ALG Overview

An Application Layer Gateway (ALG) is a software component that is designed to manage specific protocols such as Session Initiation Protocol (SIP) or FTP on Juniper Networks devices running Junos OS. The ALG module is responsible for Application-Layer aware packet processing.

ALG functionality can be triggered either by a service or application configured in the security policy:

  • A service is an object that identifies an application protocol using Layer 4 information (such as standard and accepted TCP and UDP port numbers) for an application service (such as Telnet, FTP, SMTP, and HTTP).

  • An application specifies the Layer 7 application that maps to a Layer 4 service.

A predefined service already has a mapping to a Layer 7 application. However, for custom services, you must link the service to an application explicitly, especially if you want the policy to apply an ALG.

ALGs for packets destined to well-known ports are triggered by service type. The ALG intercepts and analyzes the specified traffic, allocates resources, and defines dynamic policies to permit the traffic to pass securely through the device:

  1. When a packet arrives at the device, the flow module forwards the packet according to the security rule set in the policy.

  2. If a policy is found to permit the packet, the associated service type or application type is assigned and a session is created for this type of traffic.

  3. If a session is found for the packet, no policy rule match is needed. The ALG module is triggered if that particular service or application type requires the supported ALG processing.

The ALG also inspects the packet for embedded IP address and port information in the packet payload, and performs Network Address Translation (NAT) processing if necessary. A message buffer is allocated only when the packet is ready to process. The buffer is freed after the packet completes ALG handling, including modifying the payload, performing NAT, opening a pinhole for a new connection between a client and a server, and transferring data between a client and a server located on opposite sides of a Juniper Networks device

The maximum size of the jbuf is 9 Kb. If the message buffer size is more than 9 Kb, the entire message cannot be transferred to the ALG packet handler. This causes subsequent packets in the session to bypass ALG handling, resulting in a transaction failure. The ALG message buffer optimization is enhanced to reduce high memory consumption.

The ALG also opens a gate for the IP address and port number to permit data exchange for the control and data sessions. The control session and data session can be coupled to have the same timeout value, or they can be independent.

ALGs are supported on chassis clusters.

Understanding Custom ALG Services

By default, ALGs are bound to predefined services. For example, the FTP ALG is bound to junos-ftp, the RTSP ALG is bound to junos-rtsp, and so on.

A predefined service already has a mapping to a Layer 7 application. However, for custom services, you must link the service to an application explicitly, especially if you want the policy to apply an ALG.

When you apply predefined services to your policy, traffic matching the service will be sent to its corresponding ALG for further processing. However, under some circumstances, you might need to define custom services to achieve the following:

  • Utilize the ALG handler to process special traffic, with customer-specified protocols, destination ports and so on.

  • Permit traffic but bypass ALG processing, when traffic matches predefined services that bind with ALG.

  • Add more applications to the current ALG’s application set.

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

The three usages of custom services are illustrated below, considering MS-RPC ALG as an example:

  • Utilize the ALG handler to process special traffic:

    Traffic with TCP destination port 6000 will be sent to MS-RPC ALG for further processing.

  • Permit traffic but bypass ALG processing:

    All ALGs will be ignored by traffic with TCP destination port 135.

  • Add more applications to an ALG’s application set—To add applications such as MS-RPC or Sun RPC services, which are not predefined on the devices:

    MS-RPC data traffic with TCP, uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2, will be permitted, when custom-msrpc is applied to the policy along with other predefined junos-ms-rpc** applications.

Understanding the IPv6 DNS ALG for Routing, NAT, and NAT-PT

Domain Name System (DNS) is the part of the ALG that handles DNS traffic, monitors DNS query and reply packets, and closes the session if the DNS flag indicates the packet is a reply message.

The DNS ALG supports IPv4 in route mode for Junos OS Release 10.0 and earlier releases. In Junos OS Release 10.4, this feature implements IPv6 support on the DNS ALG for routing, Network Address Translation (NAT), and Network Address Translation-Protocol Translation (NAT-PT).

When the DNS ALG receives a DNS query from the DNS client, a security check is done on the DNS packet. When the DNS ALG receives a DNS reply from the DNS server, a similar security check is done, and then the session for the DNS traffic closes.

IPv6 DNS ALG Traffic in NAT mode

IPv6 NAT provides address translation between IPv4 and IPv6 addressed network devices. It also provides address translation between IPv6 hosts. NAT between IPv6 hosts is done in a similar manner and for similar purposes as IPv4 NAT.

When the DNS traffic works in NAT mode, the DNS ALG translates the public address in a DNS reply to a private address when the DNS client is on private network, and similarly translates a private address to a public address when the DNS client is on a public network.

In Junos OS Release 10.4 IPv6 NAT supports:

  • Source NAT translations

  • Destination NAT mappings

  • Static NAT mappings

Note

The IPv6 DNS ALG NAT supports only static NAT mapping.

IPv6 DNS ALG Traffic in NAT-PT mode

IPv6 NAT-PT provides address allocation and protocol translation between IPv4 and IPv6 addressed network devices. The translation process is based on the Stateless IP/ICMP Translation (SIIT) method; however, the state and the context of each communication is retained during the session lifetime. IPv6 NAT-PT supports Internet Control Message Protocol (ICMP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP) packets.

IPv6 NAT-PT supports the following types of NAT-PT:

  • Traditional NAT-PT

  • Bidirectional NAT-PT

A DNS-based mechanism dynamically maps IPv6 addresses to IPv4-only servers. NAT-PT uses the DNS ALG to transparently do the translations.

For example, a company using an internal IPv6 network needs to be able to communicate with external IPv4 servers that do not have IPv6 addresses.

To support the dynamic address binding, a DNS should be used for name resolution. The IPv4 host looks up the name of the IPv6 node in its local configured IPv4 DNS server, which then passes the query to the IPv6 DNS server through the device using NAT-PT.

When DNS traffic works in NAT-PT mode, the DNS ALG translates the IP address in a DNS reply packet between the IPv4 address and the IPv6 address when the DNS client is in an IPv6 network and the server is in an IPv4 network, and vice versa.

Note

In NAT-PT mode, only IPV4 to IPV6 addresses translation is supported in the DNS ALG. To support NAT-PT mode in a DNS ALG, the NAT module should support NAT-PT.

When the DNS ALG receives a DNS query from the DNS client, the DNS ALG performs the following security and sanity checks on the DNS packets:

  • Enforces the maximum DNS message length (the default is 512 bytes and the maximum length is 8KB)

  • Enforces a domain-name length of 255 bytes and a label length of 63 bytes

  • Verifies the integrity of the domain-name referred to by the pointer if compression pointers are encountered in the DNS message

  • Checks to see if a compression pointer loop exists

Similar sanity checks are done when the DNS ALG receives a DNS reply from the DNS Server, after which the session for this DNS traffic gets closed.

Understanding IPv6 Support in FTP ALG

File Transfer Protocol (FTP) is the part of the ALG that handles FTP traffic. The PORT/PASV requests and corresponding 200/227 responses in FTP are used to announce the TCP port, which the host listens to for the FTP data connection.

EPRT/EPSV/229 commands are used for these requests and responses. FTP ALG supports EPRT/EPSV/229 already, but only for IPv4 addresses.

In Junos OS Release 10.4, EPRT/EPSV/229 commands have been updated to support both IPv4 and IPv6 addresses.

FTP ALG uses preallocated objcache to store its session cookies. When both IPv4 and IPv6 addresses are supported on FTP ALG, the session cookie structure will enlarge by 256 bits (32 bytes) to store IPv6 address.

FTP ALG Support for IPv6

The FTP ALG monitors commands and responses on the FTP control channel for syntactical correctness and opens corresponding pinholes to permit data channel connections to be established. In Junos OS Release 10.4, the FTP ALG supported IPv4 routing, IPv6 routing, and NAT mode only. In Junos OS Release 11.2 and later releases, the FTP ALG also supports IPv6 NAT and NAT-PT modes.

EPRT mode

The EPRT command allows for the specification of an extended address for the data connection. The extended address must consist of the network protocol as well as the network and transport addresses.

The format of EPRT is:

EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>

  • <net-prt>: An address family number defined by IANA

  • <net-addr>: A protocol specific string of the network address

  • <tcp-port>: A TCP port number

The following are sample EPRT commands for IPv6:

EPRT |2|1080::8:800:200C:417A|5282|

In this mode, FTP ALG focuses only on the EPRT command; it extracts the IPv6 address and port from the EPRT command and opens the pinhole.

EPSV mode

The EPSV command requests that a server be listening on a data port and waiting for a connection. The response to this command includes only the TCP port number of the listening connection.

An example response string is follows:

Note

The response code for entering passive mode using an extended address must be 229. You should extract the TCP port in 229 payloads and use it to open the pinhole.

Understanding TAP Mode Support for ALG

The Terminal Access Point (TAP) mode is a standby device, which checks the mirrored traffic through switch. The TAP mode does not depend on ALG enabled or disabled status. The ALG configuration remains the same as non-TAP mode.

When you configure an SRX Series device to operate in TAP mode, the device generates security log information to display the information on threats detected, application usage, and user details. When the device is configured to operate in TAP mode, the device receives packets only from the configured TAP interface. Except the configured TAP interface, other interfaces are configured to normal interface that is used as management interface or connected to the outside server. The SRX Series device will generate security report or log according to the incoming traffic.

ALG supports the application such as payload NAT, and dynamically permit its data traffic.

Note

You can configure only one TAP interface when you operate the device in TAP mode.

Enabling and Disabling ALG in TAP Mode

This topic shows how to enable or disable the ALG status in TAP mode.

Before you begin:

  • Read the Understanding TAP Mode Support for ALG to understand about ALG support for TAP mode.

    • The default ALG status for SRX300, SRX320, SRX340, SRX345, SRX380, and SRX550M devices is as follows:

    • The default ALG status for SRX4100 device is as follows:

  • To enable the ALG that is disabled by default, use the following command.

    To change back the enabled ALG to the default status, use the following command.

  • To disable ALG that is enabled by default, use the following command.

    To change back the disabled ALG to the default status, use the following command.

  • To enable the IKE ALG, use the following command.

    To change back the enabled IKE ALG to the default status, use the following command.