Configuring firewall rules¶
When configuring firewall rules under Firewall > Rules many options are available to control how traffic is matched and controlled. Each of these options are listed in this section.
This option specifies whether the rule will pass, block, or reject traffic.
|Pass:||A packet matching this rule will be allowed to pass through the firewall. If state tracking is enabled for the rule, a state table entry is created which allows related return traffic to pass back through. See Stateful Filtering for more information.|
|Block:||A packet matching this rule will be discarded.|
|Reject:||A packet matching this rule will be discarded and for supported protocols, a message will be sent back to the originator indicating that the connection was refused.|
See Block vs. Reject for a deeper description of the options and for help deciding between Block and Reject.
To disable a rule without removing it from the rule list, check this box. It will still show in the firewall rules screen, but the rule will appear grayed out to indicate its disabled state.
The Interface drop down specifies the interface receiving traffic to be controlled by this rule. Remember that on interface and group tab rules, traffic is only filtered on the interface where the traffic is initiated. Traffic initiated from the LAN destined to the Internet or any other interface on the firewall is filtered by the LAN ruleset.
Instructs the rule to apply for IPv4, IPv6, or both IPv4+IPv6 traffic. The rules will only match and act upon packets matching the correct protocol. Aliases may be used which contain both types of IP addresses and the rule will match only the addresses from the correct protocol.
The protocol this rule will match. Most of these options are self-explanatory. TCP/UDP will match both TCP and UDP traffic. Specifying ICMP will show an additional drop down box to select the ICMP type. Several other common protocols are also available.
This field defaults to TCP for a new rule because it is a common default and it will display the expected fields for that protocol. To make the rule apply to any protocol, change this field to any. One of the most common mistakes in creating new rules is accidentally creating a TCP rule and then not being able to pass other non-TCP traffic such as ping, DNS, etc.
When ICMP is selected as the protocol, this drop-down contains all possible ICMP types to match. When passing ICMP, the best practice is to only pass the required types when feasible. The most common use case is to pass only a type of Echo Request which will allow an ICMP ping to pass.
Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP.
This field specifies the source IP address, subnet, or alias that will match this rule.
The drop-down box for source allows several different pre-defined types of sources:
|Any:||Matches any address.|
|Single host or Alias:|
|Matches a single IP address or alias name. When this is active, an alias name may be typed in the Source Address field.|
|Network:||Uses both an IP address and subnet mask to match a range of addresses.|
|PPPoE Clients:||A macro that will match traffic from the client address range for the PPPoE server if the PPPoE server is enabled.|
|L2TP Clients:||A macro that will match traffic from the client address range for the L2TP server if the L2TP server is enabled.|
|Interface Net:||An entry in this list is present for each interface on the firewall. These macros specify the subnet for that interface exactly, including any IP alias VIP subnets that differ from the defined interface subnet.|
|An entry in this list is present for each interface on the firewall. These macros specify the IP address configured on that interface.|
The WAN Net choice for source or destination means the subnet of the WAN interface only. It does not mean “The Internet” or any remote host.
For rules matching TCP and/or UDP, the source port may also be specified by
clicking the Display Advanced. The source port is hidden behind the
Display Advanced button because normally the source port must remain set to
any, as TCP and UDP connections are sourced from a random port in the
ephemeral port range (between 1024 through 65535, the exact range used varying
depending on the OS and OS version that is initiating the connection). The
source port is almost never the same as the destination port, and it should
never be configured as such unless the application in use is known to employ
this atypical behavior. It is also safe to define a source port as a range from
Selecting Invert Match will negate the match so that all traffic except this source value will trigger the rule.
This field specifies the destination IP address, subnet, or alias that will match this rule. See the description of the Source option in Source for more details.
For rules specifying TCP and/or UDP, the destination port, port range, or alias is also specified here. Unlike source, configuring a destination port is required in many cases, as it is more secure than using any and usually the destination port will be known in advance based on the protocol. Many common port values are available in the drop-down lists, or select (other) to enter a value manually or to use a port alias.
To specify a continuous range of ports, enter the lower port in the From section and the higher port value in the To section.
This box determines whether packets that match this rule will be logged to the firewall log. Logging is discussed in more detail in Logging Practices.
Enter a description here for reference. This is optional, and does not affect functionality of the rule. The best practice is to enter text describing the purpose of the rule. The maximum length is 52 characters.
Options which are less likely to be required or that have functionality confusing to new users have been tucked away in this section of the page. Click Display Advanced to show all of the advanced options. If an option in this section of the page has been set, then it will appear when the rule is loaded in the future .
One of the more unique features of pf and thus pfSense is the ability to filter by the operating system initiating a connection. For TCP rules, pf enables passive operating system fingerprinting (“p0f”) that allows rules to match based on the operating system initiating the TCP connection. The p0f feature of pf determines the OS in use by comparing characteristics of the TCP SYN packet that initiates TCP connections with a fingerprints file. Note that it is possible to change the fingerprint of an operating system to look like another OS, especially with open source operating systems such as the BSDs and Linux. This isn’t easy, but if a network contains technically proficient users with administrator or root level access to systems, it is possible.
Diffserv Code Point¶
Differentiated Services Code Point is a way for applications to indicate inside the packets how they would prefer routers to treat their traffic as it gets forwarded along its path. The most common use of this is for quality of service or traffic shaping purposes. The lengthy name is often shortened to Diffserv Code Point or abbreviated as DSCP and sometimes referred to as the TOS field.
The program or device generating the packets, for example Asterisk via its
tos_audio configuration parameters, will set the DSCP field
in the packets and then it is up to the firewall and other interim routers to
match and queue or act on the packets.
To match these parameters in the firewall, use the Diffserv Code Point drop-down entry that matches the value set by the originating device. There are numerous options, each with special meaning specific to the type of traffic. Consult the documentation for the device originating the traffic for more detail on which values must be matched.
The downside of DSCP is that it assumes routers support or act on the field, which may or may not be the case. Different routers may treat the same DSCP value in unintended or mismatched ways. Worse yet, some routers will clear the DSCP field in packets entirely as it forwards them. Also, the way pf matches traffic, the DSCP value must be set on the first packet of a connection creating a state, as each packet is not inspected individually once a state has been created.
This option only reads and matches the DSCP value. It does not set a value in packets.
Checking this box will allow packets with defined IP options to pass. By default, pf blocks all packets that have IP options set in order to deter OS fingerprinting, among other reasons. Check this box to pass IGMP or other multicast traffic containing IP options.
The firewall adds the
reply-to keyword to rules on WAN type interfaces by
default to ensure that traffic that enters a WAN will also leave via that same
WAN. In certain cases this behavior is undesirable, such as when some traffic is
routed via a separate firewall/router on the WAN interface. In these cases,
check this option to disable
reply-to only for traffic matching this rule,
rather than disabling
Tag and Tagged¶
The Tag and Tagged fields are useful in concert with floating rules, so the firewall can mark a packet with a specific string as it enters an interface, and then act differently on a matched packet on the way out with a floating rule. See Marking and Matching for more on this topic.
Maximum state entries this rule can create¶
This option limits the maximum number of connections, total, that can be allowed by this rule. If more connections match this rule while it is at its connection limit, this rule will be skipped in the rule evaluation. If a later rule matches, the traffic has the action of that rule applied, otherwise it hits the default deny rule. Once the number of connections permitted by this rule drops below this connection limit, traffic can once again match this rule.
Maximum number of unique source hosts¶
This option specifies how many total source IP addresses may simultaneously connect for this rule. Each source IP address is allowed an unlimited number of connections, but the total number of distinct source IP addresses allowed is restricted to this value.
Maximum number of established connections per host¶
To limit access based on connections per host, use this setting. This value can
limit a rule to a specific number of connections per source host (e.g.
instead of a specific global connection total. This option controls how many
fully established (completed handshake) connections are allowed per host that
match the rule. This option is only available for use with TCP connections.
Maximum state entries per host¶
This setting works similar to the established count above, but it checks for state entries alone rather than tracking if a successful connection was made.
Maximum new connections / per second¶
This method of rate limiting helps ensure that a high TCP connection rate will
not overload a server or the state table on the firewall. For example, limits
can be placed on incoming connections to a mail server, reducing the burden of
being overloaded by spambots. It can also be used on outbound traffic rules to
set limits that would prevent any single machine from loading up the state table
on the firewall or making too many rapid connections, behaviors which are common
with viruses. A connection amount and a number of seconds for the time period
may be configured for the rule. Any IP address exceeding the specified number of
connections within the given time frame will be blocked by the firewall for one
hour. Behind the scenes, this is handled by the
virusprot table, named for
its typical purpose of virus protection. This option is only available for use
with TCP connections.
State timeout in seconds¶
Using this field, a state timeout for traffic matching this rule may be defined, overriding the default state timeout. Any inactive connections will be closed when the connection has been idle for this amount of time. The default state timeout depends on the firewall optimization algorithm in use. The optimization choices are covered in Firewall Optimization Options
This option only controls the traffic in the inbound direction, so it is not very useful on its own. Outbound traffic for a matching connection will still have the default state timeout. To use this setting properly, a matching floating rule is also required in the outbound path taken by the traffic with a similar state timeout setting.
By default, new pass rules for TCP only check for the TCP SYN flag to be set, out of a possible set of SYN and ACK. To account for more complex scenarios, such as working around asymmetric routing or other non-traditional combinations of traffic flow, use this set of controls to change how the flags are matched by the firewall rule.
The first row controls which flags must be set to match the rule. The second row defines the list of flags that will be consulted on the packet to look for a match.
The meanings of the most commonly used flags are:
|SYN:||Synchronize sequence numbers. Indicates a new connection attempt.|
|ACK:||Indicates ACKnowledgment of data. These are replies to let the sender know data was received OK.|
|FIN:||Indicates there is no more data from the sender, closing a connection.|
|RST:||Connection reset. This flag is set when replying to a request to open a connection on a port which has no listening daemon. Can also be set by firewall software to turn away undesirable connections.|
|PSH:||Indicates that data should be pushed or flushed, including data in this packet, by passing the data up to the application.|
|URG:||Indicates that the urgent field is significant, and this packet should be sent before data that is not urgent.|
To allow TCP with any flags set, check Any Flags.
There are three options for state tracking in pfSense that can be specified on a per-rule basis:
When chosen, the firewall will create and maintain a state table entry for permitted traffic. This is the default, and the best choice in most situations.
Sloppy is a less strict means of keeping state that is intended for scenarios with asymmetric routing. When the firewall can only see half the traffic of a connection, the validity checks of the default state keeping will fail and traffic will be blocked. Mechanisms in pf that prevent certain kinds of attacks will not kick in during a sloppy state check.
This option causes pfSense to proxy incoming TCP connections. TCP connections start with a three way handshake. The first packet of a TCP connection is a SYN from source, which elicits a SYN ACK response from the destination, then an ACK in return from the source to complete the handshake. Normally the host behind the firewall will handle this on its own, but synproxy state has the firewall complete this handshake instead. This helps protect against one type of Denial of Service attack, SYN floods. This is typically only used with rules on WAN interfaces. This type of attack is best handled at the target OS level today, as every modern operating system includes capabilities of handling this on its own. Because the firewall can’t know what TCP extensions the back-end host supports, when using synproxy state, it announces no supported TCP extensions. This means connections created using synproxy state will not use window scaling, SACK, nor timestamps which will lead to significantly reduced performance in most all cases. It can be useful when opening TCP ports to hosts that do not handle network abuse well, where top performance isn’t a concern.
This option will not keep state on this rule. This is only necessary in some highly specialized advanced scenarios, none of which are covered in this book because they are exceedingly rare.
Setting None here only affects traffic in the inbound direction, so it is not very useful on its own since a state will still be created in the outbound direction. It must be paired with a floating rule in the outbound direction which also has the same option chosen.
No XML-RPC Sync¶
Checking this box prevents this rule from synchronizing to other High Availability cluster members via XMLRPC. This is covered in High Availability. This does not prevent a rule on a secondary node from being overwritten by the primary.
VLAN Priority (Match and Set)¶
802.1p, also known as IEEE P802.1p or Priority Code Point, is a way to match and tag packets with a specific quality of service priority. Unlike DSCP, 802.1p operates at layer 2 with VLANs. However, like DSCP, the upstream router must also support 802.1p for it to be useful.
There are two options in this section. The first will match an 802.1p field so the firewall can act on it. The second will inject an 802.1p tag into a packet as it passes through this firewall. Some ISPs may require an 802.1p tag to be set in certain areas, such as France, in order to properly handle voice/video/data on segregated VLANs at the correct priority to ensure quality.
There are eight levels of priority for 802.1p, and each has a two letter code in the GUI. In order from lowest priority to highest, they are:
This option configures a schedule specifying the days and times for the rule to be in effect. Selecting “none” means the rule will always be enabled. For more information, see Time Based Rules later in this chapter.
This option configures a Gateway or Gateway Group to be used by traffic matching this rule. This is covered in Policy routing.
In/Out Pipe (Limiters)¶
These selections list defined Limiters to apply a bandwidth limit to the traffic entering this interface (In) and leaving this interface (Out). More detail on limiters can be found in Limiters.