Configuring firewall rules

When configuring firewall rules in the pfSense® software GUI 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.


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.


A packet matching this rule will be discarded.


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 also

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.

TCP/IP Version

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:


Matches any address.

Address 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.


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 Subnets:

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.

Interface Address:

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 fa-cog 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 1024 to 65535.

Selecting Invert Match will negate the match so that all traffic except this source value will trigger the rule.


Using Invert Match on <interface> Net macros such as LAN net can lead to undesired rule behavior when the interface also uses Virtual IP addresses. This is due to traffic matching against the interface network OR the VIPs. For example, given a Subnet of, a VIP of, and a rule with a negated interface macro such as pass on $LAN from any to ! $LAN_net, traffic destined to will pass because the destination IP address does not match the VIP.


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. There is only one additional macro:

This firewall (self):

Matches all IP addresses on all firewall interfaces.

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.

Advanced Options

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 fa-cog 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 .

Source OS

One of the more unique features of pf and thus pfSense software 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_sip and 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.

IP Options

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.

Disable Reply-To

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 reply-to globally.

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. 10), 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.

TCP Flags

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:


Synchronize sequence numbers. Indicates a new connection attempt.


Indicates ACKnowledgment of data. These are replies to let the sender know data was received OK.


Indicates there is no more data from the sender, closing a connection.


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.


Indicates that data should be pushed or flushed, including data in this packet, by passing the data up to the application.


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.

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

There are three options for state tracking 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 State:

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 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 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.


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 documentation 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 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.


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.

See Firewall > Packet Flow Data for the Global configuration, and 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 Global Packet Flow Options.

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.


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:




Best Effort


Excellent Effort


Critical Applications






Internetwork Control


Network Control


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.


These options define which ALTQ traffic shaper queues are applied to traffic entering and exiting this interface. For more information on traffic shaping, see Traffic Shaper.