I just noticed on https://pentest-tools.com/network-vulnerability-scanning/port-scanner-online-nmap (https://pentest-tools.com/network-vulnerability-scanning/port-scanner-online-nmap)
that the auto generated Anti-Lockout Rules (Destination NAT) for port 22 and port 444 (my opnsense gui) are both opened on WAN and can be reached.
Is this my fault and should those 2 Anti-Lockout rules be deleted after installing 26.1 or is this something to look at? I cant see a delete option in the Destination NAT list.
How would that work? The anti-lockout rules are for the LAN interface as source only. Did you actually see those two ports open from the WAN side?
I've tried the OPNsense web Gui and it is reachable. It was always disabled for WAN. In OPNSense I had, and still have, System -> Settings : Listen Interfaces ALL (recommended).
Looks like I have to change this to LAN and Wireguard only(?) although it is not recommended?
Can you reproduce?
I have not made any rules for the OPNsense gui to be reachable on wan
Im on OPNsense 26.1_4-amd64
and migrated to the rules (new) and deleted the old rules.
Looks like a bug, when I place a block rule on wan port 444 I can still externally reach the OPNsense gui:
Possibly a bad interaction of anti-lockout and NAT reflection? I use neither, sorry.
I have the Anti-Lockout rules enabled and administration on all interfaces, too. During 26.1 upgrade, two separate non-editable rules have shown up on top of the destination NAT rules, for IPv4 and IPv6. The source interface for both is LAN.
I have done no rules migration to new rules and also created no new rules. Reflection settings are all on in "Firewall: Settings: Advanced".
SSH and Web GUI are not open on WAN.
Reflection settings were are all on in "Firewall: Settings: Advanced". I turned them off, no difference.
Er ... are you really testing from the public Internet or possibly from an internal (LAN) system and trying to connect to your WAN address? The latter will always work if access from LAN is permitted. Using the WAN destination address does not magically route the connection out and back in again.
I am testing from my iphone 5g connection (no vpn) and can reach the OPNsense GUI on the wan address and port.
dubbel checked and tested local domains, not reachable, so I am not locally connected.
Online port scanners show port 22 SSH and WebGui are open
If you deleted your original LAN interface (and possibly your WAN, identifiers "lan" and "wan") interface the ancient anti-lockout code can't really guess which one is secure so it uses the first "optX" as the base for the anti-lockout. If that's the case the best solution is to disable the anti-lockout and just add manual rules that emulate the behaviour if you want/need it.
Cheers,
Francp
I have not changed my lan or wan interface during upgrade or after converting to the new ones and removing the old rules.
When I try to disable the anti-lockout rule, I can not, it is not "clickable" / "editable" (?) and stays enabled
That's a global setting:
Firewall: Settings: Advanced: Disable anti-lockout
Quote from: RamSense on February 01, 2026, 02:55:20 PMIn OPNSense I had, and still have, System -> Settings : Listen Interfaces ALL (recommended).
Looks like I have to change this to LAN and Wireguard only(?) although it is not recommended?
I still don't understand why this is not recommended ?!
IMHO it's totally logical to bind things like the webGUI and SSH to just the Management VLAN network a.k.a. the default LAN Interface in the case of OPNsense :)
Because it does not work for interfaces that are created on-the-fly or change their IPs if the BIND is not done to the anonymous socket 0.0.0.0, which denotes "all" interfaces, including such that do not exist (yet).
Just try to use a VPN interface: It will seem to work, but on the next reboot, the service fails because it cannot bind to a non-existing interface.
So, the usual way is to bind services to "all" interfaces and block access using firewall rules.
However:
I still do not understand how this could happen unless there is some other misplaced rule or - even more likely - the smartphone was connected via WiFi and that causes a false positive test.
As I said, I use the same settings including the reflection settings and see no such thing.
disabled the anti-lockout rule.
I checked Firewall: NAT: Destination NAT
and the two rules on top are gone.
still OPNsense gui reachable.
all dubbel checked, on 5g (wifi disabled), no vpn.
tried an other laptop with extrnal vpn to the wan ip and also gui reachable.
Must be some other rule, then.
QuoteExclude the impossible and what is left, however improbable, must be the truth.
-- Arthur Conan Doyle
Quote from: meyergru on February 01, 2026, 05:44:05 PMBecause it does not work for interfaces that are created on-the-fly or change their IPs if the BIND is not done to the anonymous socket 0.0.0.0, which denotes "all" interfaces, including such that do not exist (yet).
Just try to use a VPN interface: It will seem to work, but on the next reboot, the service fails because it cannot bind to a non-existing interface.
So, the usual way is to bind services to "all" interfaces and block access using firewall rules.
But if I understand you correctly then there is no issue in binding it on the Default LAN Interface since you are probably never ever going to change anything there anyway ?!
And if you need access from a VPN or another network you can use firewall rules
for those :)
Quote from: nero355 on February 01, 2026, 06:05:45 PMBut if I understand you correctly then there is no issue in binding it on the Default LAN Interface since you are probably never ever going to change anything there anyway ?!
Unplug and replug LAN or reboot the switch it's connected to - UI access gone.
Quote from: Patrick M. Hausen on February 01, 2026, 06:12:42 PMUnplug and replug LAN or reboot the switch it's connected to - UI access gone.
Hmm... never tested that...
The same goes for OpenSSH Server ?!
Luckily the device has a regular Power On/Off button as a last resort so a clean "reboot" can be performed...
Okay, once more. This has nothing to do with the upgrade whatsoever.
Go to Interfaces: Assignments and see the "Identifiers" for all your interfaces. I'm guessing there's no "lan" because you deleted and redid it at some point, could be years ago.
Cheers,
Franco
I did another reboot, no difference.
See the screencapture of the interfaces - lan is there.
I have now (as a last resort) added a HTTP server for the wanip:GUI port in Nginx with no locations to get an 403 Forbidden if you enter the wan ip externally.
I have added a block rule on wan for SSH port 22 (below my created block GUI port that did not work), the ssh port is now externally no longer open.
So i closed this down to the opnsense gui port externally.
Uh, what happens if you turn off your reverse proxy?
Quote from: RamSense on February 01, 2026, 06:41:18 PMSee the screencapture of the interfaces - lan is there.
Ok, not an anti-lockout issue IMO.
Cheers,
Franco
Humm. good guess to test..
Disabled Nginx completely. no longer the 403 Forbidden, but the OPNsense gui login page is there.
Ok, narrowed it further down. It has something to do with the new WAN rules than(?) The block rule on top there did not work, but:
When I add a block rule in the [Any floating] section with a block rule for the OPNsense GUI port on WAN ->port closed!
N.B. found an error in my wan rule. I used source port instead of destination port as with the floating rule. now Opnsense GUI port is blocked with the WAN block rule on top.
Without
pfctl -s rules
its impossible to say why.
But don't copy paste the dump in here, try to find the rule that matched and why your block rule matched before it. You can also do this by logging all rules and using the live log.
So with the WAN block rule for the OPNsense GUI port, I closed the external exposure of the Login page.
But I did not have to do this before, I did not wanted to have the OPNsense gui externally exposed.
And the same for the SSH port 22 that I had to add a block rule for on WAN also.
Is there something I can look at, what is not already done? To narrow this further down
Can you show your rules on WAN? Since the default is to block everything, there must be some rule allowing this traffic, right?
Here are the top rules for wan
There is no allow for Opnsense GUI 444 or SSH 22 in the WAN rules.
I found an export as CSV button on the bottom right of the (WAN)rules. When I export this and search for 444 to find the Opnsense Gui port 444 rules, I only find my created own block rule on WAN and on LAN my created allow as "anti lockout" rule.
If you disable the block rules on top, the services are exposed, right? And there's 53 rules on WAN. So the rule responsible must be one of the 45 and a half you did not show.
How are you expecting anyone to help with less than 20% of the relevant information?
Or it's in floating. Or interface groups. Or NAT port forwarding. Yes, I think that sums it up. Somewhere in these places there absolutely must be a rule causing the ports to be open.
Found it! Some little bug. Thanks Patrick.
Your simple "there must be some rule allowing this" made me wonder if the deleting of the old rules has done its job or not.
And there I went through the old interface rules and there was one rule left on WAN! So the delete all (old)rules with [Remove all legacy rules] in the wizard, did not do it all. Maybe a bug there? The wizard forgot to remove one by rather just adding an important one you do not want to have!
IPv4+6 * * * * * * *
Actually, that was not a "little" bug. But did that rule come out of the blue or was it present before?
Because you obviously have used the migration assistant, you should be able to look at the rules before the migration.
This would be helpful to tell if there is a potential "HUGE" bug or just a misconfiguration on your part.
I had a rule exactly like this for interface "enc0" in my export which I needed to delete manually before migrating. No idea what the cause of this might be atm.
I have my imported CSV list still here and looked through them. There is no allow all rule there.
Since I have all the rules with a description it was easy to see that there was none without one like the screen capture above.
When searching for WAN I did not find an allow all rule.
Maybe you can replicate this also for this out of the blue rule.
Quote from: Patrick M. Hausen on February 01, 2026, 10:08:45 PMI had a rule exactly like this for interface "enc0" in my export which I needed to delete manually before migrating. No idea what the cause of this might be atm.
Related? https://forum.opnsense.org/index.php?topic=50591.0
This looks related also:
https://forum.opnsense.org/index.php?topic=50651.0 (https://forum.opnsense.org/index.php?topic=50651.0)
Makes no sense to me. What does this dump?
# pluginctl -g filter.rule
Cheers,
Franco
Quote from: Patrick M. Hausen on February 01, 2026, 10:08:45 PMI had a rule exactly like this for interface "enc0" in my export which I needed to delete manually before migrating. No idea what the cause of this might be atm.
Same here. That specific rule was "hidden" before - I was unable to find it in the old rules under 26.1., but apparently, it was exported.
Quote from: meyergru on February 02, 2026, 09:15:23 AMQuote from: Patrick M. Hausen on February 01, 2026, 10:08:45 PMI had a rule exactly like this for interface "enc0" in my export which I needed to delete manually before migrating. No idea what the cause of this might be atm.
Same here. That specific rule was "hidden" before - I was unable to find it in the old rules under 26.1., but apparently, it was exported.
Since I did use IPsec and I did have an "allow all" rule on that tunnel years ago, I suspect I just removed the VPN configuration and the rule was left orphaned in the configuration.
Quote from: franco on February 02, 2026, 08:27:16 AMMakes no sense to me. What does this dump?
# pluginctl -g filter.rule
Cheers,
Franco
when I run this now I get:
pluginctl -g filter.rule
[]
this was in the export file I made of the old rules with the added magic appeared rule, before deleting it:
@uuid,enabled,statetype,state-policy,sequence,action,quick,interfacenot,interface,direction,ipprotocol,protocol,icmptype,icmp6type,gateway,replyto,disablereplyto,log,allowopts,nosync,nopfsync,statetimeout,max-src-nodes,max-src-states,max-src-conn,max,max-src-conn-rate,max-src-conn-rates,overload,adaptivestart,adaptiveend,prio,set-prio,set-prio-low,tag,tagged,tcpflags1,tcpflags2,categories,sched,tos,shaper1,shaper2,description,source_not,source_net,source_port,destination_not,destination_net,destination_port
3af43003-284b-4680-ab3f-faffe9391068,1,keep,,1,pass,1,0,opt3,in,inet46,any,,,,,0,0,0,0,0,,,,,,,,,,,,,,,,,,,,,,,,0,any,,0,any,I think the export / import tool seems to do something when there is an error mentioned. If I interpreted the various notifications around this on the forum correctly.
So the legacy rules are fully purged. That's good.
The export only exports what is physically there. I think that's still good.
The import of that rule did something unexpected? It should be reproducible on your end then.
Cheers,
Franco
I still have the CSV file that was exported and imported. In this file this rule isn't there. (And nobody would like to have such a rule ;-))