Configuring Firewall Rules¶
When configuring firewall rules in the pfSense® software GUI under Firewall > Rules, many options are available to control how the firewall matches and controls packets. This section covers each of these options.
Action¶
This option specifies whether the rule will pass, block, or reject packets.
- Pass:
The firewall will allow packets matching this rule to pass.
If the rule has state tracking enabled, the firewall creates a state table entry for the first packet of a connection. This state table entry allows related return packets to pass back through.
See also
- Block:
The firewall will discard packets matching this rule.
- Reject:
The firewall will discard packets matching this rule and, for supported protocols, the firewall will send a message back to the source indicating that it refused the connection.
See also
See Block vs. Reject for a deeper description of these options and for help deciding between Block and Reject.
Disabled¶
Disables a rule without removing it from the rule list. This entry will appear faded in the rule list to indicate its inactive state.
Interface¶
The interface receiving packets to be matched by this rule. The GUI pre-sets this value to match the interface tab from which the user added or edited the rule. Changing this value will move the rule to the interface tab matching the new value.
Note
Rules on interface and group tabs only filter packets on the interface where packets enter the firewall (ingress). In other words, the interface where hosts initiated those packets.
For example, rules on the LAN tab match packets initiated from hosts on the LAN which pass through the firewall, such as connections to hosts on the Internet or other remote networks.
Address Family¶
The address family this rule will match: IPv4, IPv6, or both IPv4+IPv6. The rule will only match and act upon packets with the selected address family.
Tip
Firewall rules can utilize aliases which contain both IPv4 and IPv6 addresses. Rules will use whichever alias entries match its address family.
NAT64¶
When Address Family is set to IPv6 the GUI displays a checkbox to Enable NAT64 which changes this rule into a NAT64 rule. NAT64 rules perform translation to allow IPv6-only hosts to reach IPv4 resources. Despite acting in a role similar to Outbound NAT, these rules are placed on internal interface firewall rules where packets enter the firewall, e.g. on the LAN tab.
When Enable NAT64 is checked, the GUI displays an Address Family Translation section with the following option:
- Source:
Configures the external source address to which this rule will translate IPv4-mapped connections. For example, the external WAN IPv4 address. This is typically left on Automatic which is the default, but can be set to a specific address or VIP as needed.
Warning
While NAT64 is technically compatible with Outbound NAT, the NAT64 translation happens before Outbound NAT so it is not practical. See NAT64 and other NAT for details.
Tip
NAT64 is compatible with policy routing. See NAT64 and Policy Routing for details.
See also
Protocol¶
The IP protocol this rule will match, such as TCP or UDP. The drop-down list contains several common protocols.
Most options only match packets based on the IP protocol encoded in the packet, however some types support additional filtering behaviors:
- TCP, UDP, SCTP:
These protocols support source and destination port numbers. When a rule is configured for one of these protocols, the GUI displays controls for ports.
- TCP/UDP:
Matches both TCP and UDP packets with a single rule.
- ICMP:
When a rule is configured for ICMP, the GUI displays an ICMP Subtypes option to filter specific types of ICMP messages.
Note
This field defaults to TCP for a new rule because it is a common choice and the GUI will display fields that users expect to see, such as source and destination ports.
To make the rule apply to any protocol, change this option to Any. A common mistake in creating a new ruleset is accidentally creating only TCP rules and then not being able to pass non-TCP packets such as ICMP, DNS, etc.
ICMP Subtypes¶
This multi-select list contains all possible ICMP subtypes which this rule can match. The GUI displays this option when a rule has the Protocol option set to ICMP.
When passing ICMP packets, the most secure practice is for rules to only pass required subtypes when feasible. The most common use case is for rules to pass only the Echo Request subtype which will pass ICMP “ping” packets.
Tip
Allowing an ICMP subtype of any is acceptable in modern networks. ICMP has a bad reputation in the past, but it is generally beneficial and has overcome that reputation on modern networks. Some older equipment may still have issues, however.
Source¶
The source IP address, subnet, or alias that this rule will match.
The Source option contains several different pre-defined types of sources:
- Any:
Matches any address.
- Address or Alias:
Matches a single IP address or alias name.
When a rule is configured for this value, the Source Address field allows entering an alias name and supports auto-completion of compatible alias names.
See also
- Network:
Matches a range of addresses defined by an IP address and CIDR mask/prefix length.
- PPPoE Clients:
Macro which will match packets from the client address range for the PPPoE server if the PPPoE server is enabled.
- L2TP Clients:
Macro which will match packets from the client address range for the L2TP server if the L2TP server is enabled.
- Interface Address:
Macros which match all IP addresses configured on a firewall interface. This includes IP addresses of any address family on the selected interface, such as static IP addresses, Virtual IP Addresses, and dynamic IP addresses obtained from DHCP or PPPoE.
This list contains entries for each interface on the firewall.
- Interface Subnets:
Macros which match networks directly attached to a firewall interface. This includes networks for IP addresses of any address family including static IP addresses, Virtual IP Addresses, and dynamic IP addresses.
This list contains entries for each interface on the firewall.
Warning
This does not match networks reachable through an interface, only networks for IP addresses configured on an interface.
Warning
The WAN subnets value does not mean “The Internet” or “any remote host”, it only matches the network(s) of the WAN interface IP address(es).
Invert Match¶
Invert Match will negate the matching behavior so the rule will match all packets except those with the specified Source value.
Note
Invert Match can lead to undesired rule behavior when configured in combination with <interface> subnets macros, such as LAN subnets, when the interface also uses Virtual IP addresses.
When configured in this manner the firewall will match packets against the
interface network OR the VIP networks. For example, given a Subnet of
192.168.1.0/24, a VIP of 10.0.0.1/32, and a rule with a negated
interface macro such as pass on $LAN from any to ! $LAN_net, packets
destined to 192.168.1.100 will pass because the destination IP address
does not match the VIP.
Source Port Range¶
Rules configured to match the TCP, UDP, or SCTP protocols can also match based on the source port of a packet.
The GUI hides this option behind a 
Display Advanced button as it is
rarely correct to match based on source port. In nearly all cases the source
port must remain set to any as nearly all clients source TCP, UDP, and SCTP
connections from a random port in the ephemeral port range (typically between
1024 through 65535).
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 typically safe to define a source port as a range from 1024 to
65535.
Destination¶
The destination IP address, subnet, or alias that this rule will match. This operates the same as the Source option, but it checks the packet destination.
See also
The Destination field contains one additional macro:
- This firewall (self):
Matches all IP addresses on all firewall interfaces.
Destination Port Range¶
Rules configured to match TCP, UDP, or SCTP protocols can also match based on the destination port, port range, or an alias containing ports.
Configuring a destination port is necessary in many cases as it is more secure than allowing any port and the destination port is usually known in advance based on specific network services.
The drop-down lists contain common port values. Select (other) to enter a numerical port manually or use a port alias.
Tip
A rule will match a continuous range of ports starting at the lower port in the From field and ending at the higher port value in the To field, inclusive.
Log¶
When checked, if this rule matches a packet it will create a log entry in the firewall log.
See also
Description¶
Text describing the rule, such as its intended behavior or name of a service. The best practice is to clearly describe the purpose of the rule in this field.
The description is optional and does not affect functionality of the rule. The maximum length is 52 characters.
Advanced Options¶
Options in this section are less common or have functionality confusing to new
users. As such, the GUI hides them by default. Click Display
Advanced to show all of the advanced options. If an option in this section of
the page has been set, the GUI will automatically display this section when the
rule is loaded in the future.
Source OS¶
Attempts to match a packet by guessing which operating system (OS) is running on the host initiating a connection. This is only possible on rules which match TCP packets.
This task is handled by passive OS fingerprinting (“p0f”). The p0f feature of pf determines the OS in use by comparing characteristics of the TCP SYN packet which initiates TCP connections with a fingerprints file.
Note
It is possible for users to change the fingerprint of one OS to mimic a different OS, especially with an open source OS such as a BSD or Linux variant. This isn’t easy, but if a network contains technically proficient users with administrator or root level access to devices, it is possible.
Diffserv Code Point¶
Differentiated Services Code Point is a packet header a device or application can use to indicate how it prefers routers treat the packet. The most common use of this value is for quality of service or traffic shaping purposes.
Differentiated Services Code Point is often shortened to Diffserv Code Point or abbreviated as DSCP and sometimes referred to as the TOS field.
The Diffserv Code Point drop-down field sets the DSCP value that this rule will match. There are numerous options, each with special meaning. Consult the documentation for the device or application originating the packets for more detail on which values rules must match.
Note
This option only reads and matches the DSCP value. It does not set a value in packets.
The device or application generating the packets will set the DSCP field value
in the packets it creates. For example, Asterisk sets DSCP values via its
tos_sip and tos_audio configuration parameters. After that point it is
up to the firewall and other interim routers to match and queue or act on the
packets.
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 before passing them to the next hop. Also, the way pf matches packets, the DSCP value must be set on the first packet of a connection creating a state, as pf does not inspect each packet individually once it has created a state.
IP Options¶
When set, packets matching this rule can have values set for IP options. By default, pf does not match packets which contain IP options in order to deter OS fingerprinting, among other reasons.
Tip
Check this box to pass IGMP or other multicast packets containing IP options.
Disable Reply-To¶
When set, prevents the firewall from adding the reply-to keyword on this
rule.
By default, the firewall adds the reply-to keyword to rules on WAN type
interfaces to ensure that packets which enter a WAN will also leave via that
same WAN. In certain cases this behavior is undesirable, such as when the
firewall must route packets via a separate firewall/router within the network on
the WAN interface. In these cases, check this option rather than disabling
reply-to globally.
Tag and Tagged¶
The Tag and Tagged fields are useful in concert with floating rules. Using tags, 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 also
Maximum state entries this rule can create¶
Limits the maximum number of connection states, total, that this rule will allow. If this rule matches a packet for a new connection while it is at its connection limit, the firewall will skip this rule during evaluation. If a later rule matches, the firewall applies the action of that rule to the packet, otherwise it hits the default deny rule. Once the number of active connections permitted by this rule drops below this connection limit, the rule can match packets for new connections again.
Maximum number of unique source nodes¶
Limits the total number of unique source IP addresses which may simultaneously have connection states created by this rule. Each source IP address is allowed an unlimited number of connections, but the total number of distinct source IP addresses is restricted to this value.
Maximum number of established connections per host¶
Limits access based on established connection states per host. This value can
limit a rule to a specific number of connections per source host (e.g. 10),
instead of a global connection total. This option controls how many fully
established (completed handshake) TCP connections the rule will allow per host.
This option is only available for use with TCP connections.
Maximum state entries per host¶
Limits connection states in total per host without considering if the connections are established. This setting works similar to the established count above, but it can work with any protocol.
Maximum new connections / per second¶
Limits the amount of new connection states this rule can create in a given time period. This option is only available for use with TCP connections. The Max. src. conn. Rate field sets the number of states and the Max. src. conn. Rates field sets the time period.
Rules can use this feature to attempt preventing a high TCP connection rate from overloading a server or the state table on the firewall. For example, a rule can limit incoming connections to a mail server, reducing the burden of being overloaded by spambots. It can also be used on outbound rules to set limits that can prevent any single host from filling up the state table on the firewall or making too many rapid connections, behaviors which are common with viruses.
The firewall will block any IP address exceeding the specified number of
connections within the given time frame for one hour. Behind the scenes, this is
handled by the virusprot table, named for its typical purpose of virus
protection.
State timeout in seconds¶
Overrides the default timeout for states created by this rule. 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
Note
This option only controls states created in the inbound direction on the given interface, so it has limited usefulness on its own. Outbound packets for a connection will still have the default state timeout as they egress. To fully apply this new timeout, create a matching floating rule in the outbound direction with a similar state timeout value.
TCP Flags¶
By default, pass rules for TCP packets only check for the TCP SYN flag to be set, out of a possible list of SYN and ACK flags. This means that for a packet to match the rule, the SYN flag must be set and the ACK flag must not be set. Other flags are ignored.
This set of controls enables rules to match different flag combinations to account for more complex scenarios, such as working around asymmetric routing or other non-traditional combinations of packet flow.
The Set row controls which flags must be set to match the rule. The Out of row defines the list of flags that will be consulted on the packet to look for a match.
Tip
Flags which are not checked in the Set row but are checked in the Out of row must not be set in packets to match this rule.
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 packets with any combination of flags set, check Any Flags.
No pfsync¶
Prevents states created by this rule from synchronizing data to high availability (HA) peers via pfsync. This isolates states for this rule to only this HA node.
State Policy¶
Optionally overrides the default Firewall State Policy for connection states created by this rule. This is only effective when the State Type for this rule is a type that creates states.
The available options are:
- Use Global Default:
Uses the global default state policy configured at System > Advanced, Firewall & NAT tab, in the Advanced Options section (Firewall State Policy).
- Interface Bound States:
Binds states to interfaces so that when a packet is inspected to determine if it matches an existing state, it must be on the interface where the state was created.
- Floating States:
Does not bind states to interfaces, allowing packets matching the source and destination of a state to pass no matter which interface they are traversing.
See also
For more information on how these policies work, see Firewall State Policy.
State Type¶
Controls how this rule will perform state tracking for connections created by packets matching this rule.
- Keep:
The firewall will create and maintain a state table entry for packets passed by this rule.
This is the default, and the best choice in most situations.
- Sloppy State:
Similar to Keep, but the firewall will perform less strict state comparison checks. This is intended for scenarios with asymmetric routing.
When the firewall can only see half the packet flow of a connection, the default validity checks for state tracking will fail and the firewall will block packets which may be part of active connections. Mechanisms in pf that prevent certain kinds of attacks will not trigger during a sloppy state check.
- Synproxy:
Instructs pf to proxy incoming TCP connections.
TCP connections start with a three way handshake. The first packet of a TCP connection is a SYN from the 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.
This option can be useful when opening TCP ports to hosts that do not handle network abuse well, where top performance isn’t a concern.
- None:
This rule will not create states for packets matching the rule. This is only necessary in highly specialized advanced scenarios, which are not covered in this documentation as they are exceedingly rare.
Note
Setting None on interface tab or group rules only affects packets in the inbound direction. As such, it is not very useful on its own since the outbound rules will still create a state as the packets egress. Rules on interface or group tabs must be paired with a floating rule in the outbound direction which also has the same option set.
Packet Flow Data¶
Optionally overrides the default Firewall Packet Flow Data configuration for tracking data for states created by this rule. This is only effective when the State Type for this rule is a type that creates states.
Note
pfSense® Plus software version 24.03 or later is required to use the Packet Flow Data feature. This feature is not available on pfSense CE Software.
Global configuration for Packet Flow Data is at Firewall > Packet Flow Data.
See also
Read the option descriptions in Global Packet Flow Options for information on how this behaves by default.
There are three options available for Packet Flow Data here in the rule configuration:
- Use global default:
Honor the global default value for tracking packet flow data.
See also
- Always track Packet Flow Data:
Always tracks packet flow data for states created by this rule, no matter what default behavior is configured. This is useful for tracking specific data when the default is not to track.
- Never track Packet Flow Data:
Never tracks packet flow data for states created by this rule, no matter what default behavior is configured. This is useful for excluding data from monitoring when the default is to track everything.
No XMLRPC Sync¶
Checking this box prevents this rule from synchronizing to other High Availability cluster members via XMLRPC.
See also
Warning
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:
- BK:
Background
- BE:
Best Effort
- EE:
Excellent Effort
- CA:
Critical Applications
- VI:
Video
- VO:
Voice
- IC:
Internetwork Control
- NC:
Network Control
Schedule¶
Configures a schedule specifying the days and times this rule will be active. Outside of the scheduled time, the rule is effectively disabled and the firewall skips the rule.
The default value is none which means the rule will always be enabled.
See also
Gateway¶
A gateway or gateway group through which the firewall will deliver packets matching this rule.
When set to Default, the firewall will consult the routing table to determine the next hop for a packet.
See also
In/Out Pipe (Limiters)¶
Traffic shaper Limiters this rule will use to apply bandwidth limits to packets entering this interface (In) and exiting this interface (Out).
See also
Ackqueue/Queue¶
ALTQ traffic shaper queues into which this rule will place matching packets entering and exiting this interface.
See also
Rule Information¶
When a firewall rule, port forward rule, or outbound NAT rule is created or updated the firewall records the login name of the user who modified the rule, the IP address from which they logged in, and timestamps on the rule to track when that user created and/or last changed the rule in question. If the firewall automatically created the rule, the note includes which action created the rule.
An example of a rule update tracking block is shown in Figure Firewall Rule Time Stamps, which is visible when editing a firewall rule at the bottom of the rule editing screen.
Firewall Rule Time Stamps¶
Rule Tracking ID¶
Figure Firewall Rule Time Stamps also displays the rule Tracking ID which is a unique identifier the firewall assigns to a rule. This identifier allows the firewall to locate the rule and correlate actions between the ruleset, firewall logs, and other data tracking purposes.
Note
This value is created and maintained by the firewall itself, the tracking ID is not intended to be edited by administrators.
The firewall generates some rules automatically and/or dynamically, and tracking IDs for such rules may change when the ruleset reloads. Tracking IDs for manually created rules are static.