Hi there,
I do have currently a running setup with a traffic shaper to limit uploading traffic from my nas to the offsite location. This traffic shaper is currently manually enabled or disabled depending on my working hours from home office.
I would like to automate it and use this traffic shaper in a firewall rule. Because this offsite location connects via Wireguard I tested rules in the LAN and WG0 Network part of the rules but nothing worked so far.
How can I achive this because only adding the queue or rule won't change (or better limit) anything. Is there a trick that I need to know to get it working?
Regards,
Shorty
Its a rule so for it to work it needs to be 1st matched.
If you put it into pf (firewall rules), it needs to be on the TOP, if any other rule before it is being matched the rule with shaper attribute will not be applied.
Regards,
S.
Thanks @Seimus , but do I need to assign Pipes or Queues to the rule and how should this rule look like?
I created one on LAN network with destination WG0 but it isn't applying this rule (attachments).
Yes you need to put in there either an already configured Pipe or a Queue that is attached to a Pipe.
the Rule direction is IN which I think means Upload reverse should be download.
Did you try to switch it?
Regards,
S.
@_shorty Have you gotten traffic shaper in the firewall rule working? If yes, please share with us a screenshot of the pipe and firewall rule settings.
Thank you.
Pipe & Queue is individual, its configured exactly as is described in Shaper Docs.
The traffic shaping feature in FW (pf) rules doesn't change how the Pipe and Queue is configured, it doesn't change how it operates.
When you use pf Traffic Shaping feature, you set the direction to UP or DOWN depending on the RULE direction depending on the Interface.
For example,
If I have an Queue-any-any-UP and Queue-any-any-DOWN, that are attached to their respective pipes Upload and Download.
I create a rule on WAN with direction of the rule OUT. In the traffic shaping direction I set Queue-any-any-UP and reverse direction Queue-any-any-DOWN.
Regards,
S.
Thank you so much for your quick reply, Seimus.
For Queue-any-any-UP or Queue-any-any-DOWN, do we need to configure the interface, source, destination, and direction as well, or is it enough to simply create them and attach them to their respective pipes?
Best regards,
Saleh
Quote from: saleh on November 27, 2025, 09:50:22 AMdo we need to configure the interface, source, destination, and direction as well
I am not sure what you mean by this.
PFs Traffic Shaping just replaces the RULEs section under FW > Shaper > Rules. This gives you a possibility to use all the features of PF rules, but as well to reduce the number of needed rules. As you can use just one RULE to classify UPLOAD and DOWNLOAD, instead of two needed rules in the old ipfw rules (FW > Shaper > Rules).
For Pipe and Queue configuration you follow the docs and best practices, e.g at minimum separate PIPEs and QUEUEs for Upload and download.
Regards,
S.
Dear OPNsense Team,
After extensive testing on three different OPNsense hardware appliances, we identified an issue affecting upload traffic in the firewall rule traffic shaping (rule-direction).
When creating an upload pipe with a bandwidth of 5 Mbps and attaching this pipe to a firewall rule under traffic shaping (rule-direction), the internet connection does not function correctly. Some websites fail to open or display errors, requiring multiple refresh attempts. Browsing becomes very slow, and upload speed tests return errors.
Through further testing, we discovered that the issue is related to the bandwidth value configured in the upload pipe. When we set a higher value, such as 25 Mbps instead of 5 Mbps, everything works properly. Despite setting 25 Mbps, the actual upload bandwidth we measure is 5 Mbps. In other words, to achieve a real upload bandwidth of 5 Mbps, we must configure the pipe with approximately 5 × 5 Mbps.
Note: This behavior was observed on OPNsense 25.7.8 and the newly released OPNsense 25.7.9. Please find the attached images.
Thank you.
This is a known issue.
The reverse-direction is broken when it involves NAT. It spans the packet twice and causes disruptions.
To overcome this you need to set the Pipe involved in this reverse direction to twice the value it should be.
Regards,
S.
We were looking at this two weeks ago actually and it appears to be an edge case in FreeBSD... we haven't gotten closer to it yet, but we will look at it again.
Cheers,
Franco
I did open as well a ticket for better tracking ;)
https://github.com/opnsense/src/issues/273
Thanks Franco!
Regards,
S.
You're the one who's helping. Thanks!
Thank you so much Seimus and Franco for your support and assistance.
I hope the issue will be fixed in the upcoming release.
Best regards,
Saleh