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

[Patrick M. Hausen]

Must be some other rule, then.

Exclude the impossible and what is left, however improbable, must be the truth.

-- Arthur Conan Doyle

[nero355]

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.

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

[Patrick M. Hausen]

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 ?!

Unplug and replug LAN or reboot the switch it's connected to - UI access gone.

[nero355]

Unplug 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...

[franco]

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

[RamSense]

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.

[Monviech (Cedrik)]

Uh, what happens if you turn off your reverse proxy?

[franco]

See the screencapture of the interfaces - lan is there.

Ok, not an anti-lockout issue IMO.


Cheers,
Franco

[RamSense]

Humm. good guess to test..
Disabled Nginx completely. no longer the 403 Forbidden, but the OPNsense gui login page is there.

[RamSense]

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.

[Monviech (Cedrik)]

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.

[RamSense]

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

[Patrick M. Hausen]

Can you show your rules on WAN? Since the default is to block everything, there must be some rule allowing this traffic, right?

[RamSense]

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.

[Patrick M. Hausen]

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.