This morning i installed the update in question, and i noticed that i can no longer access Docker services i use, neither from inside nor from outside, due to the rule "Default deny / state violation rule".
I checked among the rules, but i didn't notice any changes in the existing ones (both in the automatically created ones and in mine), so i really can't understand what the problem is.
Did it happen only to me?
I am attaching some screenshots
Please attach screenshots.
Links are not attachments.
My reasons for the request are thread longevity and user security.
By the way, from which version were you upgrading?
That's a very odd pair of rules. They may be outside of my experience, as I don't use any static NAT. As is, they do not appear to match the marked flows in your logs (source and destination ports and destination address do not match). For more info (e.g. "reason"), hit the "i" to the right of the log entries.
Quote from: pfry on April 26, 2026, 03:15:49 AMThat's a very odd pair of rules. They may be outside of my experience, as I don't use any static NAT. As is, they do not appear to match the marked flows in your logs (source and destination ports and destination address do not match). For more info (e.g. "reason"), hit the "i" to the right of the log entries.
The rules have been created to route traffic coming from the outside targeting ports 80 and 443 to NPM (Nginx Proxy Manager). NPM, in turn, handles forwarding the request to the required Docker container, based on the custom domain that has been pointed (for example: https://bitwarden.my_domain.xxx or https://paperless.my_domain.xxx).
The IP 192.168.84.2 is the IP of the WAN port. The router's IP is 192.168.84.1, and it is set to expose the firewall without filters (so that the traffic management is entirely handled by it).
The local network is 172.22.8.0/24. The IP of the LXC with Docker is 172.22.8.4.
In fact, the rules route all traffic on ports 80 and 443 arriving at 192.168.84.2 to 172.22.8.4 on ports 8443 and 8484. These 2 ports, within NPM, are translated into:
8443 -> 443
8484 -> 80
Schematically:
http://service.my_domain.xxx = public IP -> router -> WAN -> rules -> LAN -> NPM -> Docker
Quote from: passeri on April 26, 2026, 12:38:30 AMPlease attach screenshots.
Links are not attachments.
My reasons for the request are thread longevity and user security.
By the way, from which version were you upgrading?
I apologize, i corrected it; i was trying to exceed the limit of 256kb.
The update was carried out starting from the immediately previous version, 26.1.6; 26.1.6_2 is a hotfix released on 23-04.
EDIT:
Since the firewall is a VM on Proxmox, i performed a restore of it using a previous backup (specifically, the backup dates back to the night of 25-04, before i installed the hotfix). Once it restarted, everything started working again as before.
At this point, i have the impression that the problem is in the hotfix.
EDIT 2:
After several tests, i discovered that the problem arises the moment i perform the migration from the old ISC DHCP (now legacy) to Kea DHCP.
There's probably some configuration problem, I don't know.
I'm also having this problem. Seems I cannot remove the legacy rules, which preclude the new Rules from taking effect.
I did further tests and took a look at the configuration options of Kea DHCP, and i confirm that the problem occurs when i activate the service. I saw that there is a section related to DDNS, but in my case everything is managed via Docker with Nginx Proxy Manager; even on ISC DHCP there is an option related to DDNS, but i have never enabled it.
Quote from: thormir84 on April 27, 2026, 04:18:34 PMI did further tests and took a look at the configuration options of Kea DHCP, and i confirm that the crash occurs when i activate the service.
What kind of crash ?!
This topic started with a Firewall Rule issue and now there is something crashing ?!
QuoteI saw that there is a section related to DDNS, but in my case everything is managed via Docker with Nginx Proxy Manager;
even on ISC DHCP there is an option related to DDNS, but i have never enabled it.
KEA DDNS is meant for Hostname DNS Registration in combination with Unbound as the DNS Server because initially it only worked for a Static DHCP IP Address Mapping based on the MAC Address and not for a regular Dynamic DHCP IP Address.
Is there any chance that some of your Docker stuff got upgraded too within the same timeframe and is causing issues now ?
Reason I am asking : A lot of people let something like WatchTower update/upgrade their Docker Containers completely automatically.
Quote from: nero355 on April 27, 2026, 05:53:06 PMQuote from: thormir84 on April 27, 2026, 04:18:34 PMI did further tests and took a look at the configuration options of Kea DHCP, and i confirm that the crash occurs when i activate the service.
What kind of crash ?!
This topic started with a Firewall Rule issue and now there is something crashing ?!
QuoteI saw that there is a section related to DDNS, but in my case everything is managed via Docker with Nginx Proxy Manager;
even on ISC DHCP there is an option related to DDNS, but i have never enabled it.
KEA DDNS is meant for Hostname DNS Registration in combination with Unbound as the DNS Server because initially it only worked for a Static DHCP IP Address Mapping based on the MAC Address and not for a regular Dynamic DHCP IP Address.
Is there any chance that some of your Docker stuff got upgraded too within the same timeframe and is causing issues now ?
Reason I am asking : A lot of people let something like WatchTower update/upgrade their Docker Containers completely automatically.
Ahahah sorry, i made a copy and paste mistake from another forum!
I see that you are talking about static assignments and Unbound; since i use both, it could be a configuration issue on my side.
With ISC DHCP, i used static assignments even for devices with fixed IPs, so that the name would be visible on Unbound; since when migrating to KEA i exported the assignments to CSV and imported them, maybe the problem is there.
I rule out a problem with Docker or updated containers, because the problem occurs only with KEA and only shortly after its activation; as long as i use ICS there are no problems.
Quote from: thormir84 on April 27, 2026, 11:49:57 PMI see that you are talking about static assignments and Unbound; since i use both, it could be a configuration issue on my side.
With ISC DHCP, i used static assignments even for devices with fixed IPs, so that the name would be visible on Unbound; since when migrating to KEA i exported the assignments to CSV and imported them, maybe the problem is there.
I do the same for many years now in combination with different Routers and IMHO that should not be your issue! :)
If you have traffic hitting the "Default deny / state violation rule", this is almost certainly due to not having an active rule to match the action you want.
On my test device, I performed a clean installation using OPNsense-26.1.6-serial-amd64.img. After configuring the system using the Wizard, Kea DDNS is disabled by default. Is yours disabled in Kea?
To see what issues Kea encountered, open Services -> Kea DHCP -> Log File. It will probably open and list events of type Warning. Set the history to show the Last week or Last month. If nothing is presented, select event type Informational or Debug. You should now see events listed. Review these and advise what it was Kea encountered when it fell over.
Quote from: lmoore on April 28, 2026, 02:56:01 PMIf you have traffic hitting the "Default deny / state violation rule", this is almost certainly due to not having an active rule to match the action you want.
On my test device, I performed a clean installation using OPNsense-26.1.6-serial-amd64.img. After configuring the system using the Wizard, Kea DDNS is disabled by default. Is yours disabled in Kea?
To see what issues Kea encountered, open Services -> Kea DHCP -> Log File. It will probably open and list events of type Warning. Set the history to show the Last week or Last month. If nothing is presented, select event type Informational or Debug. You should now see events listed. Review these and advise what it was Kea encountered when it fell over.
First post, screenshot called "rules 2.jpg"; the rules are there. The problem, as already mentioned, occurs only under Kea DHCP, while with ISC it does not; if the rules were missing, it would not work at all.
I'm not yet familiar with the new rules, but http/https as source port seems wrong to me. Shouldn't that be ,,*"?
Good pick up by @troplin.
Yes, the source ports should be listed as "*" to allow connections from any source port.
After you change the source port to "any", these rules will allow a connection hitting your WAN IP address of 192.168.84.2 to 172.22.8.4 and with "Inspect" enabled, you will see the data counters increment. However, I don't see this working for you as you've described.
What else have you configured in OPNsense to re-write the destination ports en route to 172.22.8.4?
To achieve your goal, you would be better off disabling your two rules and setting up two Destination NAT entries, including setting the Firewall rule to Pass.
With the latest updates (26.1.7 and 26.1.7_1) and leaving everything as it was originally, the problem has stopped occurring; i activated the Kea DHCP service, after deactivating and uninstalling ICS, and i corrected the 2 rules by putting '*' in the source port; now everything works as it should (moreover, i don't know how it used to work before and why I didn't notice it).
The rules in Destination NAT had already been set up and, from what i have seen doing some tests, they must exist otherwise nothing works.
I noticed that if i leave the Destination NAT rules active and deactivate the firewall ones or vice versa, the traffic is blocked, so i assume both must always be there.
In the Destination NAT rules, i also noticed that if i select the port as "https" and "http" instead of "Single host or Network" by entering "443" and "80", the traffic is blocked; i do not understand the logic.
Glad to hear it's now working as you intended.
On my test machine, I don't currently have anything connected to the WAN, so I can't test the behaviour of http/https and 80/443 settings you've mentioned.
With your Destination NAT rules, you could set the Firewall rule setting to Register rule and disable/remove your current rules. See this message where I used your example (https://forum.opnsense.org/index.php?topic=51746.msg266243#msg266243) in another thread - just a thought.
Thank you!
I set, on the 2 NAT rules, "Register rule" and i disabled the 2 rules manually set on the firewall; now everything works, including the "https" and "http" settings as the destination port.
I probably created a sort of mess with the configuration, and the system did not take it well.
Now everything is cleaner and correct.