ALG Applications
Configuring Application Properties
To configure application properties, include the application statement at the [edit applications] hierarchy level:
You can group application objects by configuring the application-set statement; for more information, see Configuring Application Sets.
This section includes the following tasks for configuring applications:
Configuring an Application Protocol
The application-protocol statement allows you to specify which of the supported application protocols (ALGs) to configure and include in an application set for service processing. To configure application protocols, include the application-protocol statement at the [edit applications application application-name] hierarchy level:
Table 1 shows the list of supported protocols. For more information about specific protocols, see ALG Descriptions.
Table 1: Application Protocols Supported by Services Interfaces
Protocol Name | CLI Value | Comments |
|---|---|---|
Bootstrap protocol (BOOTP) | bootp | Supports BOOTP and dynamic host configuration protocol (DHCP). |
Distributed Computing Environment (DCE) remote procedure call (RPC) | dce-rpc | Requires the protocol statement to have the value udp or tcp. Requires a uuid value. You cannot specify destination-port or source-port values. |
DCE RPC portmap | dce-rpc-portmap | Requires the protocol statement to have the value udp or tcp. Requires a destination-port value. |
Domain Name System (DNS) | dns | Requires the protocol statement to have the value udp. This application protocol closes the DNS flow as soon as the DNS response is received. |
Exec | exec | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port value. |
FTP | ftp | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port value. |
H.323 | h323 | – |
IKE ALG | ike-esp-nat | Requires the protocol statement to have the value udp and requires the destination-port value to be 500. |
Internet Control Message Protocol (ICMP) | icmp | Requires the protocol statement to have the value icmp or to be unspecified. |
Internet Inter-ORB Protocol | iiop | – |
IP | ip | – |
Login | login | – |
NetBIOS | netbios | Requires the protocol statement to have the value udp or to be unspecified. Requires a destination-port value. |
NetShow | netshow | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port value. |
Point-to-Point Tunneling Protocol | pptp | – |
RealAudio | realaudio | – |
Real-Time Streaming Protocol (RTSP) | rtsp | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port value. |
RPC User Datagram Protocol (UDP) or TCP | rpc | Requires the protocol statement to have the value udp or tcp. Requires a rpc-program-number value. You cannot specify destination-port or source-port values. |
RPC port mapping | rpc-portmap | Requires the protocol statement to have the value udp or tcp. Requires a destination-port value. |
Shell | shell | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port value. |
Session Initiation Protocol | sip | – |
SNMP | snmp | Requires the protocol statement to have the value udp or to be unspecified. Requires a destination-port value. |
SQLNet | sqlnet | Requires the protocol statement to have the value tcp or to be unspecified. Requires a destination-port or source-port value. |
Talk Program | talk | |
Trace route | traceroute | Requires the protocol statement to have the value udp or to be unspecified. Requires a destination-port value. |
Trivial FTP (TFTP) | tftp | Requires the protocol statement to have the value udp or to be unspecified. Requires a destination-port value. |
WinFrame | winframe | – |
You can configure application-level gateways (ALGs) for ICMP and trace route under stateful firewall, NAT, or CoS rules when twice NAT is configured in the same service set. These ALGs cannot be applied to flows created by the Packet Gateway Controller Protocol (PGCP). Twice NAT does not support any other ALGs. NAT applies only the IP address and TCP or UDP headers, but not the payload.
For more information about configuring twice NAT, see Junos Address Aware Network Addressing Overview.
Configuring the Network Protocol
The protocol statement allows you to specify which of the supported network protocols to match in an application definition. To configure network protocols, include the protocol statement at the [edit applications application application-name] hierarchy level:
You specify the protocol type as a numeric value; for the more commonly used protocols, text names are also supported in the command-line interface (CLI). Table 2 shows the list of the supported protocols.
Table 2: Network Protocols Supported by Services Interfaces
Network Protocol Type | CLI Value | Comments |
|---|---|---|
IP Security (IPsec) authentication header (AH) | ah | – |
External Gateway Protocol (EGP) | egp | – |
IPsec Encapsulating Security Payload (ESP) | esp | – |
Generic routing encapsulation (GR) | gre | – |
ICMP | icmp | Requires an application-protocol value of icmp. |
ICMPv6 | icmp6 | Requires an application-protocol value of icmp. |
Internet Group Management Protocol (IGMP) | igmp | – |
IP in IP | ipip | – |
OSPF | ospf | – |
Protocol Independent Multicast (PIM) | pim | – |
Resource Reservation Protocol (RSVP) | rsvp | – |
TCP | tcp | Requires a destination-port or source-port value unless you specify application-protocol rcp or dce-rcp. |
UDP | udp | Requires a destination-port or source-port value unless you specify application-protocol rcp or dce-rcp. |
For a complete list of possible numeric values, see RFC 1700, Assigned Numbers (for the Internet Protocol Suite).
IP version 6 (IPv6) is not supported as a network protocol in application definitions.
By default, the twice NAT feature can affect IP, TCP, and UDP headers embedded in the payload of ICMP error messages. You can include the protocol tcp and protocol udp statements with the application statement for twice NAT configurations. For more information about configuring twice NAT, see Junos Address Aware Network Addressing Overview.
Configuring the ICMP Code and Type
The ICMP code and type provide additional specification, in conjunction with the network protocol, for packet matching in an application definition. To configure ICMP settings, include the icmp-code and icmp-type statements at the [edit applications application application-name] hierarchy level:
You can include only one ICMP code and type value. The application-protocol statement must have the value icmp. Table 3 shows the list of supported ICMP values.
Table 3: ICMP Codes and Types Supported by Services Interfaces
CLI Statement | Description |
|---|---|
icmp-code | This value or keyword provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type value, you must specify icmp-type along with icmp-code. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The keywords are grouped by the ICMP type with which they are associated: parameter-problem: ip-header-bad (0), required-option-missing (1) redirect: redirect-for-host (1), redirect-for-network (0), redirect-for-tos-and-host (3), redirect-for-tos-and-net (2) time-exceeded: ttl-eq-zero-during-reassembly (1), ttl-eq-zero-during-transit (0) unreachable: communication-prohibited-by-filtering (13), destination-host-prohibited (10), destination-host-unknown (7), destination-network-prohibited (9), destination-network-unknown (6), fragmentation-needed (4), host-precedence-violation (14), host-unreachable (1), host-unreachable-for-TOS (12), network-unreachable (0), network-unreachable-for-TOS (11), port-unreachable (3), precedence-cutoff-in-effect (15), protocol-unreachable (2), source-host-isolated (8), source-route-failed (5) |
icmp-type | Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. For more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): echo-reply (0), echo-request (8), info-reply (16), info-request (15), mask-request (17), mask-reply (18), parameter-problem (12), redirect (5), router-advertisement (9), router-solicit (10), source-quench (4), time-exceeded (11), timestamp (13), timestamp-reply (14), or unreachable (3). |
If you configure an interface with an input firewall filter that includes a reject action and with a service set that includes stateful firewall rules, the router executes the input firewall filter before the stateful firewall rules are run on the packet. As a result, when the Packet Forwarding Engine sends an ICMP error message out through the interface, the stateful firewall rules might drop the packet because it was not seen in the input direction.
Possible workarounds are to include a forwarding-table filter to perform the reject action, because this type of filter is executed after the stateful firewall in the input direction, or to include an output service filter to prevent the locally generated ICMP packets from going to the stateful firewall service.
Configuring Source and Destination Ports
The TCP or UDP source and destination port provide additional specification, in conjunction with the network protocol, for packet matching in an application definition. To configure ports, include the destination-port and source-port statements at the [edit applications application application-name] hierarchy level:
You must define one source or destination port. Normally, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port; for constraints, see Table 1.
You can specify either a numeric value or one of the text synonyms listed in Table 4.
Table 4: Port Names Supported by Services Interfaces
Port Name | Corresponding Port Number |
|---|---|
afs | 1483 |
bgp | 179 |
biff | 512 |
bootpc | 68 |
bootps | 67 |
cmd | 514 |
cvspserver | 2401 |
dhcp | 67 |
domain | 53 |
eklogin | 2105 |
ekshell | 2106 |
exec | 512 |
finger | 79 |
ftp | 21 |
ftp-data | 20 |
http | 80 |
https | 443 |
ident | 113 |
imap | 143 |
kerberos-sec | 88 |
klogin | 543 |
kpasswd | 761 |
krb-prop | 754 |
krbupdate | 760 |
kshell | 544 |
ldap | 389 |
login | 513 |
mobileip-agent | 434 |
mobilip-mn | 435 |
msdp | 639 |
netbios-dgm | 138 |
netbios-ns | 137 |
netbios-ssn | 139 |
nfsd | 2049 |
nntp | 119 |
ntalk | 518 |
ntp | 123 |
pop3 | 110 |
pptp | 1723 |
printer | 515 |
radacct | 1813 |
radius | 1812 |
rip | 520 |
rkinit | 2108 |
smtp | 25 |
snmp | 161 |
snmptrap | 162 |
snpp | 444 |
socks | 1080 |
ssh | 22 |
sunrpc | 111 |
syslog | 514 |
tacacs-ds | 65 |
talk | 517 |
telnet | 23 |
tftp | 69 |
timed | 525 |
who | 513 |
xdmcp | 177 |
zephyr-clt | 2103 |
zephyr-hm | 2104 |
For more information about matching criteria, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.
Configuring the Inactivity Timeout Period
You can specify a timeout period for application inactivity. If the software has not detected any activity during the duration, the flow becomes invalid when the timer expires. To configure a timeout period, include the inactivity-timeout statement at the [edit applications application application-name] hierarchy level:
The default value is 14,400 seconds. The value you configure for an application overrides any global value configured at the [edit interfaces interface-name service-options] hierarchy level; for more information, see Configuring Default Timeout Settings for Services Interfaces.
Configuring an IKE ALG Application
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. The IKE ALG enables the passing of IKEv1 and IPsec packets through NAPT-44 and NAT64 filters between IPsec peers that are not NAT-T compliant. This ALG supports only ESP tunnel mode. You can use the predefined IKE ALG application junos-ike, which has predefined values for the destination port (500), inactivity timeout (14,400 seconds), gate timeout (120 seconds), and ESP session idle timeout (800 seconds). If you want to use the IKE ALG with values different from the predefined junos-ike application, you need to configure a new IKE ALG application.
To configure an IKE ALG application:
- Specify a name for the application.[edit applications]user@host# set application junos-ike
- Specify the IKE ALG.[edit applications application junos-ike]user@host# set application-protocol ike-esp-nat
- Specify the UDP protocol.[edit applications application junos-ike]user@host# set protocol udp
- Specify 500 for the destination port.[edit applications application junos-ike]user@host# set destination-port 500
- Specify the number of seconds that the IKE session is
inactive before it is deleted. The default is 14,400 seconds.[edit applications application junos-ike]user@host# set inactivity-timeout seconds
- Specify the number of seconds that can pass after IKE
establishes the security association between the IPsec client and
server and before the ESP traffic starts in both directions. If the
ESP traffic has not started before this timeout value, the ESP gates
are deleted and the ESP traffic is blocked. The default is 120 seconds.[edit applications application junos-ike]user@host# set gate-timeout seconds
- Specify the ESP session (IPsec data traffic) idle timeout
in seconds. If no IPsec data traffic is passed on the ESP session
in this time, the session is deleted. The default is 800 seconds.[edit applications application junos-ike]user@host# set child-inactivity-timeout seconds
Configuring SIP
The Session Initiation Protocol (SIP) is a generalized protocol for communication between endpoints involved in Internet services such as telephony, fax, video conferencing, instant messaging, and file exchange.
The Junos OS provides ALG services in accordance with the standard described in RFC 3261, SIP: Session Initiation Protocol. SIP flows under the Junos OS are as described in RFC 3665, Session Initiation Protocol (SIP) Basic Call Flow Examples.
Before implementing the Junos OS SIP ALG, you should be familiar with certain limitations, discussed in Junos OS SIP ALG Limitations
The use of NAT in conjunction with the SIP ALG results in changes in SIP header fields due to address translation. For an explanation of these translations, refer to SIP ALG Interaction with Network Address Translation.
To implement SIP on adaptive services interfaces, you configure the application-protocol statement at the [edit applications application application-name] hierarchy level with the value sip. For more information about this statement, see Configuring an Application Protocol. In addition, there are two other statements you can configure to modify how SIP is implemented:
You can enable the router to accept any incoming SIP calls for the endpoint devices that are behind the NAT firewall. When a device behind the firewall registers with the proxy that is outside the firewall, the AS or Multiservices PIC maintains the registration state. When the learn-sip-register statement is enabled, the router can use this information to accept inbound calls. If this statement is not configured, no inbound calls are accepted; only the devices behind the firewall can call devices outside the firewall.
To configure SIP registration, include the learn-sip-register statement at the [edit applications application application-name] hierarchy level:
[edit applications application application-name]learn-sip-register;Note The learn-sip-register statement is not applicable to the Next Gen Services MX-SPC3.
You can also manually inspect the SIP register by issuing the show services stateful-firewall sip-register command; for more information, see the Junos OS System Basics and Services Command Reference. The show services stateful-firewall sip-register command is not supported for Next Gen Services.
You can specify a timeout period for the duration of SIP calls that are placed on hold. When a call is put on hold, there is no activity and flows might time out after the configured inactivity-timeout period expires, resulting in call state teardown. To avoid this, when a call is put on hold, the flow timer is reset to the sip-call-hold-timeout cycle to preserve the call state and flows for longer than the inactivity-timeout period.
Note The sip-call-hold-timeout statement is not applicable to the Next Gen Services MX-SPC3.
To configure a timeout period, include the sip-call-hold-timeout statement at the [edit applications application application-name] hierarchy level:
[edit applications application application-name]sip-call-hold-timeout seconds;The default value is 7200 seconds and the range is from 0 through 36,000 seconds (10 hours).
SIP ALG Interaction with Network Address Translation
The Network Address Translation (NAT) protocol enables multiple hosts in a private subnet to share a single public IP address to access the Internet. For outgoing traffic, NAT replaces the private IP address of the host in the private subnet with the public IP address. For incoming traffic, the public IP address is converted back into the private address, and the message is routed to the appropriate host in the private subnet.
Using NAT with the Session Initiation Protocol (SIP) service is more complicated because SIP messages contain IP addresses in the SIP headers as well as in the SIP body. When using NAT with the SIP service, the SIP headers contain information about the caller and the receiver, and the device translates this information to hide it from the outside network. The SIP body contains the Session Description Protocol (SDP) information, which includes IP addresses and port numbers for transmission of the media. The device translates SDP information for allocating resources to send and receive the media.
How IP addresses and port numbers in SIP messages are replaced depends on the direction of the message. For an outgoing message, the private IP address and port number of the client are replaced with the public IP address and port number of the Juniper Networks firewall. For an incoming message, the public address of the firewall is replaced with the private address of the client.
When an INVITE message is sent out across the firewall, the SIP Application Layer Gateway (ALG) collects information from the message header into a call table, which it uses to forward subsequent messages to the correct endpoint. When a new message arrives, for example an ACK or 200 OK, the ALG compares the “From:, To:, and Call-ID:” fields against the call table to identify the call context of the message. If a new INVITE message arrives that matches the existing call, the ALG processes it as a REINVITE.
When a message containing SDP information arrives, the ALG allocates ports and creates a NAT mapping between them and the ports in the SDP. Because the SDP requires sequential ports for the Real-Time Transport Protocol (RTP) and Real-Time Control Protocol (RTCP) channels, the ALG provides consecutive even-odd ports. If it is unable to find a pair of ports, it discards the SIP message.
This topic contains the following sections:
Outgoing Calls
When a SIP call is initiated with a SIP request message from the internal to the external network, NAT replaces the IP addresses and port numbers in the SDP and binds the IP addresses and port numbers to the Juniper Networks firewall. Via, Contact, Route, and Record-Route SIP header fields, if present, are also bound to the firewall IP address. The ALG stores these mappings for use in retransmissions and for SIP response messages.
The SIP ALG then opens pinholes in the firewall to allow media through the device on the dynamically assigned ports negotiated based on information in the SDP and the Via, Contact, and Record-Route header fields. The pinholes also allow incoming packets to reach the Contact, Via, and Record-Route IP addresses and ports. When processing return traffic, the ALG inserts the original Contact, Via, Route, and Record-Route SIP fields back into packets.
Incoming Calls
Incoming calls are initiated from the public network to public static NAT addresses or to interface IP addresses on the device. Static NATs are statically configured IP addresses that point to internal hosts; interface IP addresses are dynamically recorded by the ALG as it monitors REGISTER messages sent by internal hosts to the SIP registrar. When the device receives an incoming SIP packet, it sets up a session and forwards the payload of the packet to the SIP ALG.
The ALG examines the SIP request message (initially an INVITE) and, based on information in the SDP, opens gates for outgoing media. When a 200 OK response message arrives, the SIP ALG performs NAT on the IP addresses and ports and opens pinholes in the outbound direction. (The opened gates have a short time-to-live, and they time out if a 200 OK response message is not received quickly.)
When a 200 OK response arrives, the SIP proxy examines the SDP information and reads the IP addresses and port numbers for each media session. The SIP ALG on the device performs NAT on the addresses and port numbers, opens pinholes for outbound traffic, and refreshes the timeout for gates in the inbound direction.
When the ACK arrives for the 200 OK, it also passes through the SIP ALG. If the message contains SDP information, the SIP ALG ensures that the IP addresses and port numbers are not changed from the previous INVITE—if they are, the ALG deletes old pinholes and creates new pinholes to allow media to pass through. The ALG also monitors the Via, Contact, and Record-Route SIP fields and opens new pinholes if it determines that these fields have changed.
Forwarded Calls
A forwarded call is when, for example, user A outside the network calls user B inside the network, and user B forwards the call to user C outside the network. The SIP ALG processes the INVITE from user A as a normal incoming call. But when the ALG examines the forwarded call from B to C outside the network and notices that B and C are reached using the same interface, it does not open pinholes in the firewall, because media will flow directly between user A and user C.
Call Termination
The BYE message terminates a call. When the device receives a BYE message, it translates the header fields just as it does for any other message. But because a BYE message must be acknowledged by the receiver with a 200 OK, the ALG delays call teardown for five seconds to allow time for transmission of the 200 OK.
Call Re-INVITE Messages
Re-INVITE messages add new media sessions to a call and remove existing media sessions. When new media sessions are added to a call, new pinholes are opened in the firewall and new address bindings are created. The process is identical to the original call setup. When one or more media sessions are removed from a call, pinholes are closed and bindings released just as with a BYE message.
Call Session Timers
The SIP ALG uses the Session-Expires value to time out a session if a Re-INVITE or UPDATE message is not received. The ALG gets the Session-Expires value, if present, from the 200 OK response to the INVITE and uses this value for signaling timeout. If the ALG receives another INVITE before the session times out, it resets all timeout values to this new INVITE or to default values, and the process is repeated.
As a precautionary measure, the SIP ALG uses hard timeout values to set the maximum amount of time a call can exist. This ensures that the device is protected should one of the following events occur:
End systems crash during a call and a BYE message is not received.
Malicious users never send a BYE in an attempt to attack a SIP ALG.
Poor implementations of SIP proxy fail to process Record-Route and never send a BYE message.
Network failures prevent a BYE message from being received.
Call Cancellation
Either party can cancel a call by sending a CANCEL message. Upon receiving a CANCEL message, the SIP ALG closes pinholes through the firewall—if any have been opened—and releases address bindings. Before releasing the resources, the ALG delays the control channel age-out for approximately five seconds to allow time for the final 200 OK to pass through. The call is terminated when the five second timeout expires, regardless of whether a 487 or non-200 response arrives.
Forking
Forking enables a SIP proxy to send a single INVITE message to multiple destinations simultaneously. When the multiple 200 OK response messages arrive for the single call, the SIP ALG parses but updates call information with the first 200 OK messages it receives.
SIP Messages
The SIP message format consists of a SIP header section and the SIP body. In request messages, the first line of the header section is the request line, which includes the method type, request-URI, and protocol version. In response messages, the first line is the status line, which contains a status code. SIP headers contain IP addresses and port numbers used for signaling. The SIP body, separated from the header section by a blank line, is reserved for session description information, which is optional. Junos OS currently supports the SDP only. The SIP body contains IP addresses and port numbers used to transport the media.
SIP Headers
In the following sample SIP request message, NAT replaces the IP addresses in the header fields to hide them from the outside network.
How IP address translation is performed depends on the type and direction of the message. A message can be any of the following:
Inbound request
Outbound response
Outbound request
Inbound response
Table 5 shows how NAT is performed in each of these cases. Note that for several of the header fields the ALG determine more than just whether the messages comes from inside or outside the network. It must also determine what client initiated the call, and whether the message is a request or response.
Table 5: Requesting Messages with NAT Table
Inbound Request (from public to private) | To: | Replace domain with local address |
From: | None | |
Call-ID: | None | |
Via: | None | |
Request-URI: | Replace ALG address with local address | |
Contact: | None | |
Record-Route: | None | |
Route: | None | |
Outbound Response (from private to public) | To: | Replace ALG address with local address |
From: | None | |
Call-ID: | None | |
Via: | None | |
Request-URI: | N/A | |
Contact: | Replace local address with ALG address | |
Record-Route: | Replace local address with ALG address | |
Route: | None | |
Outbound Request (from private to public) | To: | None |
From: | Replace local address with ALG address | |
Call-ID: | None | |
Via: | Replace local address with ALG address | |
Request-URI: | None | |
Contact: | Replace local address with ALG address | |
Record-Route: | Replace local address with ALG address | |
Route: | Replace ALG address with local address | |
Outbound Response (from public to private) | To: | None |
From: | Replace ALG address with local address | |
Call-ID: | None | |
Via: | Replace ALG address with local address | |
Request-URI: | N/A | |
Contact: | None | |
Record-Route: | Replace ALG address with local address | |
Route: | Replace ALG address with local address |
SIP Body
The SDP information in the SIP body includes IP addresses the ALG uses to create channels for the media stream. Translation of the SDP section also allocates resources, that is, port numbers to send and receive the media.
The following excerpt from a sample SDP section shows the fields that are translated for resource allocation.
SIP messages can contain more than one media stream. The concept is similar to attaching multiple files to an e-mail message. For example, an INVITE message sent from a SIP client to a SIP server might have the following fields:
Junos OS supports up to 6 SDP channels negotiated for each direction, for a total of 12 channels per call.
Junos OS SIP ALG Limitations
The following limitations apply to configuration of the SIP ALG:
Only the methods described in RFC 3261 are supported.
Only SIP version 2 is supported.
TCP is not supported as a transport mechanism for signaling messages for MS-MPCs but is supported for Next Gen Services.
Do not configure the SIP ALG when using STUN. if clients use STUN/TURN to detect the firewall or NAT devices between the caller and responder or proxy, the client attempts to best-guess the NAT device behavior and act accordingly to place the call.
On MS-MPCs, do not use the endpoint-independent mapping NAT pool option in conjunction with the SIP ALG. Errors will result. This does not apply to Next Gen Services.
IPv6 signaling data is not supported for MS-MPCs but is supported for Next Gen Services.
Authentication is not supported.
Encrypted messages are not supported.
SIP fragmentation is not supported for MS-MPCs but is supported for Next Gen Services.
The maximum UDP packet size containing a SIP message is assumed to be 9 KB. SIP messages larger than this are not supported.
The maximum number of media channels in a SIP message is assumed to be six.
Fully qualified domain names (FQDNs) are not supported in critical fields.
QoS is not supported. SIP supports DSCP rewrites.
High availability is not supported, except for warm standby.
A timeout setting of never is not supported on SIP or NAT.
Multicast (forking proxy) is not supported.
Configuring an SNMP Command for Packet Matching
You can specify an SNMP command setting for packet matching. To configure SNMP, include the snmp-command statement at the [edit applications application application-name] hierarchy level:
The supported values are get, get-next, set, and trap. You can configure only one value for matching. The application-protocol statement at the [edit applications application application-name] hierarchy level must have the value snmp. For information about specifying the application protocol, see Configuring an Application Protocol.
Configuring an RPC Program Number
You can specify an RPC program number for packet matching. To configure an RPC program number, include the rpc-program-number statement at the [edit applications application application-name] hierarchy level:
The range of values used for DCE or RPC is from 100,000 through 400,000. The application-protocol statement at the [edit applications application application-name] hierarchy level must have the value rpc. For information about specifying the application protocol, see Configuring an Application Protocol.
Configuring the TTL Threshold
You can specify a trace route time-to-live (TTL) threshold value, which controls the acceptable level of network penetration for trace routing. To configure a TTL value, include the ttl-threshold statement at the [edit applications application application-name] hierarchy level:
The application-protocol statement at the [edit applications application application-name] hierarchy level must have the value traceroute. For information about specifying the application protocol, see Configuring an Application Protocol.
Configuring a Universal Unique Identifier
You can specify a Universal Unique Identifier (UUID) for DCE RPC objects. To configure a UUID value, include the uuid statement at the [edit applications application application-name] hierarchy level:
The uuid value is in hexadecimal notation. The application-protocol statement at the [edit applications application application-name hierarchy level must have the value dce-rpc. For information about specifying the application protocol, see Configuring an Application Protocol. For more information on UUID numbers, see http://www.opengroup.org/onlinepubs/9629399/apdxa.htm.
Configuring Application Sets
You can group the applications you have defined into a named object by including the application-set statement at the [edit applications] hierarchy level with an application statement for each application:
For an example of a typical application set, see Examples: Configuring Application Protocols.
Examples: Configuring Application Protocols
The following example shows an application protocol definition describing a special FTP application running on port 78:
The following example shows a special ICMP protocol (application-protocol icmp) of type 8 (ICMP echo):
The following example shows a possible application set:
The software includes a predefined set of well-known application protocols. The set includes applications for which the TCP and UDP destination ports are already recognized by stateless firewall filters.
Verifying the Output of ALG Sessions
This section contains examples of successful output from ALG sessions and information on system log configuration. You can compare the results of your sessions to check whether the configurations are functioning correctly.
FTP Example
This example analyzes the output during an active FTP session. It consists of four different flows; two are control flows and two are data flows. The example consists of the following parts:
Sample Output
MS-MPC Card
For MS-MPCs, the following is a complete sample output from the show services stateful-firewall conversations application-protocol ftp operational mode command:
user@host>show services stateful-firewall conversations
application-protocol ftpInterface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow State Dir Frm count
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13
NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12
NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
For each flow, the first line shows flow information, including protocol (TCP), source address, source port, destination address, destination port, flow state, direction, and frame count.
The state of a flow can be Watch, Forward, or Drop:
A Watch flow state indicates that the control flow is monitored by the ALG for information in the payload. NAT processing is performed on the header and payload as needed.
A Forward flow forwards the packets without monitoring the payload. NAT is performed on the header as needed.
A Drop flow drops any packet that matches the 5 tuple.
The frame count (Frm count) shows the number of packets that were processed on that flow.
The second line shows the NAT information.
source indicates source NAT.
dest indicates destination NAT.
The first address and port in the NAT line are the original address and port being translated for that flow.
The second address and port in the NAT line are the translated address and port for that flow.
MX-SPC3 Card
On the MX-SPC3 services card, the following is a complete sample output from the show services sessions application-protocol ftp operational mode command:
user@host>show services sessions application-protocol
ftpSession ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239, Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650, Total sessions: 2
For each session:
The first line shows flow information, including session ID, service-set name, policy name, session timeout, logical system name, and its state.
The second line, Resource information, indicates the session is created by ALG, including the ALG name (FTP ALG) and ASL group id, which is 1and the ASL resource id, which is 0 for control session and 1 for data session.
The third line In is forward flow and the fourth line Out is reverse flow, including the source address, source port, destination address, destination port, protocol (TCP), session conn-tag, incoming for Inand outgoing for Out interface, received frame count and bytes. NAT is performed on the header as needed.
FTP System Log Messages
System log messages are generated during an FTP session. For more information about system logs, see System Log Messages.
MS-MPC Card
The following system log messages are generated during creation of the FTP control flow:
Rule Accept system log:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1Create Accept Flow system log:
Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flowSystem log for data flow creation:
Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
MX-SPC3 CardCard
The following system log messages are generated during creation of the FTP control flow:
System log for FTP control session creation:
Mar 23 23:58:54 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 N/A(N/A) ge-1/0/2.0 UNKNOWN UNKNOWN UNKNOWN N/A N/A -1 N/A Mar 23 23:59:00 esst480r junos-alg: RT_ALG_FTP_ACTIVE_ACCEPT: application:ftp data, vms-3/0/0.0 30.1.1.2:20 -> 20.1.1.2:33947 (TCP)
System log for FTP data session creation:
Mar 23 23:59:00 esst480r RT_FLOW: RT_FLOW_SESSION_CREATE_USF: Tag svc-set-name ss1: session created 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 N/A(N/A) ge-1/1/6.0 FTP-DATA UNKNOWN UNKNOWN Infrastructure File-Servers 2 N/A
System log for FTP data session destroy:
Mar 23 23:59:02 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed TCP FIN: 30.1.1.2/20->20.1.1.2/33947 0x0 junos-ftp-data 30.1.1.2/20->20.1.1.2/33947 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneOut ss1-ZoneIn 818413577 2954(4423509) 281(14620) 2 FTP-DATA UNKNOWN N/A(N/A) ge-1/1/6.0 No Infrastructure File-Servers 2 N/A
System log for FTP control session destroy:
Mar 23 23:59:39 esst480r RT_FLOW: RT_FLOW_SESSION_CLOSE_USF: Tag svc-set-name ss1: session closed Closed by junos-tcp-clt-emul: 20.1.1.2/52877->30.1.1.2/21 0x0 junos-ftp 20.1.1.2/52877->30.1.1.2/21 0x0 N/A N/A N/A N/A 6 p1 ss1-ZoneIn ss1-ZoneOut 818413576 23(1082) 18(1176) 45 UNKNOWN UNKNOWN N/A(N/A) ge-1/0/2.0 No N/A N/A -1 N/A
Analysis
Control Flows
MS-MPC Card
The control flows are established after the three-way handshake is complete.
Control flow from FTP client to FTP server. TCP destination port is 21.
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118Control flow from FTP server to FTP client. TCP source port is 21.
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
MX-SPC3 Card
The control flows are established after the three-way handshake is complete.
Control session from FTP client to FTP server, TCP destination port is 21.
Session ID: 536870919, Service-set: ss1, Policy name: p1/131085, Timeout: 29, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 0 In: 12.10.10.10/44194 --> 22.20.20.3/21;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 13, Bytes: 585, Out: 22.20.20.3/21 --> 60.1.1.2/48660;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 11, Bytes: 650,
Data session from FTP client to FTP server, it’s for FTP passive mode.
Session ID: 536870917, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 12.10.10.10/35281 --> 22.20.20.3/8204;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 6, Bytes: 320, Out: 22.20.20.3/8204 --> 60.1.1.2/48747;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 9, Bytes: 8239,
Data session from FTP server to FTP client, it’s for FTP active mode:
Session ID: 549978117, Service-set: ss1, Policy name: p1/131085, Timeout: 1, Valid Logical system: root-logical-system Resource information : FTP ALG, 1, 1 In: 22.20.20.3/20 --> 60.1.1.3/6049;tcp, Conn Tag: 0x0, If: vms-2/0/0.200, Pkts: 10, Bytes: 8291, Out: 12.10.10.10/33203 --> 22.20.20.3/20;tcp, Conn Tag: 0x0, If: vms-2/0/0.100, Pkts: 5, Bytes: 268,
Data Flows
A data port of 20 is negotiated for data transfer during the course of the FTP control protocol. These two flows are data flows between the FTP client and the FTP server:
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Troubleshooting Questions
How do I know if the FTP ALG is active?
The ALG protocol field in the conversation should display ftp.
There should be a valid frame count (Frm count) in the control flows.
A valid frame count in the data flows indicates that data transfer has taken place.
What do I need to check if the FTP connection is established but data transfer does not take place?
Most probably, the control connection is up, but the data connection is down.
Check the conversations output to determine whether both the control and data flows are present.
How do I interpret each flow? What does each flow mean?
FTP control flow initiator flow—Flow with destination port 21
FTP control flow responder flow—Flow with source port ;21
FTP data flow initiator flow—Flow with destination port 20
FTP data flow responder flow—Flow with source port 20
RTSP ALG Example
The following is an example of an RTSP conversation. The application uses the RTSP protocol for control connection. Once the connection is set up, the media is sent using UDP protocol (RTP).
This example consists of the following:
Sample Output for MS-MPCs
Here is the output from the show services stateful-firewall conversations operational mode command:
user@host# show services stateful-firewall conversationsInterface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
Sample Output for MX-SPC3 Services Card
Here is the output from the show services sessions application-protocol rtsp operational mode command:
user@host# run show services sessions application-protocol
rtspSession ID: 1073741828, Service-set: sset1, Policy name: p1/131081, Timeout: 116, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 0 In: 31.0.0.2/33575 --> 41.0.0.2/554;tcp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 8, Bytes: 948, Out: 41.0.0.2/554 --> 131.10.0.1/7777;tcp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 6, Bytes: 1117, Session ID: 1073741829, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 1 In: 41.0.0.2/35004 --> 131.10.0.1/7780;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 79200, Out: 31.0.0.2/30004 --> 41.0.0.2/35004;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Session ID: 1073741830, Service-set: sset1, Policy name: p1/131081, Timeout: 120, Valid Logical system: root-logical-system Resource information : RTSP ALG, 1, 4 In: 41.0.0.2/35006 --> 131.10.0.1/7781;udp, Conn Tag: 0x0, If: vms-4/0/0.2, Pkts: 220, Bytes: 174240, Out: 31.0.0.2/30006 --> 41.0.0.2/35006;udp, Conn Tag: 0x0, If: vms-4/0/0.1, Pkts: 0, Bytes: 0, Total sessions: 3
Analysis
An RTSP conversation should consist of TCP flows corresponding to the RTSP control connection. There should be two flows, one in each direction, from client to server and from server to client:
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
The RTSP control connection for the initiator flow is sent from destination port 554.
The RTSP control connection for the responder flow is sent from source port 554.
The UDP flows correspond to RTP media sent over the RTSP connection.
Troubleshooting Questions
Media does not work when the RTSP ALG is configured. What do I do?
Check RTSP conversations to see whether both TCP and UDP flows exist.
The ALG protocol should be displayed as rtsp.
Note The state of the flow is displayed as Watch, because the ALG processing is taking place and the client is essentially “watching” or processing payload corresponding to the application. For FTP and RTSP ALG flows, the control connections are always Watch flows.
How do I check for ALG errors?
You can check for errors by issuing the following command. Each ALG has a separate field for ALG packet errors.
user@host# show services stateful-firewall statistics extensiveInterface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
System Log Messages
Enabling system log generation and checking the system log are also helpful for ALG flow analysis. This section contains the following:
System Log Configuration
You can configure the enabling of system log messages at a number of different levels in the Junos OS CLI. As shown in the following sample configurations, the choice of level depends on how specific you want the event logging to be and what options you want to include. For details on the configuration options, see the Junos OS Administration Library (system level) or the Junos OS Services Interfaces Library for Routing Devices (all other levels).
At the topmost global level:
user@host# show system syslogfile messages {any any;}At the service set level:
user@host# show services service-set svc_setsyslog {host local {services any;}}stateful-firewall-rules allow_rtsp;interface-service {service-interface ms-3/2/0;}At the service rule level:
user@host# show services stateful-firewall rule allow_rtspmatch-direction input-output;term 0 {from {applications junos-rtsp;}then {accept;syslog;}}
System Log Output
System log messages are generated during flow creation, as shown in the following examples:
The following system log message indicates that the ASP matched an accept rule:
For a complete listing of system log messages, see the System Log Explorer.