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 about 2 months ago. Updated 19 days ago.

Status:
New
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 about 2 months ago

I confirm this behaviour.

#2 Updated by Renato Botelho about 1 month ago

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

#3 Updated by Renato Botelho about 1 month 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 about 1 month ago

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

#5 Updated by Renato Botelho about 1 month ago

  • Status changed from Not a Bug to New

#6 Updated by Jim Thompson about 1 month ago

  • Assignee set to Renato Botelho

#7 Updated by Greg Siemon 19 days 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.

Also available in: Atom PDF