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 : [image: 1567088623012-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

@KOM ok thanks will try that

I would tend to do it the way that Netgate suggests you do it. Put your shaping rules on WAN.

@Digital-Storm What you are running into is this: https://docs.netgate.com/pfsense/en/latest/routing/troubleshooting-traceroute-output.html Not specific to the use of FQ-CoDel but rather the use of policy routing in your egress floating rules. Use this guide and you should be good to go: https://forum.netgate.com/post/807490

I will have to check it out, thanks!

Based on my limited knowledge it is working as designed. This is based on a single queue and scheduler; you have to setup dynamic limiters to see the individual traffic streams. Dynamic limiters would negate the benefits of FQ-Codel and/or Codel since each clients stream would be separate from the rest which would prevent the magic of Codel from happening since it would only see single streams.

@wormuths [image: 1561849591175-p2p.png]

@Morad__T - Why not setup a limiters for this particular host / IP and then apply them to a new LAN firewall rule that controls outbound (i.e. internet bound) traffic for just that host / IP (be sure to place it above the rule that controls outbound i.e. internet bound traffic for the rest of the hosts of the LAN). If you want to make sure that LAN traffic (which passes across the firewall) is not limited for that host / IP, place one or more additional rules above that newly created rule (that has the limiters applied), with the source being that host / IP and destination being whichever LAN / subnet you don't want speed limited. Remember firewall rules are evaluated from the top down. Essentially it would be similar to this: Type Src Dst Pass Host/IP Local Subnet1....N (No Limiters) Pass Host/IP Any (Limiters Applied) Pass LAN Any (No Limiters) Hope this helps.

Update: The queue length only made a very minor improvement. You can leave the queue length at the default in most situations. Changes you should make is with quantum and limit. In the following script gives some recommended settings https://github.com/dtaht/deBloat/blob/master/src/debloat.sh . After the changes CoDel was more responsive and overall worked better. The recommendations for quantum is 3000 for 100M, 1514 for 10M connection, and 500 for low latency if desired. A limit setting of 1200 for 100M and 800 or 10M. And a flows setting of 2048 as an optional setting.