OPNsense Forum
English Forums => General Discussion => Topic started by: DevanNull on September 15, 2021, 02:18:37 am
-
Ok, I have another question to stump everyone. I was playing around with firewall rules and trying to set DSCP values on packets. For just a simple test, I set all ICMP packets going OUT of my WAN (on the WAN interface rules) set to pass and priority set to "Voice (5)". Now, when I run "tcpdump -i vtnet1 -v icmp" (on the opnsense box, vtnet1 is my WAN interface), all of my TOS fields on the packets are "0x0" (I've also tried this with TCP/UDP). I also set the rule to log to the firewall logs. In the logs, I can indeed see that the traffic was matched. I know that the rules need new states for it to take effect, and rather than killing the states everytime, I merely would ping different IP addresses on the internet. I even tried this on LAN OUT thinking maybe NAT had something to do with it.
Also, a side effect, is that pings would eventually stop passing the wan, and when I tried TCP/UDP, all traffic stopped until I disabled the rule.
So, does the "set priority" option actually mark the packets after it leaves the firewall, or is it merely for internal use? And no, this has nothing to do with the traffic shaper, pure firewall rules only.
-
pf.conf (where the GUI text was copied from) makes it sound like it would adjust the TOS field of IP but in reality it seems to only tag VLAN packets accordingly. I'm not sure if this ever worked on FreeBSD.
Cheers,
Franco
-
Take a look at Firewall: Settings: Normalization for rules that allow TOS/DSCP values to be set. This doesn't support logging so I assume you went to firewall rules. I'll patch up that description then...
Cheers,
Franco
-
Thank you so much! That was the solution. I would have NEVER of got that. When searching for anything similar, I mostly got results on matching packets or traffic shaping with DSCP.
I had actually been to the Firewall Settings: Normalization section before, but the Detailed settings area where you add the rules isn't very clear in it's intent. Even looking at the documentation, it says the rules are for "matching" not "setting". So, I should have just hit the plus sign to see what I could do with those rules.
Again, thank you!
-
Yay, no problem. Was nice to take a look at the source code again in the operating system and confirm how it should and shouldn't work. :)
FWIW, relevant commit:
https://github.com/opnsense/core/commit/d2291d21d2
Cheers,
Franco
-
I ran into another little problem with the rules. One of my rules was matching UDP packets going OUT my WAN, to a specific destination port and for some reason it was overriding the other 5 or so rules I had in place, marking ALL the packets with the 0x20 tos. In other words, the rule below was overriding the TOS on all of my other rules.
This is the rule in question:
scrub out on vtnet1 proto udp from any port = 33333 to any port = 1195 set-tos 0x20 fragment reassemble
The other rules are set via packets coming IN from the LAN with most having the packets changed to EF, for example:
scrub in on vtnet0 proto udp from <VoIP> to any set-tos 0xb8 fragment reassemble
I have no other rules on the interface's or floating that relate to port 33333 or 1195 (thinking that another rule was overriding it somehow).
I was finally able to get the 0xb8 tagging working again by finally specifying a destination on the WAN out rule, which, it should have matched merely on the destination port 1195 (I added the source port, tested, then added the destination as a last resort)
I hope that wasn't confusing.
Did I find a bug?
-
I was finally able to get the 0xb8 tagging working again by finally specifying a destination on the WAN out rule, which, it should have matched merely on the destination port 1195 (I added the source port, tested, then added the destination as a last resort)
I think I've run into the same bug.
The normalization rules seem to ignore source and destination ports completely. I've tried with TCP port 80 for example, and instead of matching only HTTP connections, the DSCP is set on all TCP connections (to any port).
At the moment, I'm using OPNsense version 20.7.5.
Does anyone know if this issue is fixed in the latest release?