Anti-Lockout Rule (Destination NAT) -> open ports external?

[RamSense]

I just noticed on 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.

[meyergru]

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?

[RamSense]

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.

[RamSense]

Looks like a bug, when I place a block rule on wan port 444 I can still externally reach the OPNsense gui:

[Patrick M. Hausen]

Possibly a bad interaction of anti-lockout and NAT reflection? I use neither, sorry.

[meyergru]

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.

[RamSense]

Reflection settings were are all on in "Firewall: Settings: Advanced". I turned them off, no difference.

[Patrick M. Hausen]

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.

[RamSense]

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

[franco]

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

[RamSense]

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

[Patrick M. Hausen]

That's a global setting:

Firewall: Settings: Advanced: Disable anti-lockout

[nero355]

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?

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 :)

[meyergru]

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.

[RamSense]

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.