Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Announcement: Our new, consolidated Junos CLI Reference is now available.

close
external-header-nav
keyboard_arrow_up
close
keyboard_arrow_left
list Table of Contents
file_download PDF
keyboard_arrow_right

Stateful Firewalls

date_range 24-Nov-23

Junos Network Secure Overview

Routers use firewalls to track and control the flow of traffic. Adaptive Services and MultiServices PICs employ a type of firewall called a . Contrasted with a firewall that inspects packets in isolation, a stateful firewall provides an extra layer of security by using state information derived from past communications and other applications to make dynamic control decisions for new communication attempts.

Note:

On ACX Series routers, the stateful firewall configuration is supported only on the ACX500 indoor routers.

Stateful firewalls group relevant into . A flow is identified by the following five properties:

  • Source address

  • Source port

  • Destination address

  • Destination port

  • Protocol

A typical Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) conversation consists of two flows: the initiation flow and the responder flow. However, some conversations, such as an FTP conversation, might consist of two control flows and many data flows.

Firewall rules govern whether the conversation is allowed to be established. If a conversation is allowed, all flows within the conversation are permitted, including flows that are created during the life cycle of the conversation.

You configure stateful firewalls using a powerful rule-driven conversation handling path. A consists of direction, source address, source port, destination address, destination port, IP protocol value, and application protocol or service. In addition to the specific values you configure, you can assign the value any to rule objects, addresses, or ports, which allows them to match any input value. Finally, you can optionally negate the rule objects, which negates the result of the type-specific match.

Firewall rules are directional. For each new conversation, the router software checks the initiation flow matching the direction specified by the rule.

Firewall rules are ordered. The software checks the rules in the order in which you include them in the configuration. The first time the firewall discovers a match, the router implements the action specified by that rule. Rules still unchecked are ignored.

Note:

Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface cards support IPv6 traffic for Junos Network Secure Stateful Firewall.

For more information, see Configuring Stateful Firewall Rules.

Stateful Firewall Support for Application Protocols

By inspecting the application protocol data, the AS or MultiServices PIC firewall can intelligently enforce security policies and allow only the minimal required packet traffic to flow through the firewall.

The firewall rules are configured in relation to an interface. By default, the stateful firewall allows all sessions initiated from the hosts behind the interface to pass through the router.

Note:

Stateful firewall ALGs are not supported on ACX500 routers.

Stateful Firewall Anomaly Checking

