Firewall & NAT¶

The options on System > Advanced, Firewall & NAT tab control various aspects of how the firewall processes packets and connections.

Packet Processing¶

IP Do-Not-Fragment compatibility¶

This option is a workaround for operating systems which generate fragmented packets with the “don’t fragment” (DF) bit set. Linux NFS (Network File System) is known to do this, as well as some VoIP implementations.

When this option is enabled, the firewall will not drop these malformed packets but instead it will clear the DF bit. The firewall will also randomize the IP identification field of outgoing packets to compensate for operating systems that set the DF bit but set a zero IP identification header field.

IP Random ID generation¶

If Insert a stronger ID into IP header of packets passing through the filter is checked, the firewall replaces the IP identification field of packets with random values to compensate for operating systems that use predictable values. This option only applies to packets that are not fragmented after the optional packet reassembly.

Firewall Optimization Options¶

The optimization mode controls how the firewall expires state table entries:

Normal:: The standard optimization algorithm, which is optimal for most environments.
High Latency:: Used for high latency links, such as satellite links. Expires idle connections later than default.
Aggressive:: Expires idle connections quicker. More efficient use of CPU and memory but can drop legitimate connections earlier than expected. This option can also improve performance in high traffic deployments with lots of connections, such as web services.
Conservative:: Tries to avoid dropping any legitimate connections at the expense of increased memory usage and CPU utilization. Can aid in environments that require long-lived but mostly idle UDP connections, such as VoIP.

The table Firewall Optimization Details contains the values chosen by PF for each optimization algorithm. The values are taken from the PF source code. The first line is the raw value, second line is human readable:

Firewall Optimization Details¶
	Normal	High Latency	Conservative	Aggressive
tcp.first First TCP packet	60 1min	180 3min	3600 60min	30 30sec
tcp.opening No response yet	30 30sec	35 35sec	900 15min	5 5sec
tcp.established Established	86400 24h	86400 24h	432000 5days	18000 5h
tcp.closing Half closed	900 15min	905 15min + 5sec	3600 1h	60 60sec
tcp.finwait Got both FINs	45 45sec	50 50sec	600 10min	30 30sec
tcp.closed Got an RST	90 90sec	95 95sec	180 3min	30 30sec
tcp.tsdiff Allowed TS diff	30 30sec	60 60sec	60 60sec	10 10sec

Disable Firewall Scrub¶

When set, the scrubbing option in pf is disabled. The scrub action in pf can interfere with NFS, and in rare cases, with VoIP traffic as well. By default, the firewall uses the fragment reassemble option which reassembles fragmented packets before sending them on to their destination, when possible. More information on the scrub feature of pf can be found in the OpenBSD PF Scrub Documentation.

Note

Disabling scrub also disables other features that rely on scrub to function, such as DF bit clearing and ID randomization. Disabling scrub does not disable MSS clamping if it is active for VPNs, or when an MSS value is configured on an interface.

Firewall Adaptive Timeouts¶

Adaptive Timeouts control state handling in pf when the state table is nearly full. Using these timeouts, a firewall administrator can control how states are expired or purged when there is little or no space remaining to store new connection states.

Adaptive Timeouts are enabled by default and the default values are calculated automatically based on the configured Firewall Maximum States value.

Adaptive Start:: Adaptive scaling is started once the state table reaches this level, expressed as a number of states. Adaptive Start defaults to 60% of Firewall Maximum States.
Adaptive End:: When the size of the state table reaches this value, expressed as a number of state table entries, all timeout values are assumed to be zero, which causes pf to purge all state entries immediately. This setting defines the scale factor, it should be set greater than the total number of states allowed. Adaptive End defaults to 120% of Firewall Maximum States.

When the number of connection states exceeds the threshold set by Adaptive Start, timeout values are scaled linearly with factor based on the number of states used between the Start and End state counts. The timeout adjustment factor is calculated as follows: (Number of states until the Adaptive End value is reached) / (Difference between the Adaptive End and Adaptive Start values).

Note

As an example, consider a firewall with Adaptive Start set to 600000, Adaptive End set to 1200000 and Firewall Maximum States set to 1000000. In this situation, when the state table size reaches 900000 entries the state timeouts will be scaled to 50% of their normal values.

(1,200,000 - 900,000) / (1,200,000 - 600,000) = 300,000 / 600,000 = 0.50, 50%

Continuing the example, when the state table is full at 1,000,000 states the timeout values will be reduced to 1/3 of their original values.

Tip

The state table usage indicator on the dashboard will change color and text when the state table size crosses these thresholds.

Firewall Maximum States¶

