IP Do-Not-Fragment compatibility¶
This option is a workaround for operating systems that 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 systems.
When this option is enabled, the firewall will not drop these malformed packets but instead clear the don’t fragment 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:
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.
When Disable all packet filtering is set, the pfSense® firewall is turned
into a routing-only platform. This is accomplished by disabling
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, pfSense 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 how many states are 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.
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 200,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 pfBlocker 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 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
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. pfSense 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.
We recommend creating 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.
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.
We always recommend using 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. Only TCP port forwards are supported.
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.
- 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.