Bug #7116
closed
a floating 'match' rule on LAN does not put traffic from a broswer on a clientpc into a shaper queue
100%
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"
Updated by Renato Botelho almost 8 years ago
Have you tried to remove 'quick' from this match rule?
Updated by Renato Botelho almost 8 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.
Updated by Pi Ba almost 8 years ago
Without quick it didn't work either. Only changing it to 'pass' made it work.
Updated by Renato Botelho almost 8 years ago
- Status changed from Not a Bug to New
Updated by
Updated by Greg Siemon almost 8 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.
Updated by Michael Kellogg almost 8 years ago
this also affects 2.3.3 and 2.3.4 moved to 2.4 to get limiters fix
Updated by Jakub Osika almost 8 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 _
Updated by Dmitriy K almost 8 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.
Updated by Dmitriy K almost 8 years ago
Forgot to say: Indeed, Pass rule will place packets into related queue but it will break traffic.
Updated by Kristopher Kolpin almost 8 years ago
I think my bug is related too.
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).
Updated by Jakub Osika over 7 years ago
- Traffic shaper is deleted
- A new shaper is created using the "dedicated" shaper wizard
Can confirm that this applies to PRIQ, CBQ and HFSC.
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
Updated by Renato Botelho over 7 years ago
- Assignee changed from Renato Botelho to Luiz Souza
Over to Luiz
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.
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.
Updated by Luiz Souza over 7 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Fixed in the latest snapshot.
Updated by Pi Ba over 7 years ago
Seems to work properly for my test box. Thanks!
Updated by Greg Siemon over 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?
Updated by Jakub Osika over 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!
Updated by Luiz Souza over 7 years ago
- Status changed from Feedback to Resolved
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
Updated by Adam Esslinger over 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