This value is the maximum number of connections the firewall can hold in its state table. The default size is calculated based on 10% of total RAM. This default value is sufficient for most installations, but can be adjusted higher or lower depending on the load and available memory.

Each state consumes approximately 1 KB of RAM, or roughly 1 MB of RAM for every 1000 states. The firewall must have adequate free RAM to contain the entire state table before increasing this value. Firewall states are discussed further in Stateful Filtering.

Tip

On a firewall with 8GB of RAM the state table would have a default size of approximately 800,000 states. A custom Firewall Maximum States value of 4,000,000 would consume about 4GB of RAM, half the available 8GB total.

Firewall Maximum Table Entries¶

This value defines the maximum number of entries that can exist inside of address tables used by the firewall for collections of addresses such as aliases, ssh/GUI lockout records, hosts blocked by snort alerts, and so on. By default this is 400,000 entries. If the firewall has features enabled which can load large blocks of address space into aliases such as URL Table aliases or the pfBlockerNG package, then increase this value to comfortably include at least double the total amount of entries contained in all aliases combined.

Firewall Maximum Fragment Entries¶

When scrub is enabled the firewall maintains a table of packet fragments waiting to be reassembled. By default this table can hold 5000 fragments. In rare cases a network may have an unusually high rate of fragmented packets which can require more space in this table. When this limit is reached, the following log message will appear in the main system log:

kernel: [zone: pf frag entries] PF frag entries limit reached

VPN Packet Processing¶

These settings affect traffic behavior with some types of VPNs, including IPsec and OpenVPN. It also affects the PPPoE Server.

IP Do-Not-Fragment compatibility¶

This option is the same as IP Do-Not-Fragment compatibility but this option only applies that behavior to VPN networks.

IP Fragment Reassemble¶

Reassemble IP Fragments for normalization. In this case, fragments are buffered until they form a complete packet, and only the completed packet is passed on to the filter. The advantage is that filter rules have to deal only with complete packets, and can ignore fragments. The drawback of caching fragments is the additional memory cost and potential introduction of latency.

MSS Clamping¶

Enable maximum segment size clamping on TCP flows over IPsec tunnels. This helps overcome problems with path MTU discovery (PMTUD) on IPsec VPN links.

This is useful if large TCP packets have problems traversing the VPN, or if slow/choppy connections across the VPN are observed by users. Ideally it should be set to the same value on both sides of the VPN, but traffic will have MSS clamping applied in both directions.

Enable:: When set, the Maximum MSS option is available and its value is used by the firewall configuration.

Note

For IPsec using VTI mode phase 2 entries, set the MSS value in the interface configuration for the assigned VTI interface under the Interfaces menu.
Maximum MSS:: The maximum segment size set in TCP packets flowing across IPsec VPN tunnels. Defaults to 1400. Must be low enough to account for the overhead of IPsec and the MTU of the link, but no so low that unnecessarily small segments are sent as that can be inefficient.

Advanced Options¶

Disable Firewall¶

When Disable all packet filtering is set, the firewall becomes a routing-only platform. This is accomplished by disabling pf entirely, and as a consequence, NAT is disabled since it is also handled by pf.

Tip

To disable only NAT, do not use this option. Consult Disabling Outbound NAT for more information on controlling outbound NAT behavior.

Firewall State Policy¶

Controls the default State Policy for states created by firewall rules. These policies fundamentally change how the firewall checks packets against existing state table entries to determine if a packet should be allowed. There are two options available, Interface Bound States and Floating States.

Note

There is no difference in the ability to view or kill states between either mode.

Tip

While this option controls the global default, there is a per-rule option to override this behavior as well. See State Policy for details.

Interface Bound States¶

Interface Bound States are more strict and secure. States are bound to specific interfaces by their OS/driver name (e.g. igcX). If a packet attempts to take a path through a different interface than the one to which it is bound, the packet is dropped.

As this is the most secure option, it is currently the default policy.

This policy is less likely to allow VPN or other traffic to “leak” or egress via unexpected paths (e.g. during interface events).

This policy has some drawbacks, however, as noted in the following subsections.

IPsec VTI Filtering¶

For firewalls utilizing IPsec VTI tunnels, due to the way the OS handles traffic on VTI interfaces in the default IPsec Filter Mode packets may appear to enter and exit on different interfaces (e.g. ipsecX vs enc0). This can cause issues with Interface Bound states but pass traffic OK with floating states.

This situation can be worked around a couple different ways:

Change IPsec Filter Mode

The most secure option is only viable in certain cases. On installations which only contain VTI tunnels and no policy-based tunnels or mobile IPsec configurations, switch the IPsec Filter Mode option in the Advanced IPsec Settings to Filter IPsec VTI and Transport on assigned interfaces, block all tunnel mode traffic.

