Project

General

Profile

Bug #7116

a floating 'match' rule on LAN does not put traffic from a broswer on a clientpc into a shaper queue

Added by Pi Ba 3 months ago. Updated 12 days ago.

Status:
Confirmed
Priority:
Normal
Category:
Traffic Shaper
Target version:
Start date:
01/12/2017
Due date:
% Done:

0%

Affected version:
2.4
Affected Architecture:
amd64

Description

a floating 'match' rule on LAN does not put traffic from a broswer on a clientpc into a shaper queue.

Using Virtualbox on windows with pfSense version: 2.4.0-BETA (amd64) built on Thu Jan 12 07:45:16 CST 2017

Below most relevant rules shown. Changing the 'match' to 'pass' will show that the myq and myaq queue's do get some traffic then.

WANDESCRIPTIONFORINTERFACE = "{ em0 }" 
LANI = "{ em1 }" 
 altq on em1 hfsc bandwidth 100Mb queue {  qwe,  def,  myq,  myaq  } 
 queue qwe on em1 bandwidth 10Mb hfsc (  default  )  
 queue def on em1 bandwidth 20Mb hfsc (  default  )  
 queue myq on em1 bandwidth 5Mb 
 queue myaq on em1 bandwidth 15Mb 

 altq on em0 hfsc bandwidth 100Mb queue {  qwe,  def,  myq,  myaq  } 
 queue qwe on em0 bandwidth 10Mb 
 queue def on em0 bandwidth 20Mb hfsc (  default  )  
 queue myq on em0 bandwidth 5Mb 
 queue myaq on em0 bandwidth 15Mb 

match  in  quick  on {  em1  } inet proto tcp  from any to any tracker 1484177366 flags S/SA  queue (myq,myaq)  label "USER_RULE" 
pass  in  quick  on $LANI inet from { 192.168.132.0/22 10.10.10.1/32 } to any tracker 0100000101 keep state  label "USER_RULE: Default allow LAN to any rule" 

History

#1 Updated by Chris Collins 3 months ago

I confirm this behaviour.

#2 Updated by Renato Botelho 3 months ago

Have you tried to remove 'quick' from this match rule?

#3 Updated by Renato Botelho 3 months ago

  • Status changed from New to Not a Bug

According to docs you shouldn't use quick on match rules: https://doc.pfsense.org/index.php/What_are_Floating_Rules

It means your configuration is wrong. I'll close this ticket and it can be discussed on forum. If a real bug is found we can re-open.

#4 Updated by Pi Ba 3 months ago

Without quick it didn't work either. Only changing it to 'pass' made it work.

#5 Updated by Renato Botelho 3 months ago

  • Status changed from Not a Bug to New

#6 Updated by Jim Thompson 3 months ago

  • Assignee set to Renato Botelho

#7 Updated by Greg Siemon 3 months ago

Pi Ba wrote:

Without quick it didn't work either. Only changing it to 'pass' made it work.

I'm seeing the same behaviour (I think). I'm using PRIQ for my queues. A specific and repeatable example, is UDP traffic to VOIP providers. I have a match rule for UDP to/from the IPs of those providers in an alias and assigning the traffic to qVOIP. Only a few kilobytes of traffic gets assigned to the queue despite several MB of traffic being transmitted. Confirmed that the correct IPs (as per the state table) are involved. qVOIP under Firewall - Rules - Floating displayed only 30kb of Traffic as being matched. The state table showed >2MB of UDP traffic had been sent to the VOIP provider via UDP. No traffic was showing up in qVOIP during a call as per Status - Queues. Strangely, I have a qOthersHigh queue that is showing reasonable amounts of traffic in it. That queue mostly sees DNS traffic so its not completely broken.

#8 Updated by Michael Kellogg about 2 months ago

I too am seeing this bug

#9 Updated by Michael Kellogg about 2 months ago

this also affects 2.3.3 and 2.3.4 moved to 2.4 to get limiters fix

#10 Updated by Jakub Osika about 1 month ago

I too am seeing this bug. Fresh setup of traffic shaping using the wizard simply didn't work. All traffic was being poured into the "Default" queues:

QUEUE                 BW SCH  PRIO     PKTS   BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN   P/S    B/S
qACK                     priq    6        0       0        0        0    0                   0      0
qDefault                 priq    3   164355  26549K        0        0    0                   2    257
qGames                   priq    5        0       0        0        0    0                   0      0
qOthersHigh              priq    4        0       0        0        0    0                   0      0
qOthersLow               priq    2        0       0        0        0    0                   0      0
qLink                    priq    2   145183 134230K        0        0    0                   0      0
qACK                     priq    6        0       0        0        0    0                   0      0
qGames                   priq    5        0       0        0        0    0                   0      0
qOthersHigh              priq    4        0       0        0        0    0                   0      0
qOthersLow               priq    3        0       0        0        0    0                   0      0

However the moment I change the Action in the firewall floating rule for qOthersHigh from Match to Pass, it started working:

QUEUE                 BW SCH  PRIO     PKTS   BYTES   DROP_P   DROP_B QLEN BORROW SUSPEN   P/S    B/S
qACK                     priq    6      507   26871        0        0    0                   0      0
qDefault                 priq    3     1409  236954        0        0    0                  24   2990
qGames                   priq    5        0       0        0        0    0                   0      0
qOthersHigh              priq    4      108  109486        0        0    0                   0      0
qOthersLow               priq    2        0       0        0        0    0                   0      0
qLink                    priq    2     1374 1123756        0        0    0                   7    843
qACK                     priq    6        0       0        0        0    0                   0      0
qGames                   priq    5        0       0        0        0    0                   0      0
qOthersHigh              priq    4        0       0        0        0    0                   0      0
qOthersLow               priq    3        0       0        0        0    0                   0      0

Running SG-1000, 2.4.0.b.20170211.0742. Have not updated because current setup for everything else works and I don't want to break things _

#11 Updated by Dmitriy K about 1 month ago

I confirm this bug. In pfSense 2.4 no matter what you with Match floating rules do all traffic is being pushed into default queue. I've setup with a PRIQ shaper. Logging is on. Firewall tab has entries about floating rules being applied but nothing happens. In pfSense 2.3 same setup works flawlessly. Looks like something is broken in fbsd11.

#12 Updated by Dmitriy K about 1 month ago

Forgot to say: Indeed, Pass rule will place packets into related queue but it will break traffic.

#13 Updated by Kristopher Kolpin about 1 month ago

I think my bug is related too.

https://redmine.pfsense.org/issues/7409

#14 Updated by Chris Collins 23 days ago

Pass makes it work but of course it will also circumvent filtering on the firewall.
To make it work "and" not circumvent filtering then add the rules to LAN, not to the floating (until this problem gets resolved).

#15 Updated by Jakub Osika 15 days ago

I'm not sure if this helps, but the bug persists when:
  • Traffic shaper is deleted
  • A new shaper is created using the "dedicated" shaper wizard

Can confirm that this applies to PRIQ, CBQ and HFSC.

#16 Updated by Jim Pingle 15 days ago

  • Status changed from New to Confirmed

I'm seeing this now as well on 2.4. Just a basic run through the shaper, tell it to prioritize a couple things like HTTP/HTTPS, and traffic only shows in the default queue. Adjusting the rule to a floating pass/quick in/out rule on WAN+LAN puts traffic in the queue.

Maybe a pf patch for match/queue was skipped on 2.4/FreeBSD 11

#17 Updated by Renato Botelho 12 days ago

  • Assignee changed from Renato Botelho to Luiz Otavio O Souza

Over to Luiz

Also available in: Atom PDF