Project

General

Profile

Actions

Bug #7116

closed

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

Added by Pi Ba over 7 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Traffic Shaper (ALTQ)
Target version:
Start date:
01/12/2017
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
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" 

Actions #1

Updated by Chris Collins over 7 years ago

I confirm this behaviour.

Actions #2

Updated by Renato Botelho over 7 years ago

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

Actions #3

Updated by Renato Botelho over 7 years 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.

Actions #4

Updated by Pi Ba over 7 years ago

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

Actions #5

Updated by Renato Botelho over 7 years ago

  • Status changed from Not a Bug to New
Actions #6

Updated by Jim Thompson over 7 years ago

  • Assignee set to Renato Botelho
Actions #7

Updated by Greg Siemon over 7 years 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.

Actions #8

Updated by Michael Kellogg over 7 years ago

I too am seeing this bug

Actions #9

Updated by Michael Kellogg over 7 years ago

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

Actions #10

Updated by Jakub Osika over 7 years 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 _

Actions #11

Updated by Dmitriy K over 7 years 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.

Actions #12

Updated by Dmitriy K over 7 years ago

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

Actions #13

Updated by Kristopher Kolpin over 7 years ago

I think my bug is related too.

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

Actions #14

Updated by Chris Collins over 7 years 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).

Actions #15

Updated by Jakub Osika over 7 years 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.

Actions #16

Updated by Jim Pingle over 7 years 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

Actions #17

Updated by Renato Botelho over 7 years ago

  • Assignee changed from Renato Botelho to Luiz Souza

Over to Luiz

Actions #18

Updated by John Holcomb over 7 years ago

Adding that I found this while when upgrading from 2.3 to 2.4

My setup is : WAN -> VLAN10 -> pfsense computer with single gigabit port -> VLAN 1 -> LAN

This works fine for most things, but the HFSC queues that were working correctly in 2.3 aren't working in 2.4.

I realize this is confirmed, but just wanted to add more data.

Actions #19

Updated by Bipin Chandra over 7 years ago

Suffering same, any plans this would get fixed soon because converting rules to a pass isn't feasible in my situation and after noticing this issue I would have to move to 2.3 till this is fixed. Few of my clients on sg1000 so no idea what I would do about that.

Actions #20

Updated by Luiz Souza about 7 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

Fixed in the latest snapshot.

Actions #21

Updated by Pi Ba about 7 years ago

Seems to work properly for my test box. Thanks!

Actions #22

Updated by Greg Siemon about 7 years ago

I can now see traffic in all of the queues where there should be traffic. It does indeed seem to be fixed. Any chance you could point us to the actual fixes in Git?

Actions #23

Updated by Jakub Osika about 7 years ago

I can also confirm that the issue seems fixed. Steps taken:

  • Deleted all shaping firewall rules
  • Deleted traffic shaper
  • Went through trafic shaper creation wizard with HFSC selected for up and down
  • Manually reset state table
  • Setup downloads on port 80 and port 81 both downloads were placed into correct queues
  • General "chatter" from various other programs could be seen being placed into various queues

Thank you!

Actions #24

Updated by Luiz Souza about 7 years ago

  • Status changed from Feedback to Resolved
Actions #25

Updated by Kristopher Kolpin about 7 years ago

Seeing bug 7116 again with squid and any other traffic originating from the firewall. Cannot place it into any kind of shaper with match or pass rules. Just ends up in default queue.

pfSense 2.4.0.r.20170927.1221

squid 0.4.39

Actions #26

Updated by Adam Esslinger about 5 years ago

Im seeing this issue also on 2.4.4-RELEASE-p3 (amd64). I have several queues setup and sometimes traffic ends up in the correct queue and sometimnes traffic doesn't appear in any of the queues including the default queue. The only work around I have found at this time is to schedule a CRON job that reloads the filters. /etc/rc.filter_configure

Actions

Also available in: Atom PDF