When configured in this way, PF can track states and packets on VTI interfaces appropriately, but it is not compatible with tunnel mode or mobile IPsec.

Rules with Floating Policy Set

The most compatible method is to add rules using the floating policy for IPsec VTI traffic:

Edit rules on the IPsec tab and change the per-rule State Policy in the Advanced Options to Floating States on each rule that matches inbound traffic from VTI peers.
Add new rule(s) on to the top of the Floating tab to match outbound traffic for VTI peers, for example:

Action
Pass

Quick
Checked

Interface
IPsec (enc0)

Direction
Out

Advanced Options: State Policy
Floating States

Set the other parameters to match the VTI peer traffic, or set the rule for Any protocol, source, and destination to match any outbound IPsec traffic.

Change Default State Policy

Switching the default policy back to Floating states will allow it to work, but with the security implications mentioned previously.

High Availability State Synchronization¶

For High Availability configurations utilizing state synchronization (pfsync), all nodes in the cluster must either be using identical hardware and physical interface assignments, or be using abstracted interfaces such as laggX that can mask hardware differences. Otherwise synchronized states will never match traffic on the secondary node, making state synchronization ineffective. See pfsync and Physical Interfaces for more information on this limitation.

Floating States¶

Floating States are less secure, more lenient in their checks, and are not strictly associated with any interface. The interface is tracked in state properties, but it is informational and not enforced.

This policy is more forgiving when it comes to multi-WAN and asymmetric routing scenarios. It also allows HA nodes with different hardware to utilize state synchronization.

The most significant drawback to this relaxed policy is that it might allow packets to be misdirected or take unexpected paths. This is especially the case if routing can be manipulated in some way (e.g. by a dynamic WAN). This can be especially problematic for secure traffic, such as between local systems on separate interfaces, or for VPN traffic.

State Policy History¶

The state policy behavior in PF has changed over time as it changed in the base OS, but the option to explicitly choose the default behavior did not exist until recently.

Very old versions of pfSense software (2.1.5 and before) behaved in the “floating” style.

From pfSense software version 2.2 until pfSense Plus software version 21.05.2/CE 2.5.2 the behavior was closer to “interface bound” but not identical.

From pfSense Plus software version 22.01/CE 2.6.0 until pfSense Plus software version 23.09.1/CE 2.7.2 the behavior was closer to “floating”.

Starting with pfSense Plus software version 24.03/CE 2.8.0 the default is explicitly set to “interface bound” for increased security.

The ability to change the policy, as well as the change in default policy, will also be available to some previous releases via the recommended patches mechanism in the System Patches package.

Ethernet Filtering (Plus Only)¶

Enable experimental rule-based pass/block filtering of packets based on Ethernet (Layer 2) header attributes (e.g. MAC addresses). These rules are processed before other (L3) rules on the inbound direction, and after those rules outbound. When enabled, Ethernet rules are managed on their own tab at Firewall > Rules, Ethernet tab.

Note

This feature is exclusive to pfSense Plus version 23.05 and later.

Static Route Filtering¶

The Bypass firewall rules for traffic on the same interface option applies if the firewall has one or more static routes defined. If this option is enabled, traffic that enters and leaves through the same interface will not be checked by the firewall. This may be required in situations where multiple subnets are connected to the same interface, to avoid blocking traffic that is passed through the firewall in one direction only due to asymmetric routing. See Bypass Firewall Rules for Traffic on Same Interface for a more in-depth discussion on that topic.

Disable Auto-added VPN rules¶

By default, when IPsec is enabled firewall rules are automatically added to the appropriate interface which will allow the tunnel to establish. When Disable Auto-added VPN rules is checked, the firewall will not automatically add these rules. By disabling these automatic rules, the firewall administrator has control over which addresses are allowed to connect to a VPN. Further information on these rules can be found at VPNs and Firewall Rules.

Disable Reply-To¶

In a Multi-WAN configuration the firewall has a beneficial default behavior that ensures traffic leaves the same interface through which it arrived. This is accomplished using the pf keyword reply-to which is added automatically to interface tab firewall rules for WAN-type interfaces. When a connection matches a rule with reply-to, the firewall remembers the path through which the connection was made and routes the reply traffic back to the gateway for that interface.

Tip

WAN-type interfaces are interfaces which have a gateway set on their Interfaces menu entry configuration, or interfaces which have a dynamic gateway such as DHCP, PPPoE, or assigned OpenVPN, GIF, or GRE interfaces.

In situations such as bridging, this behavior is undesirable if the WAN gateway IP address is different from the gateway IP address of the hosts behind the bridged interface. Disabling reply-to will allow clients to communicate with the proper gateway.

