Upgraded from 22 to 23.1 - Web Gui now inaccessible

[ausnet]

Upgraded via GUI from latest 22 version to 23.1.  Firewall rebooted, and while traffic is passing, I cannot access the GUI anymore.

Got into CLI and updated further to 23.1.7_3.  Still same behavior.  Also re-configured LAN IP via CLI to reset Web GUI settings.  Still cannot access GUI.

Wireshark shows no response to TCP SYN on 80 or 443 on LAN interface, although it does respond to ARP and Ping.

What can I do to troubleshoot or diagnose further?

[Deku2]

We had a similar issue, though we were on 23.1 and upgrading to 23.1.7.  The web UI failed to start, but all else seemed to be working.  We physically rebooted it and it came back up fine.

[ausnet]

Reboot - no change.
Shutdown and power on - no change
Restored backup from pre-upgrade - no change.

Copied off all my config backups to a TFTP server.

Should I try a clean install of 23.1.7_3 and restore config?  Or just reinstall 22.7 and stay there for a while?

Tried restoring 23.1.7_3 installation to factory defaults - was able to access GUI.  Restored the backup and GUI is inaccessible again.

[ausnet]

Tried pkg update -f (https://www.reddit.com/r/OPNsenseFirewall/comments/obybqf/how_to_roll_back_the_firmware_version/) and a reboot - no change.

Tried update from CLI and saw the error "Starting web GUI...failed" - https://forum.opnsense.org/index.php?topic=9128.0 said to try "/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf" which brought the GUI back up.

After rebooting, GUI was down again.  tried lighttpd command but got this error:
root@FW02:~ # /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf
2023-05-17 16:53:05: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.69/src/network.c.537) can't bind to socket: [Public IPv6 address from ISP]:443: Can't assign requested address

After a couple of mins, running the command again works without an error and the GUI loads.

[franco]

https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces

[mkd73]

If so, than remove that option "Listen interfaces"

[franco]

Or how about not using it... remember "I know what I am doing" button?

[mkd73]

Why not use it? I bought a book OPNsense Praktiker, there is a lot about Management Interface, and will recommended to make a Management Interface.
And i tried the same , than i switched back to listen to all interfaces, and "Error 503". what is helping is only manualy restart from SSH.

[franco]

I might make a flow chart so we don't end up in a loop. If you follow the documentation it's ok to do it, but getting 503 tells me you are not. It is what it is and I'll stop arguing.


Cheers,
Franco

[mkd73]

Hmmm, it worked before 23.1.7_3, so i followed documentation. And nobody argues here, we are only telling you the problems that we have.

[ausnet]

https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces

Hi Franco.  I looked at the setting, and the wording of the warning doesn't convey the message you think it does.

The warning says you should know what you're doing if you want to only listen on certain interfaces.  I work with multiple NGFW vendors for my job.  I know what I'm doing, and it's a best practice to not listen for management traffic on WAN, DMZ, or other untrusted interfaces.  If following that best practice is dangerous on OpnSense, the warning needs to say something like "selecting interfaces here may make the GUI inaccessible if the interface is unavailable when the web GUI starts.  Use with caution."

I appreciate you guys developing the product and making it publicly available.  Making warning messages less dependent on tribal knowledge will be helpful to people who are new to the product.  Also, identifying why the settings were ok on the previous version, but not ok on this version might unearth a bug or provide an opportunity to make the product more robust.

In the meantime, I will remove the interface list setting and try to use policy to block management access on external/untrusted interfaces.

Cheers

[mkd73]

I aprreciate also their work, but, and i have already spended , not once , if OpnSense CE is a test platform i would like to know that.
Next problem, PPPoE "put zero" , you put Zero 0, and nothing happens, with two zeroes 00 is ok. I mean, those are basic things.Than German Telekom, you make a VLAN 7 Interface, pppoe, with a modem, and it does not connect at all, no logs.
Next: VoIP, never ending story. And i think that OPNSense and PFsense, both does not clear rules really, i am talking because of VOIP, someone suggested only outbound rule to your Voip server, i deleted all rules than make only that, rebooted, and it worked, new installation, just one rule, does not work.
I would really buy a Software, but, "you did not read good you book" is a little arrogant.

[franco]

I aprreciate also their work, but, and i have already spended , not once , if OpnSense CE is a test platform i would like to know that.

I think at this point you're just trolling. My last reply here if you don't want to heed the documentation AND complain about things. A lot of people are here to get help and that's what we want to keep doing here.

The warning says you should know what you're doing if you want to only listen on certain interfaces.  I work with multiple NGFW vendors for my job.  I know what I'm doing, and it's a best practice to not listen for management traffic on WAN, DMZ, or other untrusted interfaces.  If following that best practice is dangerous on OpnSense, the warning needs to say something like "selecting interfaces here may make the GUI inaccessible if the interface is unavailable when the web GUI starts.  Use with caution.

It's really not unclear. Assuming it says what you think it says is not what it can mean. You lose access and you accepted the risk.

https://github.com/opnsense/core/blob/master/src/www/system_advanced_admin.php#L437-L439

It's really easy to configure this safely, but that is what the doc suggests (and the setting itself is not the place to educate people on how to configure a management interface -- most just use "LAN" and this is where it breaks for example if IPv6 tracking is active which performs an endless cycle of rebinding to listening addresses and lighttpd eventually doesn't like it and says 503).


Cheers,
Franco

[mkd73]

"I think at this point you're just trolling. My last reply here if you don't want to heed the documentation AND complain about things. A lot of people are here to get help and that's what we want to keep doing here."
No comment on this.
We were here for that, to get help.
I am very happy actually that you developed opnsense, and the first choise since than was always opnsense for me and my customers. But it seems it is better not to comment or criticise here.
Thx franco.