- Related Topics
- Firewall Filter Configuration Statements Supported by JUNOS Software 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
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. Allowed actions are 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. Table 1 describes the match conditions you can specify when configuring a firewall filter.
Table 1: Supported Match Conditions 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. For IPv6, 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. |
|
|
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. Note: An interface from which a packet is sent cannot be used as a match condition. |
|
|
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. |
|
|
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.
All match conditions are applicable to IPv4 traffic.
On EX3200 and EX4200 switches, you can apply match conditions to IPv6 traffic on Layer 3 interfaces, aggregated Ethernet interfaces, and loopback interfaces. The following are the match conditions applicable to IPv6 trafic:
- destination-address
- destination-port
- destination-prefix-list
- icmp-code
- icmp-type
- interface
- next-header
- packet-length
- source-address
- source-port
- source-prefix-list
- tcp-established
- tcp-flags
- tcp-initial
- traffic-class
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 2 shows the actions that you can specify in a term.
Table 2: 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 3 shows the action modifers that you can specify in a term.
Table 3: 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. Note: interface is not a supported action modifier for IPv6 traffic. |
|
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 are the only actions supported for firewall filters applied on loopback interfaces. |
