Floating rules — purpose and multi-interface matching

Per-interface rules are the bread and butter of OPNsense firewalling: one rule list per interface, packets on that interface evaluated against that list. They are simple, predictable, and sufficient for most needs. They are also limited: a rule on the LAN cannot match packets on the DMZ, a rule on the WAN cannot match packets leaving the LAN, and a rule that needs to apply in both directions across multiple interfaces requires duplicating itself four times.

Floating rules exist for the cases per-interface rules cannot express. A floating rule can match packets on multiple interfaces, in either direction, with conditions per-interface. They are a different kind of object with a different evaluation position in the ruleset.

What a floating rule is

A floating rule lives at Firewall → Rules → Floating. It has the same fields as a per-interface rule (action, source, destination, port, etc.) but adds three more: Interface(s), Direction, and a set of advanced toggles (Quick, State, Allow options, Schedule).

The rule above matches SSH traffic from the management IPs arriving on any of three interfaces. Per-interface rules would require three separate rules (one per interface), each on the correct interface’s rule list. The floating rule expresses the same intent once.

$ pfctl -s rules | grep -E '@9[0-9]+|@1[0-9][0-9]'

@92 pass in quick on igb0 inet proto tcp from <management_ips> to any port = 22
@95 pass in quick on igb1 inet proto tcp from <management_ips> to any port = 22
@98 pass in quick on igb2 inet proto tcp from <management_ips> to any port = 22

When floating rules are the right tool

Four production patterns dominate:

• Multi-interface rules. A rule that should match the same condition on multiple interfaces.
• Direction-aware rules. A rule that should match outbound on one interface and inbound on another.
• Global anti-spoofing and bogon blocking. Block traffic that should never appear on the WAN or DMZ.
• Log-only rules. A floating rule with action pass and Log enabled, no other effect.

Floating rules are not for everything. The cost is more complex evaluation order, and a floating rule that matches many interfaces can shadow per-interface rules below it if not positioned carefully.

The Interface(s) field

The Interface(s) field is the most distinctive feature. It accepts a list of interfaces. A floating rule that lists LAN, DMZ is injected at both the LAN and DMZ rule lists, in the same relative position.

The matching semantics:

• Any-of. A packet matches the rule if it is on any of the listed interfaces. The interfaces are OR’d, not AND’d.
• Direction-aware. The Direction field determines whether the rule matches inbound or outbound packets on the listed interface(s).
• No implied cross-interface logic. A floating rule does not match packets that traverse from one listed interface to another.

The Direction field

Floating rules have three Direction options:

• In. The rule matches packets arriving on the listed interface(s), regardless of where they are going.
• Out. The rule matches packets leaving on the listed interface(s), regardless of where they came from.
• Any. The rule matches packets in either direction on the listed interface(s).

The default is in. Most floating rules are inbound.

Quick and non-quick floating rules

Like per-interface rules, floating rules can be quick (the default) or non-quick. The semantics are the same: a quick rule stops evaluation on match; a non-quick rule allows evaluation to continue, with the last matching rule deciding.

For floating rules, the choice has additional implications. A non-quick floating rule that matches a packet does not decide for that packet; evaluation continues to the next rule (which may be another floating rule, a per-interface rule, or the implicit block). This is the basis of “log only” floating rules.

A quick floating rule that matches a packet decides immediately. This is the standard case. Be careful with broad quick floating rules — they shadow per-interface rules below them in the ruleset.

Order: floating rules vs interface rules

Floating rules evaluate in the position determined by the GUI. The generated ruleset has the floating rules at the top, then per-interface rules, then defaults.

The order can be controlled more granularly with the Sequence field on the floating rule (pre-sequence or post-sequence for older OPNsense versions). This places the floating rule before or after all per-interface rules on the listed interfaces. Pre-sequence floating rules are evaluated first; post-sequence are evaluated after per-interface rules.

Floating rule anti-patterns

Three patterns cause incidents:

• The “permit any on every interface” floating rule. A floating rule that permits all traffic on all interfaces, intended as a fallback for an unknown interface, silently shadows every per-interface rule below it.
• The floating rule for a single interface. A floating rule that lists only one interface and has no direction or sequencing that a per-interface rule could not express.
• The floating rule with a complex match no other rule needs. A floating rule that uses advanced matching that no per-interface rule on the firewall needs.

Summary

• Floating rules match multiple interfaces in a single GUI entry. They compile to one PF rule per interface.
• Use floating rules for multi-interface rules, direction-aware rules, global anti-spoofing, and log-only rules.
• The Interface(s) field is OR’d. The Direction field determines inbound, outbound, or any.
• Floating rules evaluate in the GUI order, with pre-sequence and post-sequence positions controlling relative placement.
• quick on a floating rule stops evaluation on match. Non-quick floating rules are useful for logging.
• Verify floating rules with pfctl -s rules after every change.