Just ran into this issue.
When the Limiter is disabled, you will be unable to determine it is actually set on a Rule.
Enable the Limiter, and you'll be able to find it on Rules and remove it.

This is probably the best place to start:

https://docs.netgate.com/pfsense/en/latest/book/firewall/rule-methodology.html

Unless your coffee pot is networked - then it too should be updated!

Do you not update your OS or your virus scanner software?

@tman222 Thank you. This was the failure. Now it works.

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
Screen Shot 2019-10-11 at 10.45.04.png

using netcat on port 443, traffic is sent to the default queues.
cat bigfile.dat | nc myhost 443
Screen Shot 2019-10-11 at 10.47.25.png

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

Lan rule 1570715403 sets the tag. 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?

@manu77 ,

I have selected the appropriate wan interface in each rule (in-rule and out-rule for each wan interface) - in the WanIn/Out rules I have selected only the wan interface, and in the corresponding wan2 rules I have selected only the wan2 interface.

Good luck with any further testing:-)

Hello All,

Somebody has found a solution ?

Another topic is near this one .
I tested exactly what you 're speaking about wihout any success !!

https://forum.netgate.com/topic/140609/problems-with-flexible-limiters-set-using-floating-rules

thanks

Hi @RedDelPaPa - It depends. How fast if your internet connection? If you have a higher speed connection a queue size of 50 might just be too small. If you do end up increasing the queue size, I would recommend also enabling queue management using Codel to make sure that you don't end up with bufferbloat. Having a high priority on the queue's traffic will naturally mitigate some of that, but enabling AQM will also help.

Hope this helps.

This question might be better asked in the pfBlockerNG forum.

Limiters would be difficult to use here since I'm not aware of a way to have those dynamically adjust based on some type of feedback mechanism (e.g. latency, bandwidth, time of day, etc.)

You might try some ALTQ traffic shaping algorithms / techniques instead to prioritize traffic accordingly. Here is some more info on that:

https://docs.netgate.com/pfsense/en/latest/trafficshaper/traffic-shaping-guide.html
https://www.youtube.com/watch?v=rF46PNid1Mo (long but worth watching)

Hope this helps.

Sorry to bring up such an old topic, did you manage to resolve the issue?

Status > Monitoring is your friend there.

If you have created VLAN-based networks and assigned them to any LAN interface (ix0-ix3) but also assigned any of the interfaces directly (for example, ix0 for VOIP), the ones used directly will be excluded from the Traffic Shaper Wizard.

The solution is to use VLANs only but leave all interfaces ix0-ix3 unassigned.

This seems to be the case for SG-5100 but not for others like SG-3100 (I have both).

Mixing of VLAN and direct assignment is not recommended due to security implications, but why it is excluded from Traffic Shaping wizard I am not sure. It seems to be allowed for SG-3100 although it does have a separate switch so it may not be apple-to-apple comparison.

NOTE: The above is what I had to do in my setup; if you don't use VLANs though then the above would not apply and something else would be to blame.

I added some DNS exceptions rules in front of my shaper rules :

dd8edc61-e2d9-4177-be57-4adf0fca8afb-image.png

The first rule is matched when unbound connects to any DNS server on the net, using IPv4 or IPv6, UDP or TCP, destination port 53.
The second one matches when unbound send s out some DNS traffic on my LAN interface, source port is then '53'. (Destination could be anything above 1024).

The counters show that these rules are matching traffic.

Said all this, I still think your issue isn't shaper related.
Unbound can't connect to "192.168.4.59 - port 1855" : it could be anything, even hardware related.

Lightsquid does reporting based on squid's access log.

Oh dah... thx