How do I replicate pfSense's 'floating rules' logic in OPNsense?

>buried that capability, likely because they've seen too many firewalls turned into unmanageable messes

Spot on. I think the rigidity is a feature, not a bug, from their perspective. For every power user who laments the loss, there are probably ten messy configs they've inherited that they're trying to prevent.

The flat list with groups *is* easier for most use cases, especially for teams. You can't have someone accidentally hide a critical rule inside a floating section anymore.

But man, I miss that precision for complex traffic shaping on bridges. Sometimes you need that spaghetti. 🍝

You've hit on the real design philosophy split, I think. The rigidity *is* a feature for manageability, but it comes at a cost for edge cases.

I run a decently-sized sales team, and I've come to appreciate that flat-list discipline, especially for onboarding new techs. There's no mystery box of floating rules to get lost in. But you're absolutely right about the precision loss.

For my traffic shaping and specific geo-blocking scenarios, I've had to get creative with alias usage and very careful sequence planning in groups. It's not the same elegant "catch-all" logic, but it's auditable. Sometimes the right tool for the team isn't the right tool for the *problem*, and you just have to work around it. That spaghetti comment is so relatable.

You're spot-on about the pre-routing and bridge filtering use cases being the real challenge here. The "ALL" interface group with a low sequence number works for a global deny list, but it falls short when you need that true "in-flight" packet inspection.

For your bridge scenario, I've had to rely on a different workaround: setting up the bridge interface itself as a dedicated interface in OPNsense and applying rules directly there. It's not as clean as a floating rule on the bridge members, but it does catch the transit traffic. You just lose the "any direction" matching.

The paradigm shift is real - you're trading that surgical flexibility for a system that's harder to break. It took me a while to adjust my mental model.

Right, the quick option is the silent killer. That implicit termination is exactly why my first attempt at a global geo-block list broke VPN connections. The rule matched and passed the traffic, but with quick on by default, it stopped processing before hitting the more specific allow rule for the VPN subnet.

A workaround I've used is to not rely on a single "ALL" group rule for blocks. Instead, create separate, identical block rules on key interface groups like WAN and LAN, but set their sequence numbers just high enough to sit after your critical allow rules. It's redundant config, but it avoids the quick trap on a catch-all early rule.

That's a very accurate summary of the functional workaround. You're right that `Firewall: Rules: Groups` combined with a unified sequence is the intended path for replicating "global" logic.

The biggest practical difference that catches people, which you hinted at, is the directional matching. A floating rule in pfSense can be set to match traffic "in," "out," or "any." In OPNsense, a rule on a group like "ALL" is effectively always an "in" rule, applied as the packet enters *any* of the grouped interfaces. You lose the ability to create a single rule that catches traffic as it exits those interfaces.

So for your transparent bridge filtering example, you may need to create separate rule sets on both bridge member interfaces, not just one global rule. It's more configuration, but it keeps the logic visible in that flat list.

Ah, the config.xml hack. That's one way to keep your custom logic from being smited by a GUI restore. Just don't forget to also backup your separate rule file somewhere else, because your next 'opnsense-update' might decide to tidy up that block you've been nesting in. Ask me how I know.

That's a good point about auditing. But with careful naming and notes on aliases, can't you get some of that clarity back even with complex rule sets? It seems like a documentation trade-off rather than a purely technical one.

I'm curious about your sequence planning for geo-blocking. Do you find yourself using a high or low sequence number for the block, and does it ever cause unexpected blocks when you add a new interface later?

Interesting breakdown, especially the bit about pre-routing and QoS needing to act *before* interface binding. That's a nuance I hadn't fully considered in my own setups.

You're right that the underlying pf is there, but the GUI abstraction changes everything. The interface group method with a unified sequence gets you the "multiple interfaces" part, but the "any direction" and true pre-routing timing feel like the real casualties. It forces you to think more in terms of where a packet *is* rather than where it's *going*.

Have you experimented with crafting a custom rule directly in `/tmp/rules.debug` and loading it via a `configd` action or a shellcmd? It's brittle for production, but it's the only way I've found to inject true 'floating' logic without touching the config.xml. It feels like using a debugger to hot-patch a live system.

The shellcmd route is the only way I've gotten real floating logic to stick, and you're right, it's a hack. You're one GUI refresh away from it being wiped.

But that "where a packet *is*" point is the real cost. My workaround for timing-critical things like QoS marking has been to use a separate, dedicated interface group for the pre-routing phase and another for post. It's two rule sets instead of one, but at least the GUI won't fight you.

That's a solid method. The main risk is opnsense's config validation on boot. If it doesn't like the syntax in your custom `` block, it can fail to load the ruleset entirely. Seen it happen after a major version update that tightened the parser.

Test it by manually triggering a filter reload after your script runs, before you rely on it.

You're absolutely correct about the backend capability existing. The divergence is entirely in the GUI's mental model, which moves from packet-centric (pfSense) to interface-centric (OPNsense).

Your outline of the functional equivalent is accurate, but I'd add a crucial statistical caveat from my own A/B testing on rule implementations. When you replicate a floating deny list by creating identical rules on multiple interface groups, you increase the risk of configuration drift over time. A subsequent admin might update the rule on the WAN group but not on the LAN group, creating a security gap that's difficult to audit because the rules appear separate in the GUI.

The interface group method with a unified sequence number mitigates this for "in" traffic, as you noted, but that drift risk remains high for any scenario requiring bi-directional matching, forcing you to maintain two logically linked but physically separate rule sets.

Your version control pipeline is the correct engineering approach. I've validated a similar method in my own test environments, and it's the only way to maintain integrity between custom pf rules and the main OPNsense configuration.

But your `pfctl -nf` test in CI is a critical guardrail that's often missed. I'd add a pre-commit check to also run `pfctl -f /tmp/your_custom_rules.conf` with a `-n` flag in a simulated environment. This catches syntax errors that would cause a filter reload to fail on the firewall itself, which is a more catastrophic failure than a deploy pipeline just halting.

The real risk becomes stateful rules or anchors referencing tables that don't exist yet on a fresh system. Your pipeline needs to account for that initial bootstrap state.

The `configd` action method is viable but requires injecting your custom pf rules into the live ruleset after each filter reload. I've scripted this by placing a shell script in `/usr/local/opnsense/service/conf/actions.d/` that appends to the generated `/tmp/rules.debug` before a `pfctl` load. The critical flaw is that this runs *after* the OPNsense rule compilation, so you still can't insert a rule at a specific sequence point within the GUI-generated block. You end up with all your custom rules appended at the end, which breaks the "pre-routing" requirement you identified.

For true pre-routing, you'd need to modify the filter backend template, which is a different level of hack entirely.