Classify pfSense DSCP traffic from the connection's first packet

A mark applied only after connection establishment may not influence the expected stateful classification.

Source facts

Netgate states that pfSense matches DSCP values but does not set or change them through this feature. Matching is exact across the six-bit field. With normal state handling, classification normally uses the packet creating the state, so a later mark change or a differently marked first packet can produce an unexpected queue assignment.

Source: Netgate — Traffic Shaping with Differentiated Services (DiffServ) Identifiers.

Applicability

This concerns the documented pfSense DiffServ matching behavior.

DSE recommendation

DSE recommends checking endpoint marking at connection establishment before changing firewall classification rules. Align the rule with the exact expected DSCP value and document which device owns marking. Avoid a no-state workaround merely to chase changing marks; the source warns that securely constructing such rules is difficult. Keep Layer 2 PCP and Layer 3 DSCP policies distinct even when they represent the same business traffic class. Include the initial packet in the endpoint evidence, rather than beginning capture after the conversation is underway. Ask the application owner to identify the intended marker at connection start. Compare a fresh correctly marked flow with the problematic flow before rewriting queue or firewall policy.

Verification

Capture a fresh approved connection from its first packet and compare DSCP values over its lifetime. Inspect the matched rule and queue for that connection. Repeat with an unmarked control flow and confirm that both classifications match the intended policy before drawing conclusions from aggregate interface throughput.

Official reference

Netgate — Traffic Shaping with Differentiated Services (DiffServ) Identifiers. Reviewed October 20, 2026.