DSCP values not matching packets in Floating rules. Legacy CS values do match
ACiD GRiM last edited by ACiD GRiM
I have DSCP tagging for some services, and can confirm they are in packet transfers:
Differentiated Services Field: 0x98 (DSCP: AF43, ECN: Not-ECT)
However I do not see them entering the packet queue, and if I set the rule to log on match, I don't see any log entry.
OSPF packets with CS6 DSCP value 0xc0 are correctly moved in to the specified queue
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
In my floating rules, I have CS6 assigned to a queue, and then I have af43 assigned to a queue in separate match rules.
All traffic goes to the default queue, except for some OSPF traffic, what am I missing?
Edit: After testing with iperf3 and setting dscp to cs6 and confirming via packet capture, I've found that the matching is not happening at all, as the iperf flow was assigned to queue 0.
At this point I don't see why the OSPF traffic is getting classed as CS6 and iperf traffic is not when they're classed the same.
pf creates a state based on the first packet of a connection. Thus in normal rules, the DSCP bits are only checked for queuing in the first packet. If the bits change in later packets, the queue is not updated since the state table is passing the traffic at that point, not the rules.
The only real workaround here is an ugly one, which is to create floating rules for each direction of traffic (inbound and outbound on each interface it passes) to pass it and check the DSCP bit but without keeping state. This creates a much higher load for the firewall though since it has to inspect the ruleset for each packet matching the rule rather than using the (much faster) state table check.
ACiD GRiM last edited by ACiD GRiM
Is there a difference between "a rule for each DSCP value directions" and a rule with "both" in the direction?
I read the documentation and have attempted to set the state to none, is that as simply as setting the state type to none.
In the XML as "<statetype><![CDATA[none]]></statetype>"
I did the above and while I get a small trickle of data in the queues most of the time, I have not made an individual rule for each direction. Is that all that remains for this to work?
So I created a rule for each direction and I'm not really seeing any more queue assignment than I did with the "both" rules.
I'm specifically trying to get ssh on port 4620 traffic thats tagged as af13, which doesn't seem to be assigned to any queue if the rule has none state or keep state configured on the af13 match rule. this is assigned to both Wan and Lan interfaces. and the packet capture on both interfaces shows the tagged traffic with af13. I've attached my rules in a screenshot.
Just assume each DSCP class is assigned to prio 1-13, and CS 6 and 7 are assigned to 14 and 15
Duplicates are because of in and out rules, and cs1-5 are doubled with AF 11 , 21 , 31, 41 since I want them in the same queue.
Here's the raw XML from one rule
<rule> <id></id> <tracker>1535275020</tracker> <type>match</type> <interface>wan,lan,opt1,opt2,openvpn</interface> <ipprotocol>inet46</ipprotocol> <tag></tag> <tagged></tagged> <direction>any</direction> <quick>yes</quick> <floating>yes</floating> <max></max> <max-src-nodes></max-src-nodes> <max-src-conn></max-src-conn> <max-src-states></max-src-states> <statetimeout></statetimeout> <statetype><![CDATA[keep state]]></statetype> <os></os> <source> <any></any> </source> <destination> <any></any> </destination> <dscp>cs7</dscp> <descr></descr> <defaultqueue>Prio15</defaultqueue> <created> <time>1535275020</time> <username>admin@fd00:f9a8:0:10:9990:ddd0:44ec:3d06</username> </created> <updated> <time>1535277494</time> <username>admin@fd00:f9a8:0:10:9990:ddd0:44ec:3d06</username> </updated> </rule>
My goal here is to assign DSCP classed traffic to queues instead of creating rules for traffic. I want my upstream switch hardware to be the classification source, and pfsense to just process the data according to my queues.h