The stateful firewall recognizes the following events as anomalies and sends them to the IDS software for processing:

  • IP anomalies:

    • IP version is not correct.

    • IP header length field is too small.

    • IP header length is set larger than the entire packet.

    • Bad header checksum.

    • IP total length field is shorter than header length.

    • Packet has incorrect IP options.

    • Internet Control Message Protocol (ICMP) packet length error.

    • Time-to-live (TTL) equals 0.

  • IP address anomalies:

    • IP packet source is a broadcast or multicast.

    • Land attack (source IP equals destination IP).

  • IP fragmentation anomalies:

    • IP fragment overlap.

    • IP fragment missed.

    • IP fragment length error.

    • IP packet length is more than 64 kilobytes (KB).

    • Tiny fragment attack.

  • TCP anomalies:

    • TCP port 0.

    • TCP sequence number 0 and flags 0.

    • TCP sequence number 0 and FIN/PSH/RST flags set.

    • TCP flags with wrong combination (TCP FIN/RST or SYN/(URG|FIN|RST).

    • Bad TCP checksum.

  • UDP anomalies:

    • UDP source or destination port 0.

    • UDP header length check failed.

    • Bad UDP checksum.

  • Anomalies found through stateful TCP or UDP checks:

    • SYN followed by SYN-ACK packets without ACK from initiator.

    • SYN followed by RST packets.

    • SYN without SYN-ACK.

    • Non-SYN first flow packet.

    • ICMP unreachable errors for SYN packets.

    • ICMP unreachable errors for UDP packets.

  • Packets dropped according to stateful firewall rules.

Note:

ACX500 routers do not support IP fragmentation anomalies.

If you employ stateful anomaly detection in conjunction with stateless detection, IDS can provide early warning for a wide range of attacks, including these:

  • TCP or UDP network probes and port scanning

  • SYN flood attacks

  • IP fragmentation-based attacks such as teardrop, bonk, and boink

Configuring Stateful Firewall Rules

To configure a stateful firewall rule, include the rule rule-name statement at the [edit services stateful-firewall] hierarchy level:

content_copy zoom_out_map
[edit services stateful-firewall]
rule rule-name {
    match-direction (input | output | input-output);
    term term-name {
        from {
            application-sets set-name;
            applications [ application-names ];
            destination-address  (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
            destination-address-range low minimum-value high maximum-value <except>;
            destination-prefix-list list-name <except>;
            source-address  (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
            source-address-range low minimum-value high maximum-value <except>;
            source-prefix-list list-name <except>;
        }
        then {
            (accept <skip-ids>| discard | reject);
            allow-ip-options [ values ];
            syslog;
        }
    }
}
Note:

ACX500 routers do not support applications and application-sets at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.

Note:

On ACX500 routers, to enable syslog, include the stateful-firewall-logs CLI statement at the [edit services service-set service-set-name syslog host local class] hierarchy level.

Note:

edit services stateful-firewall hierarchy is not supported on SRX series.

Each stateful firewall rule consists of a set of terms, similar to a filter configured at the [edit firewall] hierarchy level. A term consists of the following:

  • from statement—Specifies the match conditions and applications that are included and excluded. The from statement is optional in stateful firewall rules.

  • then statement—Specifies the actions and action modifiers to be performed by the router software. The then statement is mandatory in stateful firewall rules.

ACX500 Series routers do not support the following while configuring stateful firewall rules:

  • match-direction (output | input-output)

  • post-service-filter at the interface service input hierarchy level.

  • IPv6 source address and destination address.

  • application-sets, application, allow-ip-options at the [edit services stateful-firewall] hierarchy level.

  • Application Layer Gateways (ALGs).

  • Chaining of services within Multiservices Modular Interfaces Card (MS-MIC) and with inline-services (-si).

  • Class of service.

  • The following show services stateful-firewall CLI commands are not supported:

    • show services stateful-firewall conversations—Show conversations

    • show services stateful-firewall flow-analysis—Show flow table entries

    • show services stateful-firewall redundancy-statistics—Show redundancy statistics

    • show services stateful-firewall sip-call—Show SIP call information

    • show services stateful-firewall sip-register—Show SIP register information

    • show services stateful-firewall subscriber-analysis—Show subscriber table entries

The following sections explain how to configure the components of stateful firewall rules:

Configuring Match Direction for Stateful Firewall Rules

Each rule must include a match-direction statement that specifies the direction in which the rule match is applied. To configure where the match is applied, include the match-direction statement at the [edit services stateful-firewall rule rule-name] hierarchy level:

content_copy zoom_out_map
[edit services stateful-firewall rule rule-name]
match-direction (input | output | input-output);
Note:

ACX500 Series routers do not support match-direction (output | input-output).

If you configure match-direction input-output, sessions initiated from both directions might match this rule.

The match direction is used with respect to the traffic flow through the AS or Multiservices PIC. When a packet is sent to the PIC, direction information is carried along with it.

With an interface service set, packet direction is determined by whether a packet is entering or leaving the interface on which the service set is applied.

With a next-hop service set, packet direction is determined by the interface used to route the packet to the AS or Multiservices PIC. If the inside interface is used to route the packet, the packet direction is input. If the outside interface is used to direct the packet to the PIC, the packet direction is output. For more information on inside and outside interfaces, see Configuring Service Sets to be Applied to Services Interfaces.

On the PIC, a flow lookup is performed. If no flow is found, rule processing is performed. Rules in this service set are considered in sequence until a match is found. During rule processing, the packet direction is compared against rule directions. Only rules with direction information that matches the packet direction are considered. Most packets result in the creation of bidirectional flows.

Configuring Match Conditions in Stateful Firewall Rules

To configure stateful firewall match conditions, include the from statement at the [edit services stateful-firewall rule rule-name term term-name] hierarchy level:

content_copy zoom_out_map
[edit services stateful-firewall rule rule-name term term-name]
from {
    application-sets set-name;
    applications [ application-names ];
    destination-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
    destination-address-range low minimum-value high maximum-value <except>;
    destination-prefix-list list-name <except>;
    source-address (address | any-ipv4 | any-ipv6 | any-unicast) <except>;
    source-address-range low minimum-value high maximum-value <except>;
    source-prefix-list list-name <except>;
}
Note:

ACX500 routers do not support applications and application-sets at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.

The source address and destination address can be either IPv4 or IPv6.

You can use either the source address or the destination address as a match condition, in the same way that you would configure a firewall filter; for more information, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide. You can use the wildcard values any-unicast, which denotes matching all unicast addresses, any-ipv4, which denotes matching all IPv4 addresses, or any-ipv6, which denotes matching all IPv6 addresses.

Alternatively, you can specify a list of source or destination prefixes by configuring the prefix-list statement at the [edit policy-options] hierarchy level and then including either the destination-prefix-list or the source-prefix-list statement in the stateful firewall rule. For an example, see Examples: Configuring Stateful Firewall Rules.

If you omit the from term, the stateful firewall accepts all traffic and the default protocol handlers take effect:

  • User Datagram Protocol (UDP), Transmission Control Protocol (TCP), and Internet Control Message Protocol (ICMP) create a bidirectional flow with a predicted reverse flow.

  • IP creates a unidirectional flow.

You can also include application protocol definitions you have configured at the [edit applications] hierarchy level; for more information, see Configuring Application Properties.

  • To apply one or more specific application protocol definitions, include the applications statement at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.

  • To apply one or more sets of application protocol definitions you have defined, include the application-sets statement at the [edit services stateful-firewall rule rule-name term term-name from] hierarchy level.

    Note:

    If you include one of the statements that specifies application protocols, the router derives port and protocol information from the corresponding configuration at the [edit applications] hierarchy level; you cannot specify these properties as match conditions.

Configuring Actions in Stateful Firewall Rules

To configure stateful firewall actions, include the then statement at the [edit services stateful-firewall rule rule-name term term-name] hierarchy level:

content_copy zoom_out_map
[edit services stateful-firewall rule rule-name term term-name]
then {
    (accept | discard | reject);
    allow-ip-options [ values ];
    syslog;
}

You must include one of the following actions:

  • accept—The packet is accepted and sent on to its destination.

  • accept skip-ids—The packet is accepted and sent on to its destination, but IDS rule processing configured on an MS-MPC is skipped.

  • discard—The packet is not accepted and is not processed further.

  • reject—The packet is not accepted and a rejection message is returned; UDP sends an ICMP unreachable code and TCP sends RST. Rejected packets can be logged or sampled.

Note:

The ACX500 indoor routers do not support the action accept skip-ids.

You can optionally configure the firewall to record information in the system logging facility by including the syslog statement at the [edit services stateful-firewall rule rule-name term term-name then] hierarchy level. This statement overrides any syslog setting included in the service set or interface default configuration.

Configuring IP Option Handling

You can optionally configure the firewall to inspect IP header information by including the allow-ip-options statement at the [edit services stateful-firewall rule rule-name term term-name then] hierarchy level. When you configure this statement, all packets that match the criteria specified in the from statement are subjected to additional matching criteria. A packet is accepted only when all of its IP option types are configured as values in the allow-ip-options statement. If you do not configure allow-ip-options, only packets without IP header options are accepted.

Note:

ACX500 indoor routers do not support the configuration of allow-ip-options statement.

The additional IP header option inspection applies only to the accept and reject stateful firewall actions. This configuration has no effect on the discard action. When the IP header inspection fails, reject frames are not sent; in this case, the reject action has the same effect as discard.

If an IP option packet is accepted by the stateful firewall, Network Address Translation (NAT) and intrusion detection service (IDS) are applied in the same way as to packets without IP option headers. The IP option configuration appears only in the stateful firewall rules; NAT applies to packets with or without IP options.

When a packet is dropped because it fails the IP option inspection, this exception event generates both IDS event and system log messages. The event type depends on the first IP option field rejected.

Table 1 lists the possible values for the allow-ip-options statement. You can include a range or set of numeric values, or one or more of the predefined IP option settings. You can enter either the option name or its numeric equivalent. For more information, refer to http://www.iana.org/assignments/ip-parameters.

Table 1: IP Option Values

IP Option Name

Numeric Value

Comment

any

0

Any IP option

ip-security

130

ip-stream

136

loose-source-route

131

route-record

7

router-alert

148

strict-source-route

137

timestamp

68

Configuring Stateful Firewall Rule Sets

The rule-set statement defines a collection of stateful firewall rules that determine what actions the router software performs on packets in the data stream. You define each rule by specifying a rule name and configuring terms. Then, you specify the order of the rules by including the rule-set statement at the [edit services stateful-firewall] hierarchy level with a rule statement for each rule:

content_copy zoom_out_map
[edit services stateful-firewall]
rule-set rule-set-name {
    rule rule-name;
}

The router software processes the rules in the order in which you specify them in the configuration. If a term in a rule matches the packet, the router performs the corresponding action and the rule processing stops. If no term in a rule matches the packet, processing continues to the next rule in the rule set. If none of the rules matches the packet, the packet is dropped by default.

Examples: Configuring Stateful Firewall Rules

The following example shows a stateful firewall configuration containing two rules, one for input matching on a specified application set and the other for output matching on a specified source address:

content_copy zoom_out_map
[edit services]
stateful-firewall {
    rule Rule1 {
        match-direction input;
        term 1 {
            from {
                application-sets Applications;
            }
            then {
                accept;
            }
        }
        term accept {
            then {
                accept;
            }
        }
    }
    rule Rule2 {
        match-direction output;
        term Local {
            from {
                source-address {
                    10.1.3.2/32;
                }
            }
            then {
                accept;
            }
        }
    }
}

The following example has a single rule with two terms. The first term rejects all traffic in my-application-group that originates from the specified source address, and provides a detailed system log record of the rejected packets. The second term accepts Hypertext Transfer Protocol (HTTP) traffic from anyone to the specified destination address.

content_copy zoom_out_map
[edit services stateful-firewall]
rule my-firewall-rule {
    match-direction input-output;
    term term1 {
        from {
            source-address 10.1.3.2/32;
            application-sets my-application-group;
        }
        then {
            reject;
            syslog;
        }
    }
    term term2 {
        from {
            destination-address 10.2.3.2/32;
            applications http;
        }
        then {
            accept;
        }
    }
}

The following example shows use of source and destination prefix lists. This requires two separate configuration items.

You configure the prefix list at the [edit policy-options] hierarchy level:

content_copy zoom_out_map
[edit]
policy-options {
    prefix-list p1 {
        10.1.1.1/32;
        10.2.2.0/24;
    }
    prefix-list p2 {
        10.3.3.3/32;
        10.4.4.0/24;
    }
}

You reference the configured prefix list in the stateful firewall rule:

content_copy zoom_out_map
[edit]
services {
    stateful-firewall {
        rule r1 {
            match-direction input;
            term t1 {
                from {
                    source-prefix-list {
                        p1;
                    }
                    destination-prefix-list {
                        p2;
                    }
                }
                then {
                    accept;
                }
            }
        }
    }
}

This is equivalent to the following configuration:

content_copy zoom_out_map
[edit]
services {
    stateful-firewall {
        rule r1 {
            match-direction input;
            term t1 {
                from {
                    source-address {
                        10.1.1.1/32;
                        10.2.2.0/24;
                    }
                    destination-address {
                        10.3.3.3/32;
                        10.4.4.0/24;
                    }
                }
                then {
                    accept;
                }
            }
        }
    }
}

You can use the except qualifier with the prefix lists, as in the following example. In this case, the except qualifier applies to all prefixes included in prefix list p2.

content_copy zoom_out_map
[edit]
services {
    stateful-firewall {
        rule r1 {
            match-direction input;
            term t1 {
                from {
                    source-prefix-list {
                        p1;
                    }
                    destination-prefix-list {
                        p2 except;
                    }
                }
                then {
                    accept;
                }
            }
        }
    }
}

For additional examples that combine stateful firewall configuration with other services and with virtual private network (VPN) routing and forwarding (VRF) tables, see the configuration examples.

Note:

You can define the service-set and assign it either as interface style or next-hop style.

Example: BOOTP and Broadcast Addresses

The following example supports Bootstrap Protocol (BOOTP) and broadcast addresses:

content_copy zoom_out_map
[edit applications]
application bootp {
    application-protocol bootp;
    protocol udp;
    destination-port 67;
}
[edit services]
stateful-firewall bootp-support {
    rule bootp-allow {
        direction input;
        term bootp-allow {
            from {
                destination-address {
                    any-unicast;
                    255.255.255.255;
                }
                application bootp;
            }
            then {
                accept;
            }
        }
    }
}

Example: Configuring Layer 3 Services and the Services SDK on Two PICs

You can configure the Layer 3 service package and the Services SDK on two PICs. For this example, you must configure an FTP or HTTP client and a server. In this configuration, the client side of the router interface is ge-1/2/2.1 and the server side of the router interface is ge-1/1/0.48. This configuration enables Network Address Translation (NAT) with stateful firewall (SFW) on the uKernel PIC and application identification (APPID), application-aware access list (AACL), and intrusion detection and prevention (IDP) on the Services SDK PIC for FTP or HTTP traffic.

Note:

The Services SDK does not support NAT yet. When NAT is required, you can configure the Layer 3 service package to deploy NAT along with the Services SDK such as APPID, AACL, or IDP.

Note:

The IDP functionality is deprecated for the MX Series for Junos OS release 17.1R1 and above.

To deploy the Layer 3 service package and the Services SDK on two PICs:

  1. In configuration mode, go to the following hierarchy level:
    content_copy zoom_out_map
    [edit services]
    user@host# edit stateful-firewall
    
  2. In the hierarchy level, configure the conditions for the stateful firewall rule r1.
    content_copy zoom_out_map
    [edit services stateful-firewall]
    user@host# set rule rule-name match-direction input-output term term from applications application-name
    user@host# set rule rule-name match-direction input-output term term then accept syslog
    

    In this example, the stateful firewall term is ALLOWED-SERVICES. Enclose the application names—junos-ftp, junos-http, and junos-icmp-ping—in brackets for application-name.

    content_copy zoom_out_map
    [edit services stateful-firewall]
    user@host# set rule r1 match-direction input-output term ALLOWED-SERVICES from applications [ junos-ftp junos-http junos-icmp-ping ]
    user@host# set rule r1 match-direction input-output term ALLOWED-SERVICES then accept syslog
    
  3. Configure the conditions for the stateful firewall rule r2.
    content_copy zoom_out_map
    [edit services stateful-firewall]
    user@host# set rule rule-name match-direction input-output term term then discard
    user@host# set rule rule-name match-direction input-output term term then syslog
    

    In this example, the stateful firewall term is term1.

    content_copy zoom_out_map
    [edit services stateful-firewall]
    user@host# set rule r2 match-direction input-output term term1 then discard
    user@host# set rule r2 match-direction input-output term term1 then syslog
    
  4. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit services stateful-firewall]
    user@host# show 
    rule r1 {
        match-direction input-output;
        term ALLOWED-SERVICES {
            from {
                applications [ junos-ftp junos-http junos-icmp-ping ];
            }
            then {
                accept;
                syslog;
            }
        }
    }
    rule r2 {
        match-direction input-output;
        term term1 {
            then {
                discard;
                syslog;
            }
        }
    }
  5. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit services]
    user@host# edit nat
    
  6. In the hierarchy level, configure the NAT pool.
    content_copy zoom_out_map
    [edit services nat]
    user@host# set pool pool-name address ip-address
    user@host# set pool pool-name port automatic
    

    In this example, the NAT pool is OUTBOUND-SERVICES and the IP address is 10.48.0.2/32.

    content_copy zoom_out_map
    [edit services natl]
    user@host# set pool OUTBOUND-SERVICES address 10.48.0.2/32
    user@host# set pool OUTBOUND-SERVICES port automatic
    
  7. Configure the NAT rule.
    content_copy zoom_out_map
    [edit services nat]
    user@host# set rule rule-name match-direction output term term from applications application-name
    user@host# set rule rule-name match-direction output term term then translated source-pool source-pool translation-type source dynamic
    

    In this example, the NAT rule is SET-MSR-ADDR, the NAT term is TRANSLATE-SOURCE-ADDR, and the source pool is OUTBOUND-SERVICES. Enclose the application names—junos-ftp, junos-http, and junos-icmp-ping—in parentheses for application-name.

    content_copy zoom_out_map
    [edit services nat]
    user@host# set rule SET-MSR-ADDR match-direction output term TRANSLATE-SOURCE-ADDR from applications [ junos-ftp junos-http junos-icmp-ping ] 
    user@host# set rule SET-MSR-ADDR match-direction output term TRANSLATE-SOURCE-ADDR then translated source-pool OUTBOUND-SERVICES translation-type source dynamic
    
  8. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit services nat]
    user@host# show 
    pool OUTBOUND-SERVICES {
        address 11.48.0.2/32;
        port {
            automatic;
        }
    }
    rule SET-MSR-ADDR {
        match-direction output;
        term TRANSLATE-SOURCE-ADDR {
            from {
                applications [ junos-ftp junos-http junos-icmp-ping ]; 
            }
            then {
                translated {
                    source-pool OUTBOUND-SERVICES;
                    translation-type {
                        source dynamic;
                    }
                }
            }
        }
    }
  9. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit security]
    user@host# edit idp
    
    Note:

    The [edit security idp] statements are deprecated for the MX Series for Junos OS release 17.1R1 and above.

  10. In the hierarchy level, configure the IDP policy.
    content_copy zoom_out_map
    [edit security idp]
    user@host# set idp-policy policy-name rulebase-ips rule rule-name match application default attacks predefined-attacks attack-name
    user@host# set idp-policy policy-name rulebase-ips rule rule-name match application default attacks predefined-attack-groups attack-group--name
    user@host# set idp-policy policy-name rulebase-ips rule rule-name then action no-action
    user@host# set idp-policy policy-name rulebase-ips rule rule-name then notification log-attacks alert
    

    In this example, the IDP policy is test1, the rule is r1, the predefined attack is FTP:USER:ROOT, and the predefined attack group is "Recommended Attacks".

    content_copy zoom_out_map
    [edit security idp]
    user@host# set idp-policy test1 rulebase-ips rule r1 match application default attacks predefined-attacks FTP:USER:ROOT
    user@host# set idp-policy test1 rulebase-ips rule r1 match application default attacks predefined-attack-groups [ "Recommended Attacks" ]
    user@host# set idp-policy test1 rulebase-ips rule r1 then action no-action
    user@host# set idp-policy test1 rulebase-ips rule r1 then notification log-attacks alert
    
  11. Configure the trace options for IDP services.
    content_copy zoom_out_map
    [edit security idp]
    user@host# set traceoptions file filename
    user@host# set traceoptions flag all
    user@host# set traceoptions level all
    

    In this example, the log file name is idp-demo.log.

    content_copy zoom_out_map
    [edit security idp]
    user@host# set traceoptions file idp-demo.log
    user@host# set traceoptions flag all
    user@host# set traceoptions level all
    
  12. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit security idp]
    user@host# show 
    idp-policy test1 {
        rulebase-ips {
            rule r1 {
                match {
                    application default;
                    attacks {
                        predefined-attacks FTP:USER:ROOT;
                        predefined-attack-groups "Recommended Attacks";
                    }
                }
                then {
                    action {
                        no-action;
                    }
                    notification {
                        log-attacks {
                            alert;
                        }
                    }
                }
            }
        }
    }
    traceoptions {
        file idp-demo.log;
        flag all;
        level all;
    }
  13. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit services]
    user@host# edit aacl
    
  14. In the hierarchy level, configure the AACL rules.
    content_copy zoom_out_map
    [edit services aacl]
    user@host# set rule rule-name  match-direction input-output term term from application-group-any
    user@host# set rule rule-name  match-direction input-output term term then count application accept
    

    In this example, the AACL rule is app-aware and the term is t1.

    content_copy zoom_out_map
    [edit services aacl]
    user@host# set rule app-aware  match-direction input-output term t1 from application-group-any
    user@host# set rule app-aware  match-direction input-output term t1 then count application accept
    
  15. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit services aacl]
    user@host# show 
    rule app-aware {
                match-direction input-output;
                term t1 {
                    from {
                        application-group-any;
                    }
                    then {
                        count application;
                        accept;
                    }
                }
            }
    
  16. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit services]
    user@host# edit service-set App-Aware-Set
    
  17. Configure the APPID profile.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set application-identification-profile application-identification-profile
    

    In this example, the APPID profile is dummy-profile.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set application-identification-profile dummy-profile
    
  18. Configure the IDP profile.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set idp-profile idp-profile
    

    In this example, the IDP profile is test1.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set idp-profile test1
    
  19. Configure the policy decision statistics profile.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set policy-decision-statistics-profile profile-name
    

    In this example, the policy decision statistics profile is lpdf-stats.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set policy-decision-statistics-profile lpdf-stats
    
  20. Configure the AACL rules.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set aacl-rules rule-name
    

    In this example, the AACL rule name is app-aware.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set aacl-rules app-aware
    
  21. Configure two stateful firewall rules.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set stateful-firewall-rules rule-name
    user@host# set stateful-firewall-rules rule-name
    

    In this example, the first rule is r1 and the second rule is r2.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set stateful-firewall-rules r1
    user@host# set stateful-firewall-rules r2
    
  22. In the hierarchy level, configure the service set to bypass traffic on service PIC failure.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set service-set-options bypass-traffic-on-pic-failure
    
  23. Configure interface-specific service set options.
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set interface-service service-interface service-interface
    

    In this example, the services interface is ms-0/1/0.

    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# set interface-service service-interface ms-0/1/0
    
  24. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit services service-set App-Aware-Set]
    user@host# show 
    application-identification-profile dummy-profile;
    idp-profile test1;
    policy-decision-statistics-profile {
        lpdf-stats;
    }
    aacl-rules app-aware;
    stateful-firewall-rules r1;
    stateful-firewall-rules r2;
    service-set-options {
        bypass-traffic-on-pic-failure;
    }
    interface-service {
        service-interface ms-0/1/0;
    }
  25. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit services]
    user@host# edit service-set NAT-SFW-SET
    
  26. In the hierarchy level, configure optional notification parameters for the services interface. Note that it is required only for debugging.
    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set syslog host host-name services any
    

    In this example, the host to notify is local.

    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set services-options syslog host local services any
    
  27. Configure two stateful firewall rules.
    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set stateful-firewall-rules rule-name
    user@host# set stateful-firewall-rules rule-name
    

    In this example, the first rule is r1 and the second rule is r2.

    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set stateful-firewall-rules r1
    user@host# set stateful-firewall-rules r2
    
  28. Configure NAT rules.
    content_copy zoom_out_map
    [edit services service-set  NAT-SFW-SET]
    user@host# set nat-rules rule-name
    

    In this example, the NAT rule is SET-MSR-ADDR.

    content_copy zoom_out_map
    [edit services service-set  NAT-SFW-SET]
    user@host# set nat-rules SET-MSR-ADDR
    
  29. Configure interface-specific service set options.
    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set interface-service service-interface service-interface
    

    In this example, the services interface is sp-3/1/0.

    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# set interface-service service-interface sp-3/1/0
    
  30. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit services service-set NAT-SFW-SET]
    user@host# show 
    syslog {
        host local {
            services any;
        }
    }
    stateful-firewall-rules r1;
    stateful-firewall-rules r2;
    interface-service {
        service-interface sp-3/1/0;
    }
  31. Go to the following hierarchy level:
    content_copy zoom_out_map
    user@host# edit interfaces
    
  32. In the hierarchy level, configure the interface.
    content_copy zoom_out_map
     [edit interfaces]
    user@host# set interface
    

    In this example, the interface is ge-1/2/2.1.

    content_copy zoom_out_map
    [edit interfaces]
    user@host# set ge-1/2/2.1
    
  33. Go to the following hierarchy level:
    content_copy zoom_out_map
     [edit interfaces]
    user@host# edit ge-1/2/2.1
    
  34. In the hierarchy level, configure the service set for received packets.
    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1]
    user@host#  set family inet service input service-set service-set-name
    

    In this example, the input service set is App-Aware-Set.

    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1]
    user@host# set family inet service input service-set App-Aware-Set
    
  35. Configure the service set for transmitted packets.
    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1]
    user@host#  set family inet service output service-set service-set-name
    

    In this example, the output service set is App-Aware-Set.

    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1]
    user@host# set family inet service output service-set App-Aware-Set
    
  36. Go to the following hierarchy level:
    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1]
    user@host# edit family inet
    
  37. In the hierarchy level, configure the interface address.
    content_copy zoom_out_map
     [edit interfaces ge-1/2/2 unit 1 family inet]
    user@host# set address source
    

    In this example, the interface address is 10.10.9.10/30.

    content_copy zoom_out_map
     [edit interfaces]
    user@host# set address 10.10.9.10/30
    
  38. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit interfaces ge-1/2/2 unit 1]
    user@host# show
    family inet {
        service {
            input {
                service-set App-Aware-Set;
            }
            output {
                service-set App-Aware-Set;
            }
        }
        address 10.10.9.10/30;
    }
  39. Go to the following hierarchy level:
    content_copy zoom_out_map
    user@host# edit interfaces
    
  40. In the hierarchy level, configure the interface.
    content_copy zoom_out_map
     [edit interfaces]
    user@host# set interface
    

    In this example, the interface is ge-1/1/0.48.

    content_copy zoom_out_map
    [edit interfaces]
    user@host# set ge-1/1/0.48
    
  41. Go to the following hierarchy level:
    content_copy zoom_out_map
     [edit interfaces]
    user@host# edit ge-1/1/0.48
    
  42. In the hierarchy level, configure the service set for received packets.
    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# set family inet service input service-set service-set-name
    

    In this example, the service set is NAT-SFW-SET.

    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# set family inet service input service-set NAT-SFW-SET
    
  43. Configure the service set for transmitted packets.
    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# set family inet service output service-set service-set-name
    

    In this example, the service set is NAT-SFW-SET.

    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# set family inet service output service-set NAT-SFW-SET
    
  44. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# edit family inet
    
  45. Configure the interface address.
    content_copy zoom_out_map
     [edit interfaces ge-1/1/0 unit 48 family inet]
    user@host# set address source
    

    In this example, the interface address is 10.48.0.1/31.

    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48 family inet]
    user@host# set address 10.48.0.1/31
    
  46. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit interfaces ge-1/1/0 unit 48]
    user@host# show 
    family inet {
        service {
            input {
                service-set NAT-SFW-SET;
                }
            output {
                service-set NAT-SFW-SET;
            }
        }
        address 10.48.0.1/31;
    }
  47. Go to the following hierarchy level:
    content_copy zoom_out_map
    user@host# edit interfaces
    
  48. In the hierarchy level, configure the interface.
    content_copy zoom_out_map
    [edit interfaces]
    set interface
    

    In this example, the interface is ms-0/1/0.0.

    content_copy zoom_out_map
    [edit interfaces]
    user@host# set ms-0/1/0.0
    
  49. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit interfaces]
    user@host# edit ms-0/1/0.0
    
  50. In the hierarchy level, configure the protocol family.
    content_copy zoom_out_map
    [edit interfaces ms-0/1/0 unit 0]
    user@host# set family inet 
    
  51. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit interfaces ms-0/1/0]
    user@host# show 
    unit 0 {
        family inet;
    }
  52. Go to the following hierarchy level:
    content_copy zoom_out_map
    user@host# edit interfaces
    
  53. In the hierarchy level, configure the interface.
    content_copy zoom_out_map
    [edit interfaces]
    set interface
    

    In this example, the interface is sp-3/1/0.0.

    content_copy zoom_out_map
    [edit interfaces]
    user@host# set sp-3/1/0.0
    
  54. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit interfaces]
    user@host# edit sp-3/1/0
    
  55. In the hierarchy level, configure optional notification parameters for the services interface. Note that it is required only for debugging.
    content_copy zoom_out_map
    [edit interfaces sp-3/1/0]
    user@host# set services-options syslog host host-name services any
    

    In this example, the host to notify is local.

    content_copy zoom_out_map
    [edit interfaces sp-3/1/0]
    user@host# set services-options syslog host local services any
    
  56. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit interfaces]
    user@host# edit sp-3/1/0.0
    
  57. In the hierarchy level, configure the protocol family.
    content_copy zoom_out_map
    [edit interfaces sp-3/1/0 unit 0]
    user@host# set family inet
    
  58. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit interfaces sp-3/1/0]
    user@host# show 
    services-options {
        syslog {
            host local {
                services any;
            }
        }
    }
    unit 0 {
        family inet;
    }
  59. Go to the following hierarchy level:
    content_copy zoom_out_map
    [edit chassis]
    
  60. In the hierarchy level, configure the redundancy settings.
    content_copy zoom_out_map
    [edit chassis]
    user@host# set no-service-pic-restart-on-failover
    user@host# set redundancy graceful-switchover
    
  61. Configure the FPC and PIC.
    content_copy zoom_out_map
     [edit chassis]
    user@host# edit fpc slot pic slot
    

    In this example, the FPC is in slot 0 and the PIC is in slot 1.

    content_copy zoom_out_map
     [edit chassis]
    user@host# edit fpc 0 pic 1
    
  62. Configure the number of cores dedicated to run control functionality.
    content_copy zoom_out_map
     [edit chassis fpc slot pic slot]
    user@host#  set adaptive-services service-package extension-provider control-cores control-cores
    

    In this example, the number of control cores is 1.

    content_copy zoom_out_map
     [edit chassis fpc 1 pic 0]
    user@host#  set adaptive-services service-package extension-provider control-cores 1
    
  63. Configure the number of processing cores dedicated to data.
    content_copy zoom_out_map
     [edit chassis fpc slot pic slot]
    user@host# set adaptive-services service-package extension-provider data-cores data-cores
    

    In this example, the number of data cores is 7.

    content_copy zoom_out_map
     [edit chassis fpc 1 pic 0]
    user@host# set adaptive-services service-package extension-provider data-cores 7
    
  64. Configure the size of the object cache in megabytes. Only values in increments of 128 MB are allowed and the maximum value of object cache can be 1280 MB. On MS-100, the value is 512 MB.
    content_copy zoom_out_map
     [edit chassis fpc slot pic slot]
    user@host# set adaptive-services service-package extension-provider object-cache-size object-cache-size
    

    In this example, the size of the object cache is 1280 MB.

    content_copy zoom_out_map
     [edit chassis fpc 1 pic 0]
    user@host# set adaptive-services service-package extension-provider object-cache-size 1280
    
  65. Configure the size of the policy database in megabytes.
    content_copy zoom_out_map
     [edit chassis fpc slot pic slot]
    user@host# set adaptive-services service-package extension-provider policy-db-size policy-db-size
    

    In this example, the size of the policy database is 64 MB.

    content_copy zoom_out_map
     [edit chassis fpc 1 pic 0]
    user@host# set adaptive-services service-package extension-provider policy-db-size 64
    
  66. Configure the packages.
    content_copy zoom_out_map
     [edit chassis fpc slot pic slot]
    user@host# set adaptive-services service-package extension-provider package package
    

    In this example, the first package is jservices-appid, the second package is jservices-aacl, the third package is jservices-llpdf, the fourth package is jservices-idp, and the fifth package is jservices-sfw. jservices-sfw is available only in Junos OS Release 10.1 and later.

    content_copy zoom_out_map
     [edit chassis fpc 1 pic 0]
    user@host# set adaptive-services service-package extension-provider package jservices-appid 
    user@host# set adaptive-services service-package extension-provider package jservices-aacl
    user@host# set adaptive-services service-package extension-provider package jservices-llpdf
    user@host# set adaptive-services service-package extension-provider package jservices-idp
    user@host# set adaptive-services service-package extension-provider package jservices-sfw
    
  67. Configure the IP network services.
    content_copy zoom_out_map
     [edit chassis]
    user@host# set network-services ip
    
  68. Go to the following hierarchy level and verify the configuration:
    content_copy zoom_out_map
    [edit chassis]
    user@host# show chassis 
    no-service-pic-restart-on-failover;
    filter-memory-enhanced;
    redundancy {
        graceful-switchover;
    }
    fpc 0 {
        pic 1 {
            adaptive-services {
                service-package {
                    extension-provider {
                        control-cores 1;
                        data-cores 7;
                        object-cache-size 1280;
                        policy-db-size 64;
                        package jservices-appid;
                        package jservices-aacl;
                        package jservices-llpdf;
                        package jservices-idp;
                        package jservices-sfw;
                    }
                }
            }
        }
    }
    network-services ip;

