Messages

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:

Code Select Expand

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:

Code Select Expand

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?

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!

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.

I've been running Opnsense for a while, but never really checked for bufferbloat until yesterday.  My setup is an upload and download pipe using WFQ, with CODEL checked on both.  I then have 6 weighted queues for upload and 6 for download.  While the WFQ seems to work, checking the CODEL box on the pipes do not.  I get only C's and D's on the dslreports buffer bloat test (I get the same results if the boxes are checked or not).  If I switch both pipes to "FlowQueue-CoDel", then I get A's on the bufferbloat test, but then lose the use of my weighted queues.  Setting CoDel on the individual queues works as expected (I get A's on the bufferbloat test), but since it's per queue, if one queue is hogging the bandwidth, then the buffer bloat problem still exists.  If I understand correctly, setting it on the queues, one queue doesn't know about the packets from another queue.  So, is my understanding of what the CoDel check box is for under the pipe's settings wrong?  I assumed that after WFQ does it's processing, the the packets are sent to CoDel.

Now, I will definitely be the first to admit I'm NOT A PROGRAMMER! ;D  Usually, if I need to do something with an API, I can eventually figure it out, but not this time (I've spent the majority of the day and have not got very far).

Now, what I need to do is be able to query a firewall rule to see if it's enabled or not and I also need to be able to enable/disable that rule.  I have found the the correct endpoint for getting the rule, but I do not know how to choose the correct rule.  When I use "/api/firewall/filter/getRule", it indeed returns a rule, but I do not know how to specify the rule I'm interested in (I'm assuming there's a parameter I'm missing)  I've even tried "/api/firewall/filter/getRule/(insert the UUID of the rule in question here)" and various other parameters (I'm kind of stumbling around in the dark here).

So, once I check to see if the rule is enabled/disabled, I will need to toggle it, which is a POST command using "/api/firewall/filter/toggleRule" (or so I'm assuming this will enable/disable it).  I didn't even get around to testing this because I can't figure out how to use the "getRule" command.

I'm also assuming I will need to use the "/api/firewall/filter_base/apply" after enabling/disabling the rule.

I will be using curl in a bash script to get/set these options.

This is the documentation I've been trying to use https://docs.opnsense.org/development/api/plugins/firewall.html

I'm using version 20.1.5

Thank you!
********  SOLVED *********
Alright, my OCD would not let me give up on this and after figuring a few stupid mistakes on my end, I thought I would share what I learned.

With the new plugin on version 20.1.5 for the firewall API, it adds a new menu item under the "Firewall" section called "Automation"  under that is the "Filter" and "Source NAT" menu items.  You create your firewall rule under "Filter", then you need to get the UUID of this rule (I just looked at the config.xml  Although there is a search parameter you can use with the API).  Now, these firewall rules are above all other rules, even floating.  (so the order of execution for the firewall rules goes: Automation->Floating->Interface)

I am using curl, so I will list my examples using that.

To see if one of the automation rules are enabled/disabled, or any other information you use:

Code Select Expand

curl -k -u "$KEY":"$SECRET" https://opnsenseIP/api/firewall/filter/getRule/$UUID

I'm using a bash script here, so $KEY is a variable for your, well, key and $SECRET is of course the secret that goes with the key.  $UUID is the uuid of the automation rule.

To enable/disable the rule (it's a toggle switch):

Code Select Expand

curl -k -u "$KEY":"$SECRET" -X POST "https://opnsenseIP/api/firewall/filter/toggleRule//$UUID" -d ""

Then, to apply it, you will use this command:

Code Select Expand

curl -k -u "$KEY":"$SECRET" -X POST "https://opnsenseIP/api/firewall/filter/apply" -d ""

This last command confused me, since in the documentation it says the "apply" uses the "filter_base" controller.  Anytime I would try usinging "filter_base", I would get an exception error  Although, since I really don't understand much about APIs or programming, I might have just misunderstood it.

I hope this helps someone!