Messages

Possibly related to this: https://github.com/opnsense/src/issues/303

Edited to link correct issue

Hi @SonicJoe,


that was my first assumption. I disabled the divert to of the rules that allow the flows. But in my case it did not help. I also checked the corresponding logs for suricata and could not find any blocks. For example "dest_port:123" should trigger a hit in the suricata logs, as this was blocked.

@franco: Help please

I should clarify that I have other rules with divert-to set that work fine. It is only the rules on the WAN interface. I suspect something about the Destination NAT rules is causing confusion when the packet comes back from Suricata and gets re-inserted in the flow. I agree that Suricata is not blocking anything. I did see evidence that Suricata was evaluating the packets though:

Code Select Expand

app_layer.flow.sip_udp                                      | Total                    | 10
app_layer.tx.sip_udp                                          | Total                    | 57

I am seeing this too in relation to Suricata in Divert mode. Inbound packets on my WAN rules are getting evaluated twice (occasionally 3 times), first time is a pass and then the second (or last) time it is dropped for "state-insert,block". If I remove the divert-to from the rule, then it works normally.

Example:

Code Select Expand

root@home:~ # tail -f /var/log/filter/latest.log | grep 5060
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420777"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420778"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:58-04:00 home.example.com filterlog 30391 - [meta sequenceId="420779"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22381,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420785"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22403,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420786"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22403,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420795"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22456,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:52:59-04:00 home.example.com filterlog 30391 - [meta sequenceId="420796"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22456,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420799"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420800"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420801"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40213,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420806"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40233,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:00-04:00 home.example.com filterlog 30391 - [meta sequenceId="420807"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40233,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420811"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40250,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420812"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40250,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420813"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40271,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:01-04:00 home.example.com filterlog 30391 - [meta sequenceId="420814"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40271,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420818"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40298,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420819"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40298,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420825"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,40337,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:02-04:00 home.example.com filterlog 30391 - [meta sequenceId="420826"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,40337,0,none,17,udp,1190,34.210.91.112,10.7.0.10,5060,5060,1170
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420830"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22595,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420831"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22595,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420834"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22606,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:03-04:00 home.example.com filterlog 30391 - [meta sequenceId="420835"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22606,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:04-04:00 home.example.com filterlog 30391 - [meta sequenceId="420838"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,match,pass,in,4,0x68,,122,22636,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168
<134>1 2026-07-25T20:53:04-04:00 home.example.com filterlog 30391 - [meta sequenceId="420839"] 187,,,55e761c8-fbf4-4921-a72a-5824b67416b7,igc0,state-insert,block,in,4,0x68,,122,22636,0,none,17,udp,1188,34.226.36.34,10.7.0.10,5060,5060,1168


The affected rules are associated with destination NATs. In the example its TCP/UDP 5060 (SIP) from the WAN to the DMZ server 10.7.0.10, but I also have rules for 80 and 443 with the same results.

Edit: I forgot to mention that mine was working fine on 26.1, and I only saw this behavior after updating to 26.7.1.

I'm pretty sure destination NAT is one to one. You would need 2 rules, one for port 1630 and one for port 1631 if you need both redirected.

Edit: Oops, just realized you have 12 ports to 1641. So it would be 12 rules. I could be wrong, but that's what I did for the redirects i need.

You must be the support person who has my case, since I didn't supply any IPs here in the forum. I responded to your E-mail. Curl fails due to the self-signed cert, but I provided you screen shots of the GUI showing that Zenarmor confirms it can connect and check the indices, as well as a screenshot of the Elasticsearch DB using Elasticvue that shows all the indices were created by Zenarmor, so it must be able to connect.

Also, and I will add this to the ticket, I just tried removing the certificate and making the connection as HTTP instead of HTTPS, but I have the same issue. Here's the output of the curl command when switching to HTTP:


curl -XGET http://192.168.20.50:30003
{"error":{"root_cause":[{"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","ApiKey"]}}],"type":"security_exception","reason":"missing authentication credentials for REST request [/]","header":{"WWW-Authenticate":["Basic realm=\"security\" charset=\"UTF-8\"","ApiKey"]}},"status":401}

So that rules out a certificate issue.

I've been running Zenarmor on a Protectli 4B for about 7 months or so without issues (Home license). Due to the low amount of resources, I use a remote Elasticsearch DB. Within the last month I have hit a strange issue. Suddenly there is no data in my reporting database. Zenarmor is working. Blocks are being applied based on policies. I can confirm this by disabling or modifying policies and seeing that things work or don't. I believe everything was working fine on OPNSense 23.1.9. I haven't made any changes in a long time, other than updates. I ended up skipping 23.1.10 because it came out just before I went away on vacation and by the time i came back and was settled 23.1.11 was out. Somewhere in there a Zenarmor update occurred too.

Things I have tried:

1) Zenamor -> Configuration -> Reporting and Data -> Perform Index Check, result = "Everything looks good"
2) Try "Reset Reporting", result = "You cannot hard reset for remote database"
3) Try "Erase Reporting Data", result same as above
4) Create a brand new Elasticsearch DB, point Zenarmor at that, result = I see the Zenarmor indices created in the DB, and performing an index check still results in "Everything looks good", but no data shows up in reports
5) Factory reset Zenarmor, result = odd errors, packet engine won't start
6) Full uninstall/reinstall of Zenarmor, result = Zenarmor working again, but reporting issue persists
7) Reboot FW as a sanity check, result = no change, issue persists

I'm completely at a loss, so... any ideas? I did send logs to support but other than them asking if I tried "Reset Reporting" I haven't heard back.

Fixed it, or at least it appears fixed. I tested this morning before my last reply and I was still having the issue. I then ran a Health Audit and now the "Save" button is active again. Whew! Not sure what went wrong, and not sure how it got "fixed" since I don't think the Health Audit actually makes any changes, but glad its working again. I really didn't want to reinstall.

Good questions, but there have been no changes on my PC end and it was working fine before the upgrade. Also, I forgot to mention, but its not EVERY page with a "Save" button. I haven't gone through them all, but (for instance) the "Save" button on the "Logging" page is enabled and does let me click it. If I got to System -> Settings -> Tunables and add or edit there the "Save" button is enabled. Its almost like something is messed up in the permissions somewhere if I had to guess, and so certain pages are read-only.

So I upgraded from 21.7.8 to 22.1 tonight. After the upgrade I wanted to log in to the CLI via SSH, but I keep SSH disabled and only enable it as needed. When I go to the System -> Settings -> Administration page, the "Save" button at the bottom is grayed out. No matter what I do on that page, I cannot save. I tried both with "root" and with my secondary admin account. I also have the same issue on the System -> Settings -> General page, so I cannot change my theme, DNS, or hostname (not that I'm looking to, but its not available if I need to). I can enable and disable firewall rules, but I tried adding a new one and I have the same issue on the new firewall rule configuration page, the "Save" button at the bottom is grayed out and not responding to clicks.

Is there anything I can do to fix this so that I can make changes again? Or am I going to have to roll back?

(FYI - Luckily I keep Serial enabled, so I was able to access the CLI that way and take care of things. My issue is the inability to save changes in the GUI)