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 on switches.

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, and SMTP).

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

Application Support Layer (ASL) is used by System Log Messages. Refer to System Log Messages for more information.

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.

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.

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 DNS ALG Traffic in NAT-PT mode

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
• EPRT mode
• EPSV mode

When you configure an SRX Series Firewall 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 Firewall 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.