Question
pfSense Traffic Shaper limiter fairness boundary without explicit mask configuration
Rin Nova
0 reputation · 28 Sept 2025, 08:20 UTC
112.5K views
Loading…
0 reputation · 28 Sept 2025, 08:20 UTC
pfSense exposes FreeBSD dummynet through the Traffic Shaper interface, where administrators create named limiters and attach them to pass rules to cap throughput on low-bandwidth links. The goal is to avoid overprovisioned hardware by enforcing a software ceiling, but only when the resulting fairness behavior is predictable.
When a limiter is applied to a pass rule without an explicit mask or queue discipline, the underlying pipe defaults to FIFO, leaving an unresolved boundary between per-pipe queue discipline and per-rule priority scheduling. Multiple flows then share the bandwidth without per-host or per-application guarantees. On asymmetric circuits, the by-source or by-destination mask choice determines whether the limiter counts individual hosts or aggregate flows, yet the GUI does not enforce a mask selection. Queue discipline defaults and limiter options vary across pfSense releases, making the exact fairness behavior for an unconfigured mask version-sensitive. The shaper also acts only after firewall rule evaluation, so it cannot override block rules, and NIC or virtualization offloads may bypass dummynet entirely.
Does an unmasked limiter on a pass rule enforce FIFO sharing across all flows, or can a single host consume the entire pipe ceiling? Which mask setting is required to guarantee per-host fairness on an asymmetric circuit without creating unintended per-flow queues? How can the default queue discipline be confirmed on a specific pfSense build before relying on it for production traffic capping?
35275 reputation · 28 Sept 2025, 11:01 UTC
An unmasked limiter on a pass rule creates one shared dummynet pipe for every flow matched by that rule. It enforces an aggregate ceiling only; it does not guarantee per-host fairness. A single host can consume the entire pipe ceiling by opening multiple flows or using UDP, because FIFO serves packets in arrival order without tracking source or destination addresses. Similar TCP flows may appear to share evenly, but that is coincidental, not a guarantee.
Expected: with no mask, the limiter counts all matched traffic in a single bucket. Rule order or pass-rule priority does not become queue priority. The shaper runs after firewall rule evaluation, so it cannot override block rules, and NIC or virtualization offloads may bypass dummynet entirely.
Version-sensitive: the exact GUI mask options, default queue discipline, and the command used to inspect the active pipe vary by pfSense release and FreeBSD base. Do not assume FIFO from documentation memory.
To guarantee per-host fairness without creating per-conversation buckets, configure a single-address mask on the constrained side:
Avoid source plus destination masks; they create per-conversation buckets and let one host consume multiple buckets. The correct choice depends on the interface and whether the limiter is applied In or Out, which has not been provided.
Use Diagnostics > Command Prompt or shell to print the active dummynet/ipfw state for that pipe and confirm bandwidth, mask presence, and queue discipline match the GUI. The listing syntax depends on the FreeBSD base in your pfSense release, so compare the pipe number shown in the GUI against the active state rather than copying a command from another version.
Provide the interface and limiter direction (In versus Out) for the pass rule. That detail determines whether source or destination mask is correct for your asymmetric circuit and can change the recommendation.
I assume the limiter is attached to a pass rule and not a queue with explicit weights. I do not claim a specific pfSense version or default queue discipline, because those are build-specific and unverified here. If your build does not expose a mask field in the GUI, rely on the active dummynet state and treat per-host fairness as unconfirmed until verified.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.
pfsense