Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Configuring Application Protocol 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.

Note: 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 Network Address Translation.

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.

For a complete list of possible numeric values, see RFC 1700, Assigned Numbers (for the Internet Protocol Suite).

Note: 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 Network Address Translation.

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.

Note: 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.

For more information about matching criteria, see the Routing Policy Configuration 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 30 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 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 supported standard is described in RFC 3261, SIP: Session Initiation Protocol, which includes stateful firewall and Network Address Translation (NAT) support for SIP dialogs and UDP IPv4 transport of SIP messages.

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;

  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.

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

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

Limitations

• Only the methods described in RFC 3261 are supported.
• Only SIP version 3 is supported.
• TCP is not supported as a transport mechanism for signaling messages.
• IPv6 signaling data is not supported.
• Authentication is not supported.
• Encrypted messages are not supported.
• SIP fragmentation is not supported.
• The maximum UDP packet size containing a SIP message is assumed to be 4 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.
• 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.
• When 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. In such cases, you should not configure the ALG.

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.