Make pfSense floating-rule Quick behavior explicit

Floating rules can use last-match behavior, so an early visual position alone does not settle the outcome.

Source facts

Netgate explains that Quick stops further rule processing after a floating-rule match. Without Quick, a later matching rule can determine the result. Outbound floating rules on a WAN see the post-NAT source address; an inbound tag can preserve the association needed to match a particular internal workload later.

Source: Netgate — Floating Rules.

Applicability

This applies to pfSense floating rules and their direction-specific packet view.

DSE recommendation

DSE recommends recording the intended first-match or last-match design in each advanced rule’s description. Use ordinary interface rules when they express the requirement clearly. For an outbound rule intended to affect one internal host, establish which address it will actually see and consider an inbound tag rather than matching an address already translated away. Keep the tagging rule and consuming rule linked in the change record so a later cleanup does not silently detach them. For a last-match design, nominate the later rule expected to win and test a packet matching both entries. Retain the Quick setting and tag relationship with that result; a screenshot of rule order without those properties is insufficient for acceptance.

Verification

Generate separate approved test flows from the targeted host and an untargeted peer. Review rule counters, the translated source, and the final pass or block result. Repeat after a fresh connection so an existing state is not mistaken for the new rule’s decision.

Official reference

Netgate — Floating Rules. Reviewed October 20, 2026.