core
core copied to clipboard
opnsense
Traffic shaper documentation does not work for VLAN.
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
Shaper does not work following this documentation guide and using a VLAN interface as the GuestNet. https://docs.opnsense.org/manual/how-tos/shaper_guestnet.html
To Reproduce
Follow this guide: https://docs.opnsense.org/manual/how-tos/shaper_guestnet.html The only difference is using a VLAN interface for the GuestNet instead of a physical interface for the GuestNet.
Expected behavior
Bandwidth should be limited to the pipe limits.
Describe alternatives you considered
Used another traffic shaping guide: https://docs.opnsense.org/manual/how-tos/shaper_share_evenly.html
Screenshots
If applicable, add screenshots to help explain your problem.
Relevant log files
If applicable, information from log files supporting your claim.
Additional context
Add any other context about the problem here.
Environment
OPNsense 23.7.10_1-amd64 FreeBSD 13.2-RELEASE-p7
you can easily inspect the rules in /usr/local/etc/ipfw.rules technically for the shaper there's no difference between a vlan or a regular interface.
Hey, did you ever get this resolved? I am trying to setup a shaper on a VLAN for a guest network as well and the rule doesn't seem to be working.
Hey, did you ever get this resolved? I am trying to setup a shaper on a VLAN for a guest network as well and the rule doesn't seem to be working.
No, I don't think they care that much to fix it.
I did this option instead: https://docs.opnsense.org/manual/how-tos/shaper_limit_per_user.html
Problem with this method is you'd be limiting to each user in that IP range, rather than the whole interface.
you can easily inspect the rules in
/usr/local/etc/ipfw.rulestechnically for the shaper there's no difference between a vlan or a regular interface.
Even with the logs, I wouldn't know what to look for or how to fix it. The people in charge of fixing it can easily reproduce the issue and troubleshoot it on the spot by following the guide; just swap out the GuestNet interface with a VLAN interface.
To be frank even if you paid for support it would be a good idea to respond to support questions at least once. 😉
you can easily inspect the rules in
/usr/local/etc/ipfw.rulestechnically for the shaper there's no difference between a vlan or a regular interface.
Here is my file for the rule that I setup, but it doesn't seem to be working. If I change the interface2 from a VLAN interface to a physical one, then it works fine. I have tried changing the interface2 to a wireguard interface, and it also seems to work.
Looks like there is an issue specifically with shaper working on VLANs.
what is vlan030's parent? if it's the same interface (igb0) that might explain the issue a bit. Our advised best practice is to prevent mixing tagged and untagged traffic, in most cases it works, but there are downsides.
I would test with a clean vlan first (no parents which may overlap), but ipfw show on the console would show counters per rule and may indicate overlaps as well.
you'll have to forgive me I am new to this stuff. What do you mean by "clean vlan"? The shaper is running from one physical interface to a vlan running on a second physical interface. Would this still be considered overlapping?
Here is my output from ipfw show. I only have the one shaper rule on it.
you'll have to forgive me I am new to this stuff. What do you mean by "clean vlan"?
No problem, I meant an interface without untagged traffic on it.
The shaper is running from one physical interface to a vlan running on a second physical interface. Would this still be considered overlapping?
No, I meant the untagged and tagged packets both on igb1, but by the looks of it, no packets are being matched by your rule.
Can you try setting the rule direction to "out" by the way, the following note in the manual (man ipfw) suggests this doesn't match (our examples use networks if I'm not mistaken, personally I always try to match networks).
The recv interface can be tested on either incoming or outgoing packets, while the xmit interface can only be tested on outgoing packets. So out is required (and in is invalid) whenever xmit is used.
I have tried changing the setup using the below options. I have set the ip to a specific device (my mobile for testing), but the download speeds still exceed the pipe bandwidth. If I try doing the same but connecting my mobile to the LAN network and changing the IP accordingly, the limit gets put in place.
The vlan part sounds a bit weird here as you're not matching on one at the moment, but I can doublecheck when I'm at the office, easy to test. The usual match on target ip post NAT works like a charm on my end, if there is an upstream problem, it should be easy to reproduce.
I had a couple of spare physical interfaces on my router so i did some testing. Set up a new interface, created a VLAN on it and attempted to limit the download speeds via pipes. Unfortunatly the issue is still there. Thought it might be a setting somewhere that creeped in, but even on a fresh interface/vlan the issue is still present. Would this be classed a bug/issue?
Just checked at our office, can't reproduce an issue when vlans are being used.
The upstream bug tracker doesn't show much either to be honest (https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=ipfw).
If you disable "shared forwarding" in "Firewall: Settings: Advanced", does that make a difference? Without it, our setup is roughly the same as a standard FreeBSD 13.2 install.
I just tried something that worked, that leads me to a question. When testing this previously, the interface was set to WAN, and trying different combinations for the destination to work with the Guest subnet. I just changed the interface to the Guest network with source/destination set to any and it limits the traffic as expected?
There is one huge difference there indeed when it comes to ipv4, and that's NAT. I just noticed my test rule was also set to the wifi network, which is indeed pre-NAT, but changing it to WAN still works on my end (which assumes the right pfil processing order).
I must profusly appologies. When you said NAT it rang a bell that I had completly forgot about. I have my guest network running out over a seperate gateway group form the WAN. Setting the gateway back to default (WAN) and the pipe interface to WAN as previously worked exactly as expected. I can't see a way to setup a pipe for a whole gateway group, But my understanding is that a device using a gateway group will only ever use a single gateway interface at a time. I have three gateways in the group, so setting up a pipe seperatly for each gateway also appears to have solved my problem. I am sorry for needlessly waisting your time.
Things happen, in cases where you're sending traffic to multiple hops, you need to shape on the "lan" end indeed, otherwise multiple possible rules apply.
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.
