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.
- 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 is 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.
When set, the Maximum MSS option is available and its value is used by the firewall configuration.
- 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.
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:
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.
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.
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:
First TCP packet
No response yet
15min + 5sec
Got both FINs
Got an RST
Allowed TS diff
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
To disable only NAT, do not use this option. Consult Disabling Outbound NAT for more information on controlling outbound NAT behavior.
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.
scrub also disables other features that rely on
scrub to function, such as DF bit clearing and ID randomization.
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).
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
900000 entries the state timeouts will be scaled to 50% of their
(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.
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.
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
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.
In a Multi-WAN configuration the firewall has a beneficial default behavior that
ensures traffic leaves the same interface it arrived through. This is
accomplished using the
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
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
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.
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.
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.
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
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.
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.
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 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.
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:
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.
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.
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.
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.
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.
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.
- 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.
- 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.