2015, Brocade Communications Systems, Inc. All Rights Reserved.
ADX, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, HyperEdge, ICX, MLX, MyBrocade, OpenScript, The Effortless
Network, VCS, VDX, Vplane, and Vyatta are registered trademarks, and Fabric Vision and vADX are trademarks of Brocade
Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be
trademarks of others.
Notice: This document is for informational purposes only and does not set forth any warranty, expressed or implied, concerning any
equipment, equipment feature, or service offered or to be offered by Brocade. Brocade reserves the right to make changes to this document
at any time, without notice, and assumes no responsibility for its use. This informational document describes features that may not be
currently available. Contact a Brocade sales office for information on feature and product availability. Export of technical data contained in
this document may require an export license from the United States government.
The authors and Brocade Communications Systems, Inc. assume no liability or responsibility to any person or entity with respect to the
accuracy of this document or any loss, cost, liability, or damages arising from the information contained herein or the computer programs that
accompany it.
The product described by this document may contain open source software covered by the GNU General Public License or other open
source license agreements. To find out which open source software is included in Brocade products, view the licensing terms applicable to
the open source software, and obtain a copy of the programming source code, please visit http://www.brocade.com/support/oscd.
The document conventions describe text formatting conventions, command syntax conventions, and
important notice formats used in Brocade technical documentation.
Text formatting conventions
Text formatting conventions such as boldface, italic, or Courier font may be used in the flow of the text
to highlight specific words or phrases.
Format
bold text
italic text
Courier font
Description
Identifies command names
Identifies keywords and operands
Identifies the names of user-manipulated GUI elements
Identifies text to enter at the GUI
Identifies emphasis
Identifies variables
Identifies document titles
Identifies CLI output
Identifies command syntax examples
Command syntax conventions
Bold and italic text identify command syntax components. Delimiters and operators define groupings of
parameters and their logical relationships.
Convention
bold textIdentifies command names, keywords, and command options.
italic textIdentifies a variable.
valueIn Fibre Channel products, a fixed value provided as input to a command
Description
option is printed in plain text, for example, --show WWN.
[ ]Syntax components displayed within square brackets are optional.
Default responses to system prompts are enclosed in square brackets.
{ x | y | z }A choice of required parameters is enclosed in curly brackets separated by
x | yA vertical bar separates mutually exclusive elements.
< >Nonprinting characters, for example, passwords, are enclosed in angle
...
\
vertical bars. You must select one of the options.
In Fibre Channel products, square brackets may be used instead for this
purpose.
brackets.
Repeat the previous element, for example, member[member...].
Indicates a “soft” line break in command examples. If a backslash separates
two lines of a command input, enter the entire command at the prompt without
the backslash.
Notes, cautions, and warnings
Notes, cautions, and warning statements may be used in this document. They are listed in the order of
increasing severity of potential hazards.
NOTE
A Note provides a tip, guidance, or advice, emphasizes important information, or provides a reference
to related information.
ATTENTION
An Attention statement indicates a stronger note, for example, to alert you when traffic might be
interrupted or the device might reboot.
CAUTION
A Caution statement alerts you to situations that can be potentially hazardous to you or cause
damage to hardware, firmware, software, or data.
DANGER
A Danger statement indicates conditions or situations that can be potentially lethal or
extremely hazardous to you. Safety labels are also attached directly to products to warn of
these conditions or situations.
8Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Brocade resources
Visit the Brocade website to locate related documentation for your product and additional Brocade
resources.
You can download additional publications supporting your product at www.brocade.com. Select the
Brocade Products tab to locate your product, then click the Brocade product name or image to open the
individual product page. The user manuals are available in the resources module at the bottom of the
page under the Documentation category.
To get up-to-the-minute information on Brocade products and resources, go to MyBrocade. You can
register at no cost to obtain a user ID and password.
Release notes are available on MyBrocade under Product Downloads.
White papers, online demonstrations, and data sheets are available through the Brocade website.
Contacting Brocade Technical Support
Brocade resources
As a Brocade customer, you can contact Brocade Technical Support 24x7 online, by telephone, or by email. Brocade OEM customers contact their OEM/Solutions provider.
Brocade customers
For product support information and the latest information on contacting the Technical Assistance
Center, go to http://www.brocade.com/services-support/index.html.
If you have purchased Brocade product support directly from Brocade, use one of the following methods
to contact the Brocade Technical Assistance Center 24x7.
OnlineTelephoneE-mail
Preferred method of contact for nonurgent issues:
• My Cases through MyBrocade
• Software downloads and licensing
tools
• Knowledge Base
Required for Sev 1-Critical and Sev
2-High issues:
• Continental US: 1-800-752-8061
• Europe, Middle East, Africa, and
Asia Pacific: +800-AT FIBREE
(+800 28 34 27 33)
• For areas unable to access toll
free number: +1-408-333-6061
• Toll-free numbers are available in
many countries.
support@brocade.com
Please include:
• Problem summary
• Serial number
• Installation details
• Environment description
Brocade OEM customers
If you have purchased Brocade product support from a Brocade OEM/Solution Provider, contact your
OEM/Solution Provider for all of your product support needs.
• OEM/Solution Providers are trained and certified by Brocade to support Brocade® products.
• Brocade provides backline support for issues that cannot be resolved by the OEM/Solution Provider.
• Brocade Supplemental Support augments your existing OEM support contract, providing direct
access to Brocade expertise. For more information, contact Brocade or your OEM.
• For questions regarding service levels and response times, contact your OEM/Solution Provider.
Document feedback
To send feedback and report errors in the documentation you can use the feedback form posted with
the document or you can e-mail the documentation team.
Quality is our first concern at Brocade and we have made every effort to ensure the accuracy and
completeness of this document. However, if you find an error or an omission, or you think that a topic
needs further development, we want to hear from you. You can provide feedback in two ways:
• Through the online feedback form in the HTML documents posted on www.brocade.com.
• By sending your feedback to documentation@brocade.com.
Provide the publication title, part number, and as much detail as possible, including the topic heading
and page number if applicable, as well as your suggestions for improvement.
10Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
About This Guide
This guide describes firewall functionality on the Brocade 5600 vRouter (referred to as a virtual router,
vRouter, or router in the guide).
Firewall functionality analyzes and filters IP packets between network interfaces. The most common
application of this functionality is to protect traffic between an internal network and the Internet. It allows
you to filter packets based on their characteristics and perform actions on packets that match the rule.
The Brocade vRouter firewall functionality provides the following features:
• Packet filtering for traffic that traverses the router by using the in and out keywords on an interface
• Definable criteria for packet-matching rules, including source IP address, destination IP address,
source port, destination port, IP protocol, and Internet Control Message Protocol (ICMP) type
• General detection on IP options, such as source routing and broadcast packets
• Ability to set the firewall globally for stateful or stateless operation
The vRouter firewall offers both IPv4 and IPv6 stateful packet inspection to intercept and inspect
network activity and to allow or deny the attempt. The advanced firewall capabilities from the vRouter
include stateful failover.
Firewall cannot be applied to outbound local traffic. It can only be applied to inbound interface traffic and
forwarded outbound traffic.
Firewall and fragmented packets
As per RFC 6192, fragments destined to the local CPU are dropped by the dataplane. To avoid having
allowed CPU-bound fragments from being dropped, a firewall rule must be configured to allow them
through the interface so that the fragments can be reassembled.
If neither firewall nor NAT is configured, packet fragments are not inspected and are forwarded
unchanged. However, in accordance with RFC 6192, any fragments that are destined to a router local
address are dropped.
An input firewall allows fragments to be reassembled. For both IPv4 and IPv6, if the packets arrive on
an interface for which firewall is configured, the fragments are reassembled at input before passing to
the firewall. If all the fragments of a packet are not received, then the packet is dropped. The
reassembled packet passes through the remainder of the forwarding path and firewall does not
recognize fragments at either input or output. At output, the packet is refragmented, if necessary. This
behavior also applies to a packet arriving on an interface that is assigned to a firewall zone.
When fragmented packets arrive on an interface without a firewall configured and exits on an interface
with an output firewall configured, the fragmented packets are not inspected for L4 (TCP, UDP, ICMP,
or GRE) information; however, the firewall rules recognize them as fragments. Because the system
does not process L4 information, a session for this packet is not found or created. Therefore, any
return packets that are associated with this fragment flow cannot match a session and, when in the
stateful state, might be dropped.
RSVP packets are sent hop-by-hop and since they can be large, they would benefit from being
fragmented. The following commands can ensure that an RSVP is responded to.
vyatta@R1# set security firewall name RSVP rule 10 action accept
vyatta@R1# set security firewall name RSVP rule 10 protocol rsvp
Defining firewall instances
Firewalls filter packets on interfaces. Use of the firewall feature has two steps:
1. Define a firewall instance and save it under a name. A firewall instance is also called a firewall rule
set, where a rule set is just a series of firewall rules. You define the firewall instance and configure
the rules in its rule set in the firewall configuration node.
2. Apply the instance to an interface or a zone by configuring the interface configuration node for the
interface or zone. After the instance is applied to the interface or zone, the rules in the instance
begin filtering packets on that location.
Firewall rules
Firewall rules specify the match conditions for traffic and the action to be taken if the match conditions
are satisfied. Traffic can be matched on a number of characteristics, including source IP address,
destination IP address, source port, destination port, IP protocol, and ICMP type.
Rules are executed in numeric sequence, according to the rule number, from lowest to highest. If the
traffic matches the characteristics specified by a rule, the action of the rule is executed; if not, the
system “falls through” to the next rule.
The action can be one of the following:
• Accept: Traffic is allowed and forwarded.
• Drop: Traffic is silently discarded.
To avoid having to renumber firewall rules, a good practice is to number rules in increments of 10. This
increment allows room for the insertion of new rules within the rule set.
Implicit drop
All firewall rule sets on the vRouter have, by default, an implicit final action of “drop all”; that is, traffic
not matching any rule in the rule set is silently discarded. This default action can be changed by using
security firewall name <name> default-action <action> on page 47.
Exclusion rules
Note that you should take care in employing more than one “exclusion” rule, that is, a rule that uses
the negation operator (exclamation mark [!]) to exclude a rule from treatment. Rules are evaluated
sequentially, and a sequence of exclusion rules could result in unexpected behavior.
14Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Stateful firewall and connection tracking
The vRouter CLI interacts with the Connection Tracking System, a module that provides connection
tracking for various system functions, such as firewall and Network Address Translation (NAT). On the
firewall, connection tracking allows for stateful packet inspection.
Stateless firewalls filter packets in isolation, is based on static source and destination information. In
contrast, stateful firewalls track the state of network connections and traffic flows and allow or restrict
traffic based on whether its connection state is known and authorized. For example, when an initiation
flow is allowed in one direction, the responder flow is automatically and implicitly allowed in the return
direction. While typically slower under heavy load than stateless firewalls, stateful firewalls are better at
blocking unauthorized communication.
By default, the vRouter firewall is stateless. If you want the firewall to operate stateless in general, you
can configure state rules within a specific rule set. Alternatively, you can configure the firewall globally
to operate statefully.
Global state policies that are configured apply to all IPv4 and IPv6 traffic destined for, originating from,
or traversing the router. In addition, after they have been configured, global state policies override any
state rules configured within the rule set.
Stateful firewall and connection tracking
TCP strict tracking
The TCP strict tracking of stateful firewall rules for traffic can be enabled by using security firewall tcp-
strict on page 74. This command also enables the user to toggle between loose or strict stateful
behaviors for TCP.
Stateful tracking must be enabled through either a state rule or global rule. When firewall is globally
stateful, policies for established, related, and invalid traffic must be defined.
Under the stateful policy, firewall tracks the state of network connections and traffic flows, and allows or
restricts traffic based on whether the connection state is known and authorized. For example, when an
initiation flow is allowed in one direction, stateful firewall automatically allows responder flows in the
return direction.
The statefulness policy applies to all IPv4 and IPv6 traffic that is destined for, originating from, or
traversing the router. In firewall, global statefulness overrides any state rules configured within rule sets.
TCP strict tracking disabled—The firewall is stateless and the rules governing statefulness must be
configured through the rule set.
TCP connections are validated by the following criteria:
Perform SEQ/ACK numbers check against boundaries. (Reference: Rooij G., “Real stateful TCP packet
filtering in IP Filter,” 10th USENIX Security Symposium invited talk, Aug. 2001.)
The four boundaries are defined as follows:
• I) SEQ + LEN <= MAX {SND.ACK + MAX(SND.WIN, 1)}\
TCP strict tracking enabled—The above validation is performed. In addition, the validation against the
correct TCP sequencing of flags (or validation of TCP stateful transitions) is also performed.
The following stateful transitions are invalid when a packet is received with the following flag pattern:
SYN-ACK FLAG to SS, ES, FW, CW, LA, TW, CL FIN FLAG to SS, SR, S2 ACK FLAG to SS, S2
NOTE
S2 is an identical SYN sent from either side of the connection.
Reverse flow:
SYN FLAG to SR, ES, FW, CW, LA, TW, CL
FIN FLAG to SS, SR
Keys to the codes above are as follows:
vyatta@vyatta:~$ show session-table
TCP state codes: SS - SYN SENT, SR - SYN RECEIVED, ES - ESTABLISHED,
FW - FIN WAIT, CW - CLOSE WAIT, LA - LAST ACK,
TW - TIME WAIT, CL - CLOSE, LI - LISTEN
Applying firewall instances to interfaces
Once a firewall instance has been defined, it can be applied to an interface, where the instance acts
as a packet filter. The firewall instance filters packets in one of the following ways, depending on what
you specify when you apply the firewall instance:
• in: If you apply the instance as in, the firewall filters packets entering the interface and traversing
the vRouter. You can apply one firewall instance as an in packet filter.
• out: If you apply the instance as out, the firewall filters packets leaving the interface. These packets
can be traversing the vRouter or originating on the vRouter. You can apply one firewall instance as
an out packet filter.
Firewall instances can be applied to an interface: one instance as an in filter, one instance as an out
filter, and one instance as a filter.
Interaction between firewall, NAT, and routing
The processing order of the various services that might be configured within the vRouter is one of the
most important concepts to understand when working with firewall functionality. If the processing order
of the services is not carefully configured, the results achieved might not be what you expect.
Traffic flow through firewall, NAT, and routing
The following figure shows how traffic flows through the firewall, NAT, and routing services within the
vRouter. Notice the order of firewall instances, destination Network Address Translation (DNAT),
routing decisions, and source Network Address Translation (SNAT).
16Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Scenario 1: firewall instances applied to inbound traffic
FIGURE 1 Traffic flow through firewall, NAT, and routing components
Scenario 1: firewall instances applied to inbound traffic
In this scenario, firewall instances are applied to inbound (in) traffic on an interface. Notice that firewall
instances are evaluated before DNAT and routing decisions, and after SNAT.
Scenario 2: firewall instances applied to outbound traffic
In this scenario, firewall instances are applied to outbound (out ) traffic on an interface. Notice that
firewall is evaluated after DNAT and routing decisions, and after SNAT.
Zone-based firewall
Ordinary firewall rule sets are applied on a per-interface basis to act as a packet filter for the interface.
In a zone-based firewall, interfaces are grouped into security “zones,” where each interface in a zone
has the same security level.
Packet-filtering policies are applied to traffic flowing between zones. Traffic flowing between interfaces
that lie in the same zone is not filtered and flows freely because the interfaces share the same security
level.
The following figure shows an example of a zone-based firewall implementation. This example has
these characteristics:
• Three transit zones exist (that is, points where traffic transits the router): the private zone, the
demilitarized zone (DMZ), and the public zone.
• The dp0p1p4 interface lies in the public zone; the dp0p1p1 and dp0p1p2 interfaces lie in the private
zone; and the dp0p1p3 interface lies in the DMZ.
• The arrows from one zone to another zone represent traffic-filtering policies that are applied to traffic
flowing between zones.
• Traffic flowing between LAN 1 and LAN 2 remains within a single security zone. Thus, traffic from
LAN1 to LAN2, and conversely, flows unfiltered.
By default, all traffic coming into the router and originating from the router is allowed.
Note the following additional points about zone-based firewalls:
• An interface can be associated with only one zone.
• An interface that belongs to a zone cannot have a per-interface firewall rule set applied to it, and
conversely.
• Traffic between interfaces that do not belong to any zone flows unfiltered, and per-interface firewall
rule sets can be applied to those interfaces.
• By default, all traffic to a zone is dropped unless explicitly allowed by a filtering policy for a source
zone (from_zone) .
• Filtering policies are unidirectional; they are defined as a “zone pair” that identifies the zone from
which traffic is sourced (from_zone ) and the zone to which traffic is destined (to_zone ). In the
preceding figure, these unidirectional policies can be seen as follows:
‐ From private to DMZ
‐ From public to DMZ
‐ From private to public
‐ From DMZ to public
‐ From public to private
‐ From DMZ to private
This section describes a sample configuration for firewall. When you have finished, the firewall is
configured on the R1 router, as shown in the following figure.
FIGURE 3 Firewall: sample configuration
This section includes the following examples:
• Filtering on source IP address on page 20
• Filtering on source and destination IP addresses on page 20
• Filtering on source IP address and destination protocol on page 21
• Configuring stateful behavior per rule set on page 27
Filtering on source IP address
The following figure shows how to define a firewall instance that contains one rule, which filters
packets only on source IP address. This rule denies packets coming from the R2 router. It then applies
the firewall instance to packets inbound on the dp0p1p1 interface.
To create an instance that filters on source IP address, perform the following steps in configuration
mode.
Filtering on source IPTABLE 1
StepCommand
Create the configuration node for the FWTEST-1 firewall
instance and its rule 1. This rule matches fragmented packets.
Define the action of this rule.
Define a rule that filters traffic on the 176.16.0.26 source IP
address.
Apply FWTEST-1 to inbound packets on dp0p1p1.
Commit the configuration.
Show the configuration.
Filtering on source and destination IP addresses
vyatta@R1# set security firewall name FWTEST-1 rule 1
fragment
vyatta@R1# set security firewall name FWTEST-1 rule 1
action accept
vyatta@R1# set security firewall name FWTEST-1 rule 1
source address 172.16.0.26
vyatta@R1# set interfaces dataplane dp0p1p1 firewall in
FWTEST-1
vyatta@R1# commit
vyatta@R1# show security firewall name FWTEST-1
rule 1 {
action accept
source {
address 172.16.0.26
}
}
vyatta@R1# show interfaces dataplane dp0p1p1
address 172.16.1.1/24
firewall FWTEST-1 {
in {
}
}
The following example shows how to define another firewall instance. This instance contains one rule,
which filters packets on both source and destination IP addresses. The rule accepts packets leaving
R5 through dp0p1p2 using 10.10.30.46 and destined for 10.10.40.101. It then applies the firewall
instance to packets outbound from the 1 virtual interface (vif 1) on the dp0p1p2 interface.
To create an instance that filters on source and destination IP addresses, perform the following steps
in configuration mode.
20Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Filtering on source and destination IPTABLE 2
StepCommand
Filtering on source IP address and destination protocol
Create the configuration node for the FWTEST-2 firewall
instance and its rule 1. This rule accepts traffic matching the
specified criteria.
Define a rule that filters traffic on the 10.10.30.46 source IP
address.
Define a rule that filters traffic on the 10.10.40.101 destination IP
address.
Apply FWTEST-2 to outbound packets on dp0p1p2 vif 40.
Commit the configuration.
Show the configuration.
vyatta@R1# set security firewall name FWTEST-2 rule 1
action accept
vyatta@R1# set security firewall name FWTEST-2 rule 1
source address 10.10.30.46
vyatta@R1# set security firewall name FWTEST-2 rule 1
destination address 10.10.40.101
vyatta@R1# set interfaces dataplane dp0p1p2 vif 40
firewall out FWTEST-2
Filtering on source IP address and destination protocol
The following example shows how to define a firewall rule that filters on source IP address and
destination protocol. This rule allows TCP packets originating from address 10.10.30.46 (that is, R5),
and destined for the Telnet port of R1. The instance is applied to local packets (that is, packets destined
for this router, R1) through the dp0p1p2 interface.
To create a instance that filters on source IP address and destination protocol, perform the following
steps in configuration mode.
Filtering on source IP and destination protocolTABLE 3
StepCommand
Create the configuration node for the FWTEST-3 firewall instance
and its rule 1. This rule accepts traffic matching the specified
criteria.
Define a rule that filters traffic on the 10.10.30.46 source IP
address.
Define a rule that filters TCP traffic.
Define a rule that filters traffic destined for the Telnet service.
vyatta@R1# set security firewall name FWTEST-3 rule 1
action accept
vyatta@R1# set security firewall name FWTEST-3 rule 1
source address 10.10.30.46
vyatta@R1# set security firewall name FWTEST-3 rule 1
protocol tcp
vyatta@R1# set security firewall name FWTEST-3 rule 1
destination port telnet
Filtering on source IP and destination protocol (Continued)TABLE 3
StepCommand
Apply FWTEST-3 to packets bound for this router arriving on
dp0p1p2.
Commit the configuration.
Show the configuration.
Defining a network-to-network filter
The following example shows how to define a network-to-network packet filter, allowing packets
originating from 10.10.40.0/24 and destined for 172.16.0.0/24. It then applies the firewall instance to
packets inbound through the 40 virtual interface (vif 40) and the dp0p1p2 interface.
To create a network-to-network filter, perform the following steps in configuration mode.
vyatta@R1# set interfaces dataplane dp0p1p2 firewall
in FWTEST-3
The following example shows how to define a firewall instance that contains one rule, which filters
packets only on source medium access control (MAC) address. This rule allows packets coming from a
specific computer, identified by its MAC address rather than its IP address. The instance is applied to
packets inbound on the dp0p1p1 interface.
To create an instance that filters on source MAC address, perform the following steps in configuration
mode.
Filtering on source MAC addressTABLE 5
StepCommand
Create the configuration node for the FWTEST-5 firewall
instance and its rule 1. This rule accepts traffic matching the
specified criteria.
Define a rule that filters traffic with the 00:13:ce:29:be:e7
source MAC address.
Apply FWTEST-5 to inbound packets on dp0p1p1.
Commit the configuration.
Show the configuration.
vyatta@R1# set security firewall name FWTEST-5 rule 1
action accept
vyatta@R1# set security firewall name FWTEST-5 rule 1
source mac-address 00:13:ce:29:be:e7
vyatta@R1# set interfaces dataplane dp0p1p1 firewall in
FWTEST-5
The firewall rule shown in the following example allows all traffic from the 172.16.1.0/24 network
except traffic to the 192.168.1.100 server.
FIGURE 4 Excluding an address
To create an instance that excludes an address, perform the following steps in configuration mode.
Excluding an addressTABLE 6
StepCommand
Create the configuration node for the FWTEST-5 firewall
instance and its rule 10. Give a description for the rule.
Allow all traffic that matches the rule to be accepted.
Allow any traffic from the 172.16.1.0/24 network that
matches the rule.
Allow traffic destined anywhere except the 192.168.1.100
destination address that matches the rule.
Apply the NEGATED-EXAMPLE instance to inbound
packets on dp0p1p1.
Commit the configuration.
vyatta@R1# set security firewall name NEGATED-EXAMPLE
rule 10 description "Allow all traffic from LAN except to
server 192.168.1.100"
vyatta@R1# set security firewall name NEGATED-EXAMPLE
rule 10 action accept
vyatta@R1# set security firewall name NEGATED-EXAMPLE
rule 10 source address 172.16.1.0/24
vyatta@R1# set security firewall name NEGATED-EXAMPLE
rule 10 destination address !192.168.1.100
vyatta@R1#
set interfaces dataplane dp0p1p1 firewall in NEGATEDEXAMPLE
vyatta@R1# commit
24Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Excluding an address (Continued)TABLE 6
StepCommand
Matching TCP flags
Show the configuration.
Accepting packets with specific TCP flags setTABLE 7
vyatta@R1# show security firewall
name NEGATED-EXAMPLE {
rule 10 {
action accept
description "Allow all traffic from LAN except to
server 192.168.1.100"
destination {
address !192.168.1.100
}
source {
address 172.16.1.0/24
}
}
}
vyatta@R1# show interfaces dataplane dp0p1p1
address 172.16.1.1/24
firewall {
in NEGATED-EXAMPLE
}
Matching TCP flags
The vRouter supports filtering on the TCP flags within TCP packets. For example, to create a rule to
accept packets with the SYN flag set and the ACK, FIN, and RST flags unset, perform the following
steps in configuration mode.
StepCommand
Set the protocol to match to TCP.
Set the TCP flags to match.
Set the action to accept.
Commit the configuration.
Show the configuration.
vyatta@R1# set security firewall name TCP-FLAGS rule 30 protocol tcp
vyatta@R1# set security firewall name TCP-FLAGS rule 30 tcp flags SYN,!ACK,!
FIN,!RST
vyatta@R1# set security firewall name TCP-FLAGS rule 30 action accept
Packets can be filtered for ICMP type names. For example, to create a rule that allows only ICMP echo
request packets, perform the following steps in configuration mode.
Accepting ICMP packets with specific type namesTABLE 8
StepCommand
Set the protocol to match to ICMP.
Set the ICMP packet type to match.
Set the action to accept.
Commit the configuration.
Show the configuration.
Matching groups
Groups of addresses, ports, and networks can be defined for similar filtering. For example, to create a
rule that rejects traffic to a group of addresses and ports and from a group of networks, perform the
following steps in configuration mode.
Rejecting traffic based on groups of addresses, networks, and portsTABLE 9
vyatta@R1# set security firewall name ICMP-NAME rule 40 protocol icmp
vyatta@R1# set security firewall name ICMP-NAME rule 40 icmp type-name
echo-request
vyatta@R1# set security firewall name ICMP-NAME rule 40 action accept
Specify a reject action within a firewall instance.
Specify an address group to match as a destination.
vyatta@R1# set resources group address-group SERVERS address
1.1.1.7
vyatta@R1# set resources group address-group SERVERS address
10.0.10.0/24
vyatta@R1# set resources group port-group PORTS port 22
vyatta@R1# set resources group port-group PORTS port http
vyatta@R1# commit
vyatta@R1# show resources
group {
address-group SERVERS {
address 10.0.10.0/24
address 1.1.1.7
}
port-group PORTS {
port 22
port http
}
}
vyatta@R1#
vyatta@R1# set security firewall name REJECT-GROUPS rule 10
action drop
vyatta@R1# set security firewall name REJECT-GROUPS rule 10
destination address SERVERS
26Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
Rejecting traffic based on groups of addresses, networks, and ports (Continued)TABLE 9
StepCommand
Stateful behavior
Specify a port group to match as a destination.
Commit the configuration.
Show the configuration.
Stateful behavior
Stateless firewalls filter packets in isolation, based on static source and destination information. In
contrast, stateful firewalls track the state of network connections and traffic flows and allow or restrict
traffic based on whether its connection state is known and authorized. For example, when an initiation
flow is allowed in one direction, the responder flow is automatically and implicitly allowed in the return
direction.
By default, the vRouter firewall is stateless. If you want the firewall to operate statefully, you have two
choices:
• You can leave the firewall operating statelessly in general and specify stateful behavior per rule set
by configuring state rules within the rule set. This configuration is described in Configuring stateful
behavior per rule set on page 27.
• You can enable global stateful behavior by configuring global state policies. This configuration is
described in Configuring global state policies on page 28.
vyatta@R1# set security firewall name REJECT-GROUPS rule 10
destination port PORTS
vyatta@R1# commit
vyatta@R1# show security firewall name REJECT-GROUPS
rule 10{
action drop
destination {
address SERVERS
port PORTS
}
source {
address SERVERS
}
}
vyatta@R1#
Configuring stateful behavior per rule set
Even if you want the firewall to operate statelessly in general, you can still configure state rules within a
specific rule set.
The following example shows how to configure a rule in the TEST1 firewall rule set. Rule 1 accepts
stateful traffic flows and flows related to existing connections for all protocols.
To configure per-rule set state rules, perform the following steps in configuration mode.
Creating a per-rule set state ruleTABLE 10
StepCommand
Create the configuration node for the TEST1 rule set
and give a description for the rule set.
vyatta@R1# set security firewall name TEST1 description
"Filter traffic statefully"
Configuring global state policies
Creating a per-rule set state rule (Continued)TABLE 10
StepCommand
Create a state rule.
Commit the configuration.
Show the firewall configuration.
Configuring global state policies
You can change behavior to be globally stateful by setting a global state policy with security firewall
global-state-policy <protocol> on page 45. When state policies are defined, state rules for return
traffic of that type need not be explicitly mentioned within the rule sets.
The global state policy that is configured applies to all IPv4 and IPv6 traffic destined for, originating
from, or traversing the router. Note that after the firewall is configured to be globally stateful, this
setting overrides any state rules configured within the rule set.
The following example shows how to configure the firewall globally to allow all return traffic.
This behavior is the same as that configured in the TEST1 rule set in Configuring stateful behavior per
rule set on page 27, except that it is applied globally instead of being restricted to the one rule set.
To configure this global stateful behavior, perform the following steps in configuration mode.
vyatta@R1# set security firewall name TEST1 rule 1 action
accept
vyatta@R1# set security firewall name TEST1 rule 1 state
enable
vyatta@R1# commit
vyatta@R1# show security firewall name TEST1
description "Filter traffic statefully"
rule 1 {
action accept
state enable
}
Setting a global state policyTABLE 11
StepCommand
Configure global state policy.
Commit the configuration.
Show the state policy configuration.
vyatta@R1# set security firewall global-state-policy icmp
vyatta@R1# set security firewall global-state-policy tcp
vyatta@R1# set security firewall global-state-policy udp
vyatta@R1# commit
vyatta@R1# show security firewall global-state-policy
icmp
tcp
udp
Zone-based firewall
The vRouter also supports a zone-based model. The following figure shows a zone-based
configuration with three user-defined zones.
The examples that follow show the configuration for this diagram.
28Brocade 5600 vRouter Firewall Reference Guide
53-1003710-03
FIGURE 5 Zone-based firewall configuration
Filtering traffic between zones
Filtering traffic between zones
The following example shows how to filter traffic between zones by attaching rule sets to zone.
Creating the zone policiesTABLE 12
StepCommand
Create a zone named private and attach
interfaces to it.
Create a zone named dmz and attach an
interface to it.
Create a zone named public and attach an
interface to it.
Create rule sets named to_private ,
to_dmz , and to_public .
vyatta@R1# set security zone-policy zone private description PRIVATE
vyatta@R1# set security zone-policy zone private interface dp0p1p1
vyatta@R1# set security zone-policy zone private interface dp0p1p2
vyatta@R1# set security zone-policy zone dmz description DMZ
vyatta@R1# set security zone-policy zone dmz interface dp0p1p3
vyatta@R1# set security zone-policy zone public description PUBLIC
vyatta@R1# set security zone-policy zone public interface dp0p1p4
vyatta@R1# set security firewall name to_private rule 1 action accept
vyatta@R1# set security firewall name to_dmz rule 1 action accept
vyatta@R1# set security firewall name to_public rule 1 action accept