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:

  • For systems with multiple WANs, traffic attempting to exit WAN interfaces other than the one with the default gateway may not be able to pass outbound. This is because states initially get created by the OS as the packet attempts to leave following the default route, and then get redirected by route-to out a different path. Since the interfaces on the state do not match, the firewall does not allow the packet. Work is ongoing to address this issue in PF.

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

See also

Refer to NAT Reflection for a discussion on the merits of NAT Reflection when compared to other techniques such as Split DNS.

There are three possible modes for NAT Reflection:

Disabled

The default value. When disabled, port forwards are only accessible from WAN and not from inside local networks.

Pure NAT

This mode uses a set of NAT rules to direct packets to the target of the port forward. It has better scalability, but it must be possible to accurately determine the interface and gateway IP address used for communication with the target at the time the rules are loaded. There are no inherent limits to the number of ports other than the limits of the protocols. All protocols available for port forwards are supported.

When this option is enabled, Automatic Outbound NAT for Reflection must also be enabled if the clients and servers are in the same local network.

NAT + Proxy

NAT + proxy mode uses a helper program to send packets to the target of the port forward. The connection is received by the reflection daemon and it acts as a proxy, creating a new connection to the local server. This behavior puts a larger burden on the firewall, but is useful in setups where the interface and/or gateway IP address used for communication with the target cannot be accurately determined at the time the rules are loaded. NAT + Proxy reflection rules are not created for ranges larger than 500 ports and will not be used for more than 1000 ports total between all port forwards. This feature only supports TCP port forwards.

Individual NAT rules have the option to override the global NAT reflection configuration, so they may have NAT reflection forced on or off on a case-by-case basis.

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.

See also

Descriptions in the following options reference firewall state conditions as described in Interpreting States.

TCP First

The first packet of a TCP connection.

TCP Opening

The state before the destination host has replied (e.g. SYN_SENT:CLOSED).

TCP Established

An established TCP connection where the three-way handshake has been completed.

TCP Closing

One side has sent a TCP FIN packet.

TCP FIN Wait

Both sides have exchanged FIN packets and the connection is shutting down. Some servers may continue to send packets during this time.

TCP Closed

One side has sent a connection reset (TCP RST) packet.

TCP Tsdiff

The allowed TCP timestamp difference.

UDP First

The first UDP packet of a connection has been received.

UDP Single

The source host has sent a single packet but the destination has not replied (e.g. SINGLE:NO_TRAFFIC).

UDP Multiple

Both sides have sent packets.

ICMP First

An ICMP packet has been received.

ICMP Error

An ICMP error was received in response to an ICMP packet.

Other First, Other Single, Other Multiple

The same as UDP, but for other protocols.