core
core copied to clipboard
upload traffic shapping dosn't work
Important notices
Before you add a new report, we ask you kindly to acknowledge the following:
- [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
- [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue
Describe the bug
hello i followed this guide from docmention to limit upload speed for each client but it's doesn't work the configuration as the guide say exactly and download limit works correctly i am not sure if it's bug or should i try different configuration i hope if you could help me
the link for the guide https://docs.opnsense.org/manual/how-tos/shaper_limit_per_user.html
i looked in older threads in the forum but i didn't find any clue why this happening
To Reproduce
Steps to reproduce the behavior: just use the settings in the guied https://docs.opnsense.org/manual/how-tos/shaper_limit_per_user.html Expected behavior
it should limit the upload speed but it dosn't
Describe alternatives you considered
i tried to change the limit to be on lan ports in genral but it didn't work too
Screenshots

Relevant log files
i am not sure what is the requested log please tell me which log to provide
Additional context
no
Environment
OPNsense 22.1.4_1-amd64 FreeBSD 13.0-STABLE OpenSSL 1.1.1n 15 Mar 2022 Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz (2 cores, 2 threads)
@minamorcose, is 10.10.10.0/24 your LAN subnet? And what do you mean with, you tried to change the limit to be on lan ports in genral?
As far as i can tell, traffic shaping in OPNsense isn't broken, so i think there is something wrong in your configuration. I can't tell you what's wrong with your configuration, but i just configured an upload limit on my firewall and it worked as expected. Here is what i did:
- Create a pipe "source pipe" with 800 kbit/s bandwidth, set mask to
source. - No Queues.
- Create a rule for interface LANx, protocol IP, source x.x.x.0/24 (LANx subnet), destination any, target "source pipe".
- Press apply (important).
- Use https://testmy.net/ for a test upload of 3 MBytes, get a result of 764 kbps.
- Restart the test a few minutes later, get a result of 762 kbps.
- Start a test on https://speed.cloudflare.com/, get a result of 725 kbps.
- Reduce the bandwidth of "source pipe" from 800 to 400 kbit/s.
- Press apply.
- Start another test on https://speed.cloudflare.com/, get a result of 371 kbps.
HTH
For Upload I would use interface LAN and direction IN as the packets may be already natted so the ACL wont match.
For Upload I would use interface LAN and direction IN as the packets may be already natted so the ACL wont match.
Sidebar: is it possible that the shaper could use an interface group? It doesn't currently so i'd need a duplicate rule for each lan interface.
This happens when shared forwarding is unchecked in Advanced Firewall settings. When checked upload is limited as expected. I'm not sure if this is expected behavior but I ran into the same issue and took forever to track this down.

If unchecked the shaper is disabled at all :)
Not very clear what this is for since it is under the "Multi-WAN" section. I don't have Multi-WAN so didn't think I needed any of those options selected until I later found traffic shaping not working.
Multi-WAN might not be best fit for shared forwarding, but it is the closest one on that page.
The dummynet configuration can be tricky, I tested this for 22.1 release QA and updated docs. They need to be followed to the letter to give the expected results.
Also with shared forwarding disabled you cannot shape at all if policy routing is used in firewall rules. It’s how it is integrated in stock FreeBSD.
Cheers, Franco
This issue has been automatically timed-out (after 180 days of inactivity).
For more information about the policies for this repository, please read https://github.com/opnsense/core/blob/master/CONTRIBUTING.md for further details.
If someone wants to step up and work on this issue, just let us know, so we can reopen the issue and assign an owner to it.