[Solved] floating rules assigning queues differently depending on traffic

[allan34]

This was a problem with my lack of fundemental understanding of how traffic is directed to the queues specified in the rules and the role of the ackqueue.

Through a combination of running the wizard for multiwan, the pf.conf man page, and some experimentation all became clear. The following is what was observed:

When the floating rule sets both the ack-queue and the queue.
Traffic is directed to the "queue" on both the WAN and the LAN side. Additionally, packets with a ToS of lowdelay or ACK packets without payload are directed to the "ackqeueue", again this is on both WAN and LAN interfaces,

Which means queues on the LAN and WAN must be named the same.

In the case of the rule only specifiing a queue and no ack queue then packets are directed to this queue on both WAN and LAN interfaces.

If a queue does not exists of that name then the default queue is used.

[I was misunderstanding the role of the ackqueue ]

pf.conf man page:

     queue <queue> | (<queue>, <queue>)
	   Packets matching this rule will be assigned to the specified	queue.
	   If two queues are given, packets which have a TOS of	lowdelay and
	   TCP ACKs with no data payload will be assigned to the second	one.

Here's the queues:

And the floating rules:

From this a multiwan setup is being tested, duplicating the queues and renaming WAN to WAN1, WAN2, WAN3 etc on both the LAN and WAN sides. So far things are looking good.

---- Original Post Below ----

Would really appreciate some help. Not sure if this is a bug or something else.

The aim is to use floating rules on the WAN interface to assign traffic to hfsc queues based upon tags set in the LAN rules.

The problem is for example https traffic generated using curl, the floating rule needs to specify the queues like this :

And all works as expected.

However traffic generated by netcat on port 1935 to a remote server needs the queue to be specified in the reverse order e.g.

Have been testing this in a clean install on pfsense 2.4.4_p3 after not being able to make sense of things in the production firewall and the same behaviour is seen in both.

the queues...

and the floating rules....

match  out log  on {  em0  } inet from any to any  tagged "streaming" tracker 1570689231  queue (qWAN_up_streaming,qWAN_down_streaming)  label "USER_RULE: Assign to streaming queue"
match  out log  on {  em0  } inet from any to any  tagged "low" tracker 1570687650  queue (qWAN_down_low,qWAN_up_low)  label "USER_RULE: Assign to low queue"
match  out log  on {  em0  } inet from any to any  tagged "high" tracker 1570691426  queue (qWAN_down_high,qWAN_up_high)  label "USER_RULE: Assign to high queue"

The "streaming" rule has the qWAN_down / qWAN_up where as the others have the order reversed... qWAN_up / qWAN_down. This is the order as shown in the gui. The rules debug file has them in the reverse order.

And a screen shot of the rules summary....

Test1:
Use netcat to connect to a remote host on port 1935, and using a LAN rule to tag the traffic "streaming" all looks well as the traffic is assigned to the correct queue...

Test2:
Same as test 1 but change the LAN rule to tag the traffic as high and the traffic ends up in the default queues...

Test3:
Use curl to generate some https traffic which is tagged as "high". And the same floating rule as test2 assigns the traffic to the expected queues...

Test4:
Use curl to generate some http traffic which is tagged as "low". And the floating rule assigns the traffic to the expected queues...

Tagging http or https as "streaming" leads to the traffic being assigned to the default queue.

The logs show that the floating rules and lan rules are being matched as expected.

Any one any ideas?

Thanks in advance. Allan

[edited to make the question clearer]

[allan34]

A further test comparing https using curl and netcat also on port 443.

curl https works as expected with the traffic on the "low" queue

using netcat on port 443, traffic is sent to the default queues.
cat bigfile.dat | nc myhost 443

And the log files show the same rules are being hit in both cases....

1. Lan rule 1570715403 sets the tag.
2. Floating rule 1570687650 on the WAN interface assigns the queues.....

curl - filter.log

Oct 11 10:51:55 pftest1 filterlog: 74,,,1570687650,em0,match,unkn(%u),out,4,0x0,,63,17834,0,DF,6,tcp,60,10.10.192.2,193.198.104.3,57884,443,0,S,2068721621,,29200,,mss;sackOK;TS;nop;wscale

netcat - filter.log

Oct 11 10:49:06 pftest1 filterlog: 74,,,1570687650,em0,match,unkn(%u),out,4,0x0,,63,49798,0,DF,6,tcp,60,10.10.192.2,10.10.32.158,41816,443,0,S,3570078997,,29200,,mss;sackOK;TS;nop;wscale

From what I know these two look identical. So why would pf react differently to these?

[allan34]

This post is deleted!