Example: Virtual Routing and Forwarding (VRF) and Service Configuration

The following example combines virtual routing and forwarding (VRF) and services configuration:

content_copy zoom_out_map
[edit policy-options]
policy-statement test-policy {
    term t1 {
        then reject;
    }
}
[edit routing-instances]
test {
    interface ge-0/2/0.0;
    interface sp-1/3/0.20;
    instance-type vrf;
    route-distinguisher 10.58.255.1:37;
    vrf-import test-policy;
    vrf-export test-policy;
    routing-options {
        static {
            route 0.0.0.0/0 next-table inet.0;
        }
    }
}
[edit interfaces]
ge-0/2/0 {
    unit 0 {
        family inet {
            service {
                input service-set nat-me;
                output service-set nat-me;
            }
        }
    }
}
sp-1/3/0 {
    unit 0 {
        family inet;
    }
    unit 20 {
        family inet;
        service-domain inside;
    }
    unit 21 {
        family inet;
        service-domain outside;
    }
    [edit services]
    stateful-firewall {
        rule allow-any-input {
            match-direction input;
            term t1 {
                then accept;
            }
        }
    }
    nat {
        pool hide-pool {
            address 10.58.16.100;
            port automatic;
        }
        rule hide-all-input {
            match-direction input;
            term t1 {
                then {
                    translated {
                        source-pool hide-pool;
                        translation-type source napt-44;
                    }
                }
            }
        }
    }
    service-set nat-me {
        stateful-firewall-rules allow-any-input;
        nat-rules hide-all-input;
        interface-service {
            service-interface sp-1/3/0.20;
        }
    }
}

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
17.1R1
The IDP functionality is deprecated for the MX Series for Junos OS release 17.1R1 and above.
17.1R1
The [edit security idp] statements are deprecated for the MX Series for Junos OS release 17.1R1 and above.
17.1
accept skip-ids—The packet is accepted and sent on to its destination, but IDS rule processing configured on an MS-MPC is skipped.
14.2
Starting in Junos OS Release 14.2, MS-MPC and MS-MIC interface cards support IPv6 traffic for Junos Network Secure Stateful Firewall.
external-footer-nav