Firewall Filter Match Conditions and Actions for EX Series Switches
Each term in a firewall filter consists of match conditions and an action. Match conditions are the values or fields that a packet must contain. You can define multiple, single, or no match conditions. If no match conditions are specified for the term, all packets are matched by default. The action is the action that the switch takes if a packet matches the match conditions for the specific term. Action modifiers are optional and specify one or more actions that the switch takes if a packet matches the match conditions for the specific term. Allowed actions are to accept a packet or discard a packet. In addition, you can specify action modifiers to count, mirror, rate limit, and classify packets.
For each firewall filter, you define the terms that specify the filtering criteria (match conditions) to apply to packets and the action for the switch to take if a match occurs. The string that defines a match condition is called a match statement. The following tables list various match conditions, their supported platforms, binding points, and actions.
- Table 1 describes the match conditions you can specify when configuring a firewall filter for IPv4 traffic.
- Table 2 describes the match conditions you can specify when configuring a firewall filter for IPv6 traffic.
- Table 3 shows the actions that you can specify in a term.
- Table 4 shows the action modifiers that you can specify in a term.
Table 1: Supported Match Conditions Applicable to IPv4 Traffic for Firewall Filters on EX Series Switches
Match Condition | Description | Supported Platforms and Bind Points | |
|---|---|---|---|
Ingress | Egress | ||
destination-address | IP destination address field, which is the address of the final destination node. |
|
|
destination-mac-address mac-address | Destination media access control (MAC) address of the packet. You can define a destination MAC address with a prefix, such as from destination-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value is taken as 48. |
|
|
destination-port number | TCP or User Datagram Protocol (UDP) destination port field. Typically, you specify this match in conjunction with the protocol match statement to determine which protocol is used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed): 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) | |||
destination-prefix-list prefix-list | IP destination prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent use. You make this definition at the [edit policy-options] hierarchy level. |
|
|
dot1q-tag number | The tag field in the Ethernet header. The tag values can be 1–4095. |
|
|
dot1q-user-priority number | User-priority field of the tagged Ethernet packet. User-priority values can be 0–7. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):
|
|
|
dscp number | Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal, binary, or decimal form. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):
|
|
|
ether-type [aarp | appletalk | arp | ipv4 | ipv6 | mpls—multicast | mpls-unicast | oam | ppp | pppoe-discovery | pppoe-session | sna |value] | Ethernet type field of a packet. The EtherType value specifies what protocol is being transported in the Ethernet frame. In place of the numeric value, you can specify one of the following text synonyms:
|
|
|
fragment-flags fragment-flags | IP fragmentation flags, specified in symbolic or hexadecimal formats. You can specify one of the following options: dont-fragment (0x4000), more-fragments (0x2000), or reserved (0x8000) |
|
|
icmp-code number | ICMP code field. This value or option provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type, you must specify icmp-type along with icmp-code. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The options are grouped by the ICMP type with which they are associated:
|
|
|
icmp-type number | ICMP packet type field. Typically, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. 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), unreachable (3) |
|
|
interface interface-name | Interface on which the packet is received. You can specify the wildcard character (*) as part of an interface name. |
|
|
ip-options | Presence of the options field in the IP header. |
|
|
is-fragment | If the packet is a trailing fragment, this match condition does not match the first fragment of a fragmented packet. Use two terms to match both first and trailing fragments. |
|
|
next-header bytes | 8-bit protocol field that identifies the type of header immediately following the IPv6 header. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmpv6 (1), igmp (2), ipip (4), ipv6 (41), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112). |
|
|
precedence precedence | IP precedence. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): critical-ecp (5), flash (3), flash-override (4), immediate (2), internet-control (6), net-control (7), priority (1), or routine (0). |
|
|
protocol list of protocols | IPv4 protocol value. In place of the numeric value, you can specify one of the following text synonyms: egp (8), esp (50), gre (47), icmp (1), igmp (2), ipip (4), ospf (89), pim (103), rsvp (46), tcp (6), udp (17) |
|
|
source-address | IP source address field, which is the address of the source node sending the packet. For IPV6, the source-address field is 128 bits in length. The filter description syntax supports the text representations for IPv6 addresses that are described in RFC 2373, IP Version 6 Addressing Architecture. |
|
|
source-mac-address mac-address | Source MAC address. You can define a source MAC address with a prefix, such as from destination-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value is taken as 48. |
|
|
source-port number | TCP or UDP source-port field. Typically, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. In place of the numeric field, you can specify one of the text synonyms listed under destination-port. |
|
|
source-prefix-list prefix-list | IP source prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent use. You make this definition at the [edit policy-options] hierarchy level. |
|
|
tcp-established | TCP packets of an established TCP connection. This condition matches packets other than the first packet of a connection. tcp-established is a synonym for the bit names "(ack | rst)". tcp-established does not implicitly check whether the protocol is TCP. To do so, specify the protocol tcp match condition. |
|
|
tcp-flags [flags tcp-initial] | One or more TCP flags:
To specify multiple flags, use logical operators. |
|
|
tcp-initial | Match the first TCP packet of a connection. tcp-initial is a synonym for the bit names "(syn & !ack)". tcp-initial does not implicitly check whether the protocol is TCP. To do so, specify the protocol tcp match condition. |
|
|
traffic-class | Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal, binary, or decimal form. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):
|
|
|
ttl value | TTL type to match. The value can be 1–255. |
|
|
vlan [vlan-name | vlan-id] | The VLAN that is associated with the packet. |
|
|
Some of the numeric range and bit-field match conditions allow you to specify a text synonym. For a list of all the synonyms for a match condition, do any of the following:
- If you are using the J-Web Filters Configuration page, select the synonym from the appropriate list.
- If you are using the CLI, type a question mark (?) after the from statement.
To specify the bit-field value to match, you must enclose the values in quotation marks (" "). For example, a match occurs if the RST bit in the TCP flags field is set:
For information about logical operators and how to use bit-field logical operations to create expressions that are evaluated for matches, see Understanding Firewall Filter Match Conditions.
On Juniper Networks EX Series Ethernet switches, you can apply a router firewall filter to both IPv4 and IPv6 traffic. You can apply firewall filter match conditions to IPv6 traffic on Layer 3 interfaces, aggregated Ethernet interfaces, and loopback interfaces. Table 2 describes the match conditions you can specify when configuring a firewall filter for IPv6 traffic.
Table 2: Supported Match Conditions Applicable to IPv6 Traffic for Firewall Filters on EX Series Switches
Match Condition | Description | Supported Platforms and Bind Points | |
|---|---|---|---|
Ingress | Egress | ||
destination-address | Specifies the 128-bit address that is the final destination node address for the packet. The filter description syntax supports the text representations for IPv6 addresses as described in RFC 2373, IP Version6 Addressing Architecture. |
|
|
destination-mac-address mac-address | Destination media access control (MAC) address of the packet. You can define a destination MAC address with a prefix, such as from destination-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value is taken as 48. |
|
|
destination-port number | Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) destination port field. Typically, you specify this match in conjunction with the protocol match statement to determine which protocol is used on the port. In place of the numeric value, you can specify one of the following text synonyms (the port numbers are also listed): 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) | |||
destination-prefix-list prefix-list | IP destination prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent use. You make this definition at the [edit policy-options] hierarchy level. |
|
|
dot1q-tag number | The tag field in the Ethernet header. The tag values can be 1–4095. |
|
|
dot1q-user-priority number | User-priority field of the tagged Ethernet packet. User-priority values can be 0–7. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):
|
|
|
ether-type (ipv6)value | Ethernet type field of a packet. The EtherType value specifies what protocol is being transported in the Ethernet frame. In place of the numeric value, you can specify the following text synonym:
|
|
|
icmp-code number | ICMP code field. This value or option provides more specific information than icmp-type. Because the value’s meaning depends upon the associated icmp-type, you must specify icmp-type along with icmp-code. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed). The options are grouped by the ICMP type with which they are associated:
|
|
|
icmp-type number | ICMP packet type field. Typically, you specify this match in conjunction with the protocol match statement to determine which protocol is being used on the port. 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), unreachable (3) |
|
|
interface interface-name | Interface on which the packet is received. |
|
|
next-header bytes | 8-bit protocol field that identifies the type of header immediately following the IPv6 header. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed): ah (51), dstops (60), egp (8), esp (50), fragment (44), gre (47), hop-by-hop (0), icmp (1), icmpv6 (1), igmp (2), ipip (4), ipv6 (41), no-next-header (59), ospf (89), pim (103), routing (43), rsvp (46), sctp (132), tcp (6), udp (17), or vrrp (112). |
|
|
packet-length bytes | Length of the received packet, in bytes. The length refers only to the IP packet, including the packet header, and does not include any Layer 2 encapsulation overhead. |
|
|
source-address | IP source address field, which is 128 bits in length. The filter description syntax supports the text representations for IPv6 addresses that are described in RFC 2373, IP Version 6 Addressing Architecture. |
|
|
source-mac-address mac-address | Source MAC address. You can define a source MAC address with a prefix, such as from destination-mac-address 00:01:02:03:04:05/24. If no prefix is specified, the default value is taken as 48. |
|
|
source-port number | TCP or UDP source-port field. Typically, you specify this match in conjunction with the next-header match statement to determine which next-header is being used on the port. In place of the numeric field, you can specify one of the text synonyms listed under destination-port. |
|
|
source-prefix-list prefix-list | IP source prefix list field. You can define a list of IP address prefixes under a prefix-list alias for frequent use. You make this definition at the [edit policy-options] hierarchy level. |
|
|
tcp-flags (flags tcp-initial) | One or more TCP flags:
To specify multiple flags, use logical operators. |
|
|
tcp-initial | Match the first TCP packet of a connection. tcp-initial is a synonym for the bit names "(syn & !ack)". tcp-initial does not implicitly check whether the protocol is TCP. To do so, specify the protocol tcp match condition. |
|
|
traffic-class number | Differentiated Services code point (DSCP). The DiffServ protocol uses the type-of-service (ToS) byte in the IP header. The most significant six bits of this byte form the DSCP. You can specify DSCP in hexadecimal, binary, or decimal form. In place of the numeric value, you can specify one of the following text synonyms (the field values are also listed):
|
|
|
vlan (vlan-id | vlan-name) | The VLAN that is associated with the packet. |
|
|
When you define one or more terms that specify the filtering criteria, you also define the action to take if the packet matches all criteria.
Table 3: Actions for Firewall Filters
Action | Description | Supported Platforms and Direction |
|---|---|---|
accept | Accept a packet. |
|
discard | Discard a packet silently without sending an Internet Control Message Protocol (ICMP) message. |
|
reject message-type | Discard a packet, and send an ICMPv4 message (type 3) “destination unreachable”. You can log the rejected packets if you configure the syslog action modifier. You can specify one of the following message codes: administratively-prohibited (default), bad-host-tos, bad-network-tos, host-prohibited, host-unknown, host-unreachable, network-prohibited, network-unknown, network-unreachable, port-unreachable, precedence-cutoff, precedence-violation, protocol-unreachable, source-host-isolated, source-route-failed, or tcp-reset. If you specify tcp-reset, a TCP reset is returned if the packet is a TCP packet. Otherwise nothing is returned. If you do not specify a message type, the ICMP notification “destination unreachable” is sent with the default message “communication administratively filtered”. Note: reject is not a supported action for IPv6 traffic. |
|
routing-instance routing-instance-name | Forward matched packets to a virtual routing instance. |
|
vlan vlan-name | Forward matched packets to a specific VLAN. Note: vlan is not a supported action for IPv6 traffic. |
|
In addition to the actions, you can specify action modifiers.
Table 4: Action Modifiers for Firewall Filters
Action Modifier | Description | Supported Platforms and Direction |
|---|---|---|
analyzer analyzer-name | Mirror port traffic to a specified destination port or VLAN that is connected to a protocol analyzer application. Mirroring copies all packets seen on one switch port to a network monitoring connection on another switch port. The analyzer name must be configured under [edit ethernet-switching-options analyzer]. |
|
count counter-name | Count the number of packets that pass this filter, term, or policer. |
|
forwarding-class class | Classify the packet in one of the following forwarding classes:
|
|
interface interface-name | Forward the traffic to the specified interface bypassing the switching lookup. |
|
log | Log the packet's header information in the Routing Engine. To view this information, issue the show firewall log command in the CLI. Note: log is not a supported action modifier for IPv6 traffic. |
|
loss-priority (high | low) | Set the packet loss priority (PLP). |
|
policer policer-name | Apply rate limits to the traffic. You can specify a policer for ingress port, VLAN, and router firewall filters only. |
|
syslog | Log an alert for this packet. You can specify that the log be sent to a server for storage and analysis. Note: syslog is not a supported action modifier for IPv6 traffic. |
|
![]() | Note: On EX Series switches, accept and discard in the ingress direction, are the only actions supported for firewall filters applied on loopback interfaces. |
Related Topics
- Firewall Filter Configuration Statements Supported by Junos OS for EX Series Switches
- Example: Configuring Firewall Filters for Port, VLAN, and Router Traffic on EX Series Switches
- Example: Using Filter-Based Forwarding to Route Application Traffic to a Security Device on EX Series Switches
- Understanding Firewall Filter Match Conditions
- Understanding How Firewall Filters Are Evaluated
- Understanding How Firewall Filters Test a Packet's Protocol
- Understanding the Use of Policers in Firewall Filters
- Understanding Filter-Based Forwarding for EX Series Switches

