State Policy Default Change

The default State Policy in pfSense Plus 24.03 software and later releases are changing from Floating states to Interface-bound states for increased security.

In nearly all configurations, pfSense software tracks connections using firewall states so it knows which return traffic to allow back through the firewall for connections that were passed in the other direction. These states carry quite a lot of information, such as the source address, destination address, protocol-specific data such as port numbers, translation information from NAT, metadata such as timestamps and packet counts, and more. For traffic passing through the firewall (e.g. LAN to WAN, LAN to VPN, LAN1 to LAN2), there are typically two state table entries: One as the connection enters the firewall (ingress) and one as the connection exits the firewall (egress).

The state policy fundamentally changes how the firewall checks packets against the interface data in state table entries to determine if a packet should be allowed.

Changing the default behavior has the potential to negatively impact some configurations that rely on the less strict enforcement of the floating state policy.

Interface-Bound State Policy

States using the Interface-Bound policy are, as the name implies, bound to specific interfaces. This is tracked at the operating system level in PF, so the interface names in states are the operating system driver names, such as igc0. Binding states to specific interfaces is more secure as it requires matching the interface through which a packet is passing against the interface stored in the firewall state.

Using the Interface-bound state policy each state table entry starts with an interface name

Strict interface matching has a few downsides. This type of policy can conflict with certain aspects of multi-WAN routing, especially with traffic originating from the firewall itself. Although developers have added workarounds for issues they have identified thus far, there are potentially more corner cases that have not been uncovered during internal testing. Additionally, this policy also requires high availability nodes to have identical hardware to use state synchronization since if the interfaces on the hardware are different, the states from mismatched hardware would either never match or potentially match on unexpected interfaces.

Floating State Policy

The other type of state policy is Floating. States using the Floating policy are not strictly associated with any interface. This policy is more lenient in its checks and, thus, is less secure. In this mode, the interface is still tracked in state properties, but it is informational and not enforced.

Using the Floating state policy each entry starts with all indicating it is valid on all interfaces, and the interface is tracked under origif.

Since the Floating state policy does not strictly enforce the interface of a state, the policy is more forgiving when it comes to multi-WAN and asymmetric routing scenarios. Traffic that happens to take a different path on egress and ingress (e.g. ECMP) is allowed to flow freely without the need for additional advanced/complex rules.

This mode also allows high-availability nodes with different hardware to utilize state synchronization since it ignores differences in interface names carried in state data.

Due to the relaxed nature of state matching under this policy, there is a potential for traffic to be misrouted and "leak" out an unexpected path. For example, traffic intended to egress via VPN could end up exiting via WAN under certain conditions if the VPN is down and routes are removed from the routing table. Similarly, traffic intended to route between local interfaces could egress through a different interface if the routing changes unexpectedly (e.g. WAN DHCP server changes).

History

The state policy behavior in PF has changed over time as it changed in the base OS, but there was no option to explicitly choose the default behavior until now.

• pfSense software versions 2.1.5 and before behaved in the Floating state policy style.
• On version 2.2 through pfSense Plus software version 21.05.2 and pfSense CE software version 2.5.2 the behavior was closer to Interface-bound state policy but not identical.
• pfSense Plus software version 22.01 and pfSense CE software version 2.6.0 through pfSense Plus software version 23.09.1 and pfSense CE software version 2.7.2, the behavior was closer to Floating state policy.
• Starting with pfSense Plus software version 24.03 and pfSense CE software version 2.8.0, the default is explicitly set to Interface-bound policy 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.

State Policy Options

Administrators are free to choose whichever policy best fits the needs of their environment. As pfSense software is security-focused, the more secure policy is the default, but both choices are acceptable in the majority of environments.

There are two methods to change the behavior:

• Global option under System > Advanced, Firewall & NAT tab, which controls the system default State Policy
• Per-rule option which allows administrators to set the policy explicitly for each rule, allowing for a more complex hybrid approach.

While the best practice would be to keep using the Interface-bound state policy, it may not fit every scenario. After upgrading to a release that includes this change, thoroughly test any applicable features such as multi-WAN (outbound and inbound), VPN routing, High Availability, and so on. If necessary, switch the default to the Floating state policy and perform the tests again.