webgui need manual restart after upgrade to 24.7

[Cilahn]

Hi franco,
i reverted to 24.1 by now. So i can't retest it. Looking at my Screenshots taken during the debugging on the 24.7 i'm pretty sure all Interfaces where unticked and the "All (recommended)" was shown. Also asked by Patrick before and i could reproduce the problem under 24.7.
I will stop investigating further. I'm relatively new to opnsene and currently evaluating it against pfsense and i must admit when in the help box under the feature is written "Only accept connections from the selected interfaces. Leave empty to listen globally. Use with care" i assume it is not a good idea to listen on the global/WAN side. When this is a common problem it would be better to not enable this config item or at least post a clear Warning in the Help Text.

I really appreciate your and Patrick very quick support. Thank you for that. Sadly opnsense doesn't print the best picture here.

Kind Regards,
Cilahn

[linore]

I might have the same issue after an upgrade to OPNsense 24.1.10_8 (and consecutive upgrade to 24.7 as well).

Previous version: 24.1.6
Issue appeared after upgrade to: 24.1.10_8

Issue: No access via web interface after boot (timeout).

Reloading the services via console (menu item 11) restores access via web interface until next reboot.

System: Log Files: General shows during boot:

2024-08-05T14:38:13   Error   opnsense   /usr/local/etc/rc.bootup: The command '/usr/local/bin/flock -ne /var/run/lighty-webConfigurator.pid /usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2024-08-05 14:38:13: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [fe80::7802:45ff:fe40:c66d]:4433: Can't assign requested address'

I can confirm that setting the listening interface at System: Settings: Administration to "All (recommended)" by deselecting all interfaces solves the issue. When the listening interface is set manual, even if all interfaces are selected, the above error message gets thrown and access to the web interface is not possible after reboot.

All interfaces are configured for static IPv4. IPv6 configuration type is set to "None".
Unchecking "Allow IPv6" at Interfaces: Settings and two reboots in a row solves the issue as well.

[Patrick M. Hausen]

I can confirm that setting the listening interface at System: Settings: Administration to "All (recommended)" by deselecting all interfaces solves the issue. When the listening interface is set manual, even if all interfaces are selected, the above error message gets thrown and access to the web interface is not possible after reboot.

"All (recommended)" and selecting each interface individually are fundamentally different things. There's a reason why

- the menu selection says "recommended"
- the help text says "use with care"
- the documentation explicitly states "Misconfigurations likely lead to a non accessible web interface"

"All (recommended)" is the only supported setting. Just don't mess with it unless you know exactly what you are doing.

I explained this again and again and again on this forum, so here's some links:

https://forum.opnsense.org/index.php?topic=33145.msg167914#msg167914
https://forum-opnsense-org.translate.goog/index.php?topic=40843.msg204479&_x_tr_sl=de&_x_tr_tl=en&_x_tr_hl=de&_x_tr_pto=wapp#msg204479

HTH,
Patrick

[doktornotor]

"All (recommended)" is the only supported setting. Just don't mess with it unless you know exactly what you are doing.

The setting should be hidden under "Advanced" at minimum. Also creating floating firewall rules (and disabling the anti-lockout if required on LAN) is a much better way of restricting access than messing with the listening interfaces.

[Monviech (Cedrik)]

Wherever you hide these settings and however many popups you create to warn people, they will find it and use it.

[doktornotor]

The thing is - this is only really useful when you need to run something on the web GUI port on some interface(s) - e.g. OpenVPN TCP/443 on WAN, or HAProxy, but still want to keep the OPNsense GUI on the default ports for whatever reason... Just way too visible as it is now.

[franco]

The static PHP page with the admin settings never having had an advanced button is probably the largest offender. I can agree with that.


Cheers,
Franco

[Patrick M. Hausen]

The setting should be hidden under "Advanced" at minimum. Also creating floating firewall rules (and disabling the anti-lockout if required on LAN) is a much better way of restricting access than messing with the listening interfaces.

Absof*inglutely! Anti-lockout, reply-to, ... I disable all of this "magic" stuff. I hate implicit, "magic" configuration with a vengeance. Everything should be explicit. If you change your LAN rules in a way so you cannot connect to the UI - tough shit. And the default is "allow * *", anyway. So why this anti-lockout thingy?

I really appreciate the change that IPsec VPN connections do not automatically create "allow" rules for ESP and AH, anymore, for example.

But of course - admittedly - I also never managed arp, ND, DHCP ... manually. So this is an area where I think these automatic rules are OK.

It's a difficult decision - not complaining about the current state of OPNsense. Just the remark that I disable everything that performs "magic", i.e. implicit rather than explicit rules, on every system I manage.

Kind regards,
Patrick

[Patrick M. Hausen]

The thing is - this is only really useful when you need to run something on the web GUI port on some interface(s) - e.g. OpenVPN TCP/443 on WAN, or HAProxy, but still want to keep the OPNsense GUI on the default ports for whatever reason... Just way too visible as it is now.

Bind to 4443, use a NAT port forward rule on LAN, done.  8)

[linore]

There is a GitHub issue about this topic: https://github.com/opnsense/core/issues/7649

[Cilahn]

Wow this boiled hot.

Sorry but you guys don't see that this is not the way to lure new users like me into the opnsense universe?

Scratiching my Head and starring into infinity ....

[franco]

Not sure which thread you read. This was rather technical and productive.


Cheers,
Franco