Bug #3726


Firewall Rule with Diffserv Code Point not matching properly

Added by James Dietrich over 9 years ago. Updated over 8 years ago.

Not a Bug
Operating System
Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


I am using 2.1.4.

I have set up some simple traffic-shaping, and have several Floating firewall rules to send various types of traffic to the several queues I have set up. This is all working fine.

For example, consider this rule (in /tmp/rules.debug):
match inet proto tcp from any to any port 22 flags S/SA queue (qMedium,qACK) label "USER_RULE"
This works fine; when I am using scp to upload a file, pftop shows that the traffic is being put in the qMedium queue.

However, the problem comes when additionally trying to match on a Diffserv Code Point. I edited the above rule in the gui and under Advanced features also required it to match on the 0x02 Diffserv Code Point. That yielded this rule (in /tmp/rules.debug):
match inet proto tcp from any to any port 22 dscp 0x02 flags S/SA queue (qMedium,qACK) label "USER_RULE"
Now pftop shows that scp upload traffic goes into the default queue--qDefault, which indicates to me that it isn't matching this rule anymore.

I took a packet capture while the scp upload was going on, and I can see that the scp upload packets have a DSCP value of 0x02, so it seems to me that they should match the rule with "dscp 0x02" in it.

I have attached screenshot showing the DSCP value of an example packet.

If any more information would be helpful, or if there's anything else you'd like me to try, please let me know.

Thank you.
James Dietrich


wireshark_dscp.png (92.5 KB) wireshark_dscp.png James Dietrich, 06/30/2014 10:46 AM
Actions #1

Updated by Chris Buechler over 8 years ago

  • Category set to Operating System
  • Status changed from New to Feedback

I recall an issue along these lines that was fixed in 2.2.x. This something you can replicate on 2.2.4?

Actions #2

Updated by James Dietrich over 8 years ago

I did replicate this on 2.2.4, but having looked at this again I now know what the problem is, and it's not a bug in pfSense. The large scp upload packets do indeed have a DSCP value of 0x02, but the initial packet that sets up the state has a DSCP value of 0x00. Back when I submitted this bug report I must have thought that each packet would be examined and queued according to the rules I had set up, but now I know that's not what happens. I used ping -Q to test, and pfSense matches a DSCP value just fine. I'm sorry for the misunderstanding, and this bug report can be closed.

Actions #3

Updated by Chris Buechler over 8 years ago

  • Status changed from Feedback to Not a Bug

Yeah that's the expected behavior in this case. Thanks for the follow up!


Also available in: Atom PDF