[an error occurred while processing this directive][an error occurred while processing this directive]

Using Stateful Firewall Rules to Identify Data Sessions

The APPID configuration properties enable the JUNOS software to detect applications based on signatures, ports, and addresses. For signature-based detection, most of the protocol control sessions are identified, but data sessions are not identified. For example, APPID identifies FTP connections to port 21 (FTP control sessions); however, FTP can open child/data sessions to transfer files and data. These sessions are not identified by signature-based APPID because they do not have well-defined signatures.

Application-level gateways (ALGs) configured using stateful firewall rules can assist APPID in identifying these data sessions. These sessions include file and video transfers that are heavy consumers of bandwidth, so a mechanism for policing and classifying this traffic effectively is a useful tool. In addition to FTP, this mechanism applies to TFTP and RTSP traffic.

To incorporate the stateful firewall rules into Dynamic Application Awareness for JUNOS Software sessions, include the following configurations:

  1. Include the stateful firewall package at the [edit chassis fpc slot-number pic pic-number adaptive-services service-package externsion-provider] hierarchy level:
    package jservices-sfw;
  2. Define two stateful firewall rules as shown in the following example, one to identify the appropriate ALGs for FTP, TFTP, or RTSP traffic and the other to allow all traffic:

    Note: Session Initiation Protocol (SIP) is already covered by APPID and the SIP ALG is not supported by stateful firewall, hence a SIP configuration is not needed.

    [edit services]stateful-firewall {rule rule1 {match-direction input-output;term term1 {from {applications [ junos-ftp junos-tftp junos-rtsp ];}then {accept;}}}rule rule2 {match-direction input-output;term term1 {then {accept;}}}rule-set rs1 {rule rule1;rule rule2;}}

    Note: The existing AACL and L-PDF operational mode commands should report the new applications when they are identified.

  3. Attach the stateful firewall rule set to a service set, as shown in the following example:
    service-set test-chaining {application-identification-profile add-based;stateful-firewall-rule-sets rs1; idp-profile idp1;aacl-rules rule1;interface-service {service-interface ms-2/0/0.0;}}
  4. Include no-drop settings for stateful firewall and TCP, as needed.

    Stateful firewall processing drops packets in a number of scenarios:

    • TCP sessions do not start with a SYN flag. (This prevents sessions from resuming; otherwise, when the PIC starts for the first time, all existing TCP sessions in flight will be dropped).
    • If the TCP tracker detects SYN but no SYN/ACK or only an ACK, then the ACK is dropped. There are a number of similar checks to verify the TCP connection, window checks, and so forth.
    • TCP checks for stateful firewall are aggressive when ALGs are run. It is not possible to ignore TCP errors when an ALG is run on a session.
    • If an ALG detects malformed packets (for example, if the FTP PORT command is not RFC-compliant), it drops packets. If an ALG is not able to allocate resources, it drops packets.

    You can include the settings shown in the following example to assist in controlling these packet drops:

    [edit interfaces]ms-1/2/0 {services-options {ignore-errors {tcp; alg; }}}

    The tcp statement mediates the first two issues listed, with reference to TCP SYN detection. The alg statement handles the fourth issue. ALGs require strict TCP processing, which cannot be relaxed.

Published: 2010-04-28

[an error occurred while processing this directive]