Another case that has issues with reply-to involves static routing to other systems in a larger WAN subnet. Disabling reply-to in this case would help ensure that replies return to the proper router instead of being routed back to the gateway.

This behavior can also be disabled on individual firewall rules rather than globally using this option.

Disable Negate rules¶

In a Multi-WAN configuration traffic for directly connected networks and VPN networks typically must still flow properly when using policy routing. The firewall will insert rules to pass this local and VPN traffic without a gateway specified, to maintain connectivity. In some cases these negation rules can over-match traffic and allow more than intended.

Tip

The best practice is to create manual negation rules at the top of internal interfaces such as LAN. These rules should pass to local and VPN destinations without a gateway set on the rule, to honor the system routing table. These rules do not have to be at the top of the interface rules, but they must be above rules that have a gateway set.

Allow APIPA¶

Automatic Private IP Addressing (APIPA), or IPv4 Link-Local addressing, uses a special subnet of 169.254.0.0/16. This traffic is for local links only (same L2), it must not be routed or traverse a firewall. As such, inbound traffic from these addresses is automatically blocked by internal firewall rules by default.

When Allow APIPA traffic is checked, the default block rules are removed, and user firewall rules can control the traffic.

There are some use cases which utilize these addresses for private communication on an interface, such as AWS VPC BGP, and in those cases, the option can be enabled along with carefully crafted manual firewall rules.

Warning

When this option is enabled, take care to never allow APIPA traffic to match policy routing rules. If APIPA traffic matches policy routing rules, behavior is unpredictable. There have been reports of such errors leading to packet loops and unexpectedly high resource usage. See Redmine Issue #2073 for more.

Aliases Hostnames Resolve Interval¶

This option controls how often hostnames in aliases are resolved and updated by the filterdns daemon. By default this is 300 seconds (5 minutes). In configurations with a small number of hostnames or a fast/low-load DNS server, decrease this value to pick up changes faster.

Check Certificate of Alias URLs¶

When Verify HTTPS certificates when downloading alias URLs is set, the firewall will require a valid HTTPS certificate for web servers used in URL table aliases. This behavior is more secure, but if the web server is private and uses a self-signed certificate, it can be more convenient to ignore the validity of the certificate and allow the data to be downloaded.

Warning

The best practice is to always use a server certificate with a valid chain of trust for this type of role, rather than weakening security by allowing a self-signed certificate.

Bogon Networks¶

The Update Frequency drop-down for Bogon Networks controls how often these lists are updated. Further information on bogon networks may be found in Block Bogon Networks.

Network Address Translation¶

NAT Reflection mode for Port Forwards¶

The NAT Reflection mode for port forwards option controls how NAT reflection is handled by the firewall. These NAT redirect rules allow clients to access port forwards using the public IP addresses on the firewall from within local internal networks.

Reflection Timeout¶

The Reflection Timeout setting forces a timeout on connections made when performing NAT reflection for port forwards in NAT + Proxy mode. If connections are staying open and consuming resources, this option can mitigate that issue.

NAT Reflection for 1:1 NAT¶

When checked, this option adds additional reflection rules which enable access to 1:1 mappings of external IP addresses from internal networks. This gives the same functionality that already exists for port forwards, but for 1:1 NAT. There are complex routing scenarios that may render this option ineffective.

This option only affects the inbound path for 1:1 NAT, not outbound. The underlying rule style is similar to the Pure NAT mode for port forwards. As with port forwards, there are per-entry options to override this behavior.

Automatic Outbound NAT for Reflection¶

When checked, this option automatically creates outbound NAT rules which assist reflection rules that direct traffic back out to the same subnet from which it originated. These additional rules allow Pure NAT and 1:1 NAT Reflection to function fully when the clients and servers are in the same subnet. In most cases, this box must be checked for NAT Reflection to work.

Note

This behavior is necessary because when clients and servers are in the same subnet, the traffic source must be changed so that the connection appears to originate from the firewall. Otherwise, the return traffic will bypass the firewall and the connection will not succeed.

TFTP Proxy¶

The built-in TFTP proxy will proxy connections to TFTP servers outside the firewall, so that client connections may be made to remote TFTP servers. Ctrl-click or shift-click to select multiple entries from the list. If no interfaces are chosen, the TFTP proxy service is deactivated.

State Timeouts¶

The State Timeout section allows fine-tuning of the state timeouts for various protocols. These are typically handled automatically by the firewall and the values are dictated by the Firewall Optimization Options options. In rare cases, these timeouts may need adjusted up or down to account for irregularities in device behavior or site-specific needs.

All of the values are expressed in seconds, and control how long a connection in that state will be retained in the state table.