Firewall Filter Terminating Actions

Firewall filters support a set of terminating actions for each protocol family. A filter-terminating action halts all evaluation of a firewall filter for a specific packet. The router performs the specified action, and no additional terms are examined.

Note:

You cannot configure the next term action with a terminating action in the same filter term. However, you can configure the next term action with another nonterminating action in the same filter term.

On Junos OS and Junos OS Evolved, next term cannot appear as the last term of the action. A filter term where next term is specified as an action but without any match conditions configured is not supported.

For MX Series routers with MPCs, you need to initialize the filter counter for Trio-only match filters by walking the corresponding SNMP MIB, for example, show snmp mib walk name ascii. This forces Junos to learn the filter counters and ensure that the filter statistics are displayed. This guidance applies to all enhanced mode firewall filters, filters with flexible conditions, and filters with the certain terminating actions. See those topics, listed under Related Documentation, for details.

Table 1 describes the terminating actions you can specify in a firewall filter term.

Table 1: Terminating Actions for Firewall Filters
Terminating Action	Description	Protocols
`accept`	Accept the packet.	`family any` `family inet` `family inet6` `family mpls` `family vpls` `family ccc` `family bridge` `family ethernet-switching` (for EX Series switches only)
`decapsulate gre [ routing-instance instance-name ]`	At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable de-encapsulation of generic routing encapsulation (GRE) packets transported through a filter-based GRE tunnel. You can configure a filter term that pairs this action with a match condition that includes a packet header match for the GRE protocol. For an IPv4 filter, include the `protocol gre` (or `protocol 47`) match condition. Attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches a de-encapsulating filter to an interface that does not support filter-based GRE tunneling, the system writes a syslog warning message that the interface does not support the filter. When the interface receives a matched packet, processes that run on the Packet Forwarding Engine perform the following operations: Remove the outer GRE header. Forward the inner payload packet to its original destination by performing destination lookup. By default, the Packet Forwarding Engine uses the default routing instance to forward payload packets to the destination network. If the payload is MPLS, the Packet Forwarding Engine performs route lookup on the MPLS path routing table using the route label in the MPLS header. If you specify the `decapsulate` action with an optional routing instance name, the Packet Forwarding Engine performs route lookup on the routing instance, and the instance must be configured. Note: On MX960 routers, the `decapsulate` action de-encapsulates GRE, IP-in-IP and IPv6-in-IP tunneling packets. You configure this action at the `[edit firewall family inet filter filter-name term term-name]` hierarchy level . For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks and Components of Filter-Based Tunneling Across IPv4 Networks.	`family inet`
`decapsulate l2tp [ routing-instance instance-name ] [ forwarding-class class-name ] [ output-interface interface-name ] [ cookie l2tpv3-cookie ] [ sample ]`	At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable de-encapsulation of Layer 2 tunneling protocol (L2TP) packets transported through a filter-based L2TP tunnel. You can configure a filter term that pairs this action with a match condition that includes a packet header match for the L2TP protocol. For IPv4 traffic, an input firewall filter `$junos-input-filter` and an output firewall filter `$junos-output-filter` are attached to the interface. Attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches a de-encapsulating filter to an interface that does not support filter-based L2TP tunneling, the system writes a syslog warning message that the interface does not support the filter. The remote tunnel endpoint sends an IP tunnel packet that contains an Ethernet MAC address in the payload. If the destination MAC address of the payload packet contains the MAC address of the router, the Ethernet packet is sent in the outgoing direction towards the network, and it is processed and forwarded as though it is received on the customer port. If the source MAC address of the payload packet contains the MAC address of the router, the Ethernet packet is transmitted in the outgoing direction towards the customer port. If the tunnel does not contain the receive-cookie configured, packet injection does not happen. In such a case, any received tunnel packet is counted and dropped in the same manner in which packets that arrive with a wrong cookie are counted and dropped. The following parameters can be specified with the `decapsulate l2tp` action: `routing-instance instance-name`—By default, the Packet Forwarding Engine uses the default routing instance to forward payload packets to the destination network. If the payload is MPLS, the Packet Forwarding Engine performs route lookup on the MPLS path routing table using the route label in the MPLS header. If you specify the `decapsulate` action with an optional routing instance name, the Packet Forwarding Engine performs route lookup on the routing instance, and the instance must be configured. `forwarding-class class-name`—(Optional) Classify l2TP packets to the specified forwarding class. `output-interface interface-name`—(Optional) For L2TP tunnels, enable the packet to be duplicated and sent towards the customer or the network (based on the MAC address in the Ethernet payload). `cookie l2tpv3-cookie`—(Optional) For L2TP tunnels, specify the L2TP cookie for the duplicated packets. If the tunnel does not contain the receive-cookie configured, packet injection does not happen. In such a case, any received tunnel packet is counted and dropped in the same manner in which packets that arrive with a wrong cookie are counted and dropped. `sample`—(Optional) Sample the packet. Junos OS does not sample packets originating from the router. If you configure a filter and apply it to the output side of an interface, then only the transit packets going through that interface are sampled. Packets that are sent from the Routing Engine to the Packet Forwarding Engine are not sampled. Note: The `decapsulate l2tp` action that you configure at the `[edit firewall family inet filter filter-name term term-name]` hierarchy level does not process traffic with IPv4 and IPv6 options. As a result, traffic with such options is discarded by the de-encapsulation of L2TP packets functionality.	`family inet`
`discard`	Discard a packet silently, without sending an Internet Control Message Protocol (ICMP) message. Discarded packets are available for logging and sampling.	`family any` `family inet` `family inet6` `family mpls` `family vpls` `family ccc` `family bridge` `family ethernet-switching` (for EX Series switches only)
`encapsulate template-name`	At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable filter-based generic routing encapsulation (GRE) tunneling using the specified tunnel template. You can configure a filter term that pairs this action with the appropriate match conditions, and then attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches an encapsulating filter to an interface that does not support filter-based GRE tunneling, the system writes a syslog warning message that the interface does not support the filter. When the interface receives a matched packet, processes that run on the Packet Forwarding Engine use information in the specified tunnel template to perform the following operations: Attach a GRE header (with or without a tunnel key value, as specified in the tunnel template. Attach a header for the IPv4 transport protocol. Forward the resulting GRE packet from the tunnel source interface to the tunnel destination (the remote PE router). The specified tunnel template must be configured using the `tunnel-end-point` statement under the `[edit firewall]` or `[edit logical-systems logical-system-name firewall]` hierarchy level. For more information, see Understanding Filter-Based Tunneling Across IPv4 Networks.	`family inet` `family inet6` `family any` `family mpls`
`encapsulate template-name` (for L2TP tunnels)	At a customer-facing interface on an MX Series router installed at the provider edge (PE) of an IPv4 transport network, enable filter-based L2TP tunneling using the specified tunnel template. You can configure a filter term that pairs this action with the appropriate match conditions, and then attach the filter to the input of an Ethernet logical interface or aggregated Ethernet interface on a Modular Interface Card (MIC) or Modular Port Concentrator (MPC) in the router. If you commit a configuration that attaches an encapsulating filter to an interface that does not support filter-based GRE tunneling, the system writes a syslog warning message that the interface does not support the filter. When the interface receives a matched packet, processes that run on the Packet Forwarding Engine use information in the specified tunnel template to perform the following operations: Attach an L2TP header (with or without a tunnel key value, as specified in the tunnel template). Attach a header for the IPv4 transport protocol. Forward the resulting L2TP packet from the tunnel source interface to the tunnel destination (the remote PE router). The specified tunnel template must be configured using the `tunnel-end-point` statement under the `[edit firewall]` or `[edit logical-systems logical-system-name firewall]` statement hierarchy.	`family inet`
`exclude-accounting`	Exclude the packet from being included in accurate accounting statistics for tunneled subscribers on an L2TP LAC. Typically used in filters that match DHCPv6 or ICMPv6 control traffic Failure to exclude these packets results in the idle-timeout detection mechanism considering these packets as data traffic, causing the timeout to never expire. (The idle timeout is configured with the `client-idle-timeout` and `client-idle-timeout-ingress-only` statements in the access profile session options.) The term excludes packets from being included in counts for both family accurate accounting and service accurate accounting. The packets are still included in the session interface statistics. The term is available for both `inet` and `inet6` families, but is used only for `inet6`.	`family inet` `family inet6`
`logical-system logical-system-name`	Direct the packet to the specified logical system. Note: This action is not supported on PTX Series Packet Transport Routers.	`family inet` `family inet6`
`reject message-type`	Reject the packet and return an ICMPv4 or ICMPv6 message: If no `message-type` is specified, a `destination unreachable` message is returned by default. If `tcp-reset` is specified as the `message-type`, `tcp-reset` is returned only if the packet is a TCP packet. Otherwise, the `administratively-prohibited` message, which has a value of 13, is returned. If any other `message-type` is specified, that message is returned. Note: Rejected packets can be sampled or logged if you configure the `sample` or `syslog` action. For MX2K-MPC11E, ICMP reject messages traverse egress filters, policers, and class of service (CoS) configurations and so are included in those statistics. The same is true for `destination unreachable` messages. The `message-type` can be one of the following values: `address-unreachable`, `administratively-prohibited`, `bad-host-tos`, `bad-network-tos`, `beyond-scope`, `fragmentation-needed`, `host-prohibited`, `host-unknown`, `host-unreachable`, `network-prohibited`, `network-unknown`, `network-unreachable`, `no-route`, `port-unreachable`, `precedence-cutoff`, `precedence-violation`, `protocol-unreachable`, `source-host-isolated`, `source-route-failed`, or `tcp-reset`. On PTX1000 routers, the reject action is supported on ingress interfaces only.	`family inet` `family inet6`
`routing-instance instance-name`	Direct the packet to the specified routing instance.	`family inet` `family inet6`
`topology topology-name`	Direct the packet to the specified topology. Note: This action is not supported on PTX Series Packet Transport Routers. Each routing instance (primary or virtual-router) supports one default topology to which all forwarding classes are forwarded. For multitopology routing, you can configure a firewall filter on the ingress interface to match a specific forwarding class, such as expedited forwarding, with a specific topology. The traffic that matches the specified forwarding class is then added to the routing table for that topology.	`family inet` `family inet6`

Note:

On QFX5120-48Y and QFX5120-32C switch models, configure discard action explicitly to bring down a BFD session. However, note that if there is a port-mirror action configured before the discard action, then the BFD session will not be brought down.