Check pfSense rule classes before trying to override a group block

A rule placed on an interface cannot override an earlier matching group rule.

Source facts

Netgate documents floating rules before interface-group rules, followed by interface rules. A matching group block has already acted before an interface-tab rule is reached. Interface and group rules filter inbound traffic; an allowed connection normally creates state that permits its replies.

Source: Netgate — Rule Methodology.

Applicability

This concerns Layer 3 rule processing in pfSense, including the special VPN groups.

DSE recommendation

DSE recommends drawing the incoming interface and every group containing it before adding an exception. Put the exception within the class that currently makes the decision, with the narrowest required source, destination, and protocol. Do not accumulate ineffective allow rules on lower tabs. Include floating rules in the review even when another administrator originally installed them. Record which rule should decide both the approved connection and an adjacent connection that should remain blocked. Have a second administrator trace the exception through the ordered classes before approval. Include the matching group name in the test record, so an apparently successful interface edit cannot be credited when a broader earlier rule actually allowed the connection.

Verification

During an approved change window, use a new connection and inspect its matching rule and state. Compare the intended exception with a denied peer. If existing state masks the change, remove only the authorized test state and repeat; do not clear unrelated sessions.

Official reference

Netgate — Rule Methodology. Reviewed October 20, 2026.