I've so far upgraded 2 OPNSense routers from 24.1.8 to 24.1.9
First one was fine.....an IPv6 only router.
Second one, the WebGUI failed to work, but everything else was fine. SSH, Ping, Routing etc
I tried a reboot, still not working.
The only thing that fixed it was issuing /usr/local/etc/rc.restart_webgui
Doing my third now...
After issuing that command, did the GUI survive a reboot?
Just tried that.
No.
I shut it down...pulled the power out....waited....reapplied power.....
This command is now needed everytime. Was perfectly fine before.
Further to this....the IPv6 only router was fine, and the WebGUI is accessed over HTTP.
My home router was fine (IPv4 and 6), access to WebGUI over HTTPS
This one, access to WEBGUI over HTTP doing both IPv4 and IPv6.....borked.
I did notice that I had the HSTS tickbox checked even though its over HTTP so unticked that now, will try again.
This perhaps? https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces
Cheers,
Franco
Hi Franco.....
It could be....but why now?
I've had it set to LAN like....forever....
It works until it doesn't is the general issue here. I've been working on a number of IPv6 improvements. Not sure if something changed the timing of the boot sequence but it could also be boot timing related issues with other software updates running as plugins even.
Cheers,
Franco
I can confirm that un-setting this from LAN to All does fix it, although now given me a headache on how to resolve an issue, as the way I've done IPv6 means you can hit the admin interface now globally.
I dont do traditional IPv6 the normal way, so I may have to rethink this whole IPv6 thing....
As long as you don't accept inbound IPv6 traffic for the web interface port I don't see how this would be possible.
Depending on the setup using LAN as selection can end up with the same issue, because LAN has a GUA and if you allow incoming traffic you will be routed to your LAN interface web GUI. It sort of shows that this has nothing to do with this setting, perhaps just that IPv6 can be different from IPv4 firewall approach.
Cheers,
Franco
Thanks Franco....
I'll have a think about this one and figure something out.....
Sure, please let us know what you did so it can help others later on. :)
Cheers,
Franco
Hi Franco,
I was looking in live view whilst hitting the admin interface from outside but nothing was showing.
I can see when I hit on IPv4 I get the default state deny rule, but nothing for IPv6.
Taking a guess I added a block rule for ipv6 only on the WAN to this firewall port 80 and sure enough that's enough to stop it.
This may be the way forward for me but I wondered why I never saw anything in the logs on a successful hit?
I wondered if the Anti Lockout was at play here perhaps?
Appreciate your insight.
I wouldn't think it was anti-lockout. When you create a quick pass rule for IPv6 traffic on WAN or floating you don't see the logging unless you log all that traffic via the rule option too.
In some cases you may want logging for a short period of time to make sure it all works as expected on such broad rules, but when moving these to production logging is turned off.
What you can do is create a specific rule for GUI access too in order to be able to log / trace that all the time if needed. This way you can also see who has accessed it that shoudn't (scope of the rule may be wrong).
Cheers,
Franco
Thank you so much for your help.
It turns out I was way overthinking this (Because of the crazy way I deploy IPv6)
A simple block rule on the WAN for IPv6 (did IPv4 for double measure) has resolved my issue.
One question though....I don't understand why the firewall was happily blocking IPv4 on the WAN, but not IPv6?
I assumed when I set listen interfaces to all 4 and 6 (given they are both on the same interface) would behave the same?
My IPv6 deployment is crazy as I have 2 leased lines. 1 doesn't support IPv6, and 1 does.
The one that doesn't support IPv6 is our primary line for IPv4.
We use a Watchguard firewall at our network edge (With 2 OPNsense above that for each leased line feeding the WG which are used for routing only. )
I added a 3rd OPNsense in my LAN which is ULA, and use that for NPTv6, so clients on the LAN can use IPv6.
Watchguard IPv6 implementation sucks, so that's how I do it.
IPv4 exits leased line 1. IPv6 exists leased line 2. All only possible because of OPNsense.
> One question though....I don't understand why the firewall was happily blocking IPv4 on the WAN, but not IPv6?
Not knowing the network setup and rules employed this is hard to guess, sorry.
Cheers,
Franco
Hey...no worries.
Thank you for always being here.
I love OPNsense, I love it I tells ya!
@franco
Just found a similar problem. My fw1 on my main node did not properly start after a reboot and 24.1.9 applied, I had to restore a backup with 24.1.8, before the reboot, fw1 worked fine. So I leave fw1 on 24.1.8
fw2 on another node run so far, I applied 24.1.9_1 and restart the VM, the system came up and UI initially worked and then died,
/usr/local/etc/rc.restart_webgui
helped to restart the GUI. Log of the WebGUI only shows the manually restart of the WebGUI.
In the logs, I found this
/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-06-19 20:24:00: (/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [fe80::be24:11ff:fe1d:b261]:80: Can't assign requested address'
If you need anything specific, let me know. I try my best.
Yes, the explicit IP bind is always prone to race conditions.
Cheers,
Franco
Strange, that never happened before and it's a local address.
The warning in the docs exists for a reason. It works until it doesn't (tm).
Cheers,
Franco
@franco
Could you point me to the part of the documentation?
Quote from: franco on June 18, 2024, 04:08:06 PM
This perhaps? https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces
@franco Thx, I change my config and find another solution. Also thanks for the hot fixes.
Hey franco....
This is more of a "good to know" question, but does this also apply to Unbound?
In fact anything?
I noticed my Unbound was selectively set, so Ive changed that to All too....
TIA
Al
Yes, naturally.
I'm not saying a strict binding is bad, but for a dynamic target that's very difficult. A couple of fixed static IPs are not so much of an issue, but we never intended to select VIPs for binding and the plugins don't do it either except for some that offer specific IP binding... which is also complicated because it won't cross-reference if that IP is valid and the service will fail if missing.
Cheers,
Franco
I'm experiencing this too, went from 24.1.9-3 to -4 today and still an issue. After every reboot, I have to restart gui from console.
This is a VM on proxmox with 2 PCI NIC passthroughs. Static WAN and IPV4 turned off on both WAN and LAN; 8443 port for OPNsense GUI.
I have a second mini pc unit with similar setup but its been offline for about a wek (haven't upgraded). As other mentioned, GUI log only shows the reboot/shutdowns/restarts.
The answer is posted above....
https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces
Copy that, thanks.
For anyone further researching...manually selecting all available interfaces in "Listen Interfaces" under Web GUI portion of administration (GUI doesn't work after reboot) is not the same as unselecting all interfaces, which then shows/displays "All (recommended)" which GUI does work after reboot.
Correct. Though the described loopback approach is much safer if you require explicit single point access.
Cheers,
Franco
As I started experiencing the same issue, can someone please explain what happened such that I need to modify the configuration in 24.1.9 to ensure constant web interface access? Maybe a note about the change should be added to the update notes?
D
Quote from: davidfi01 on June 22, 2024, 06:34:22 PM
Maybe a note about the change should be added to the update notes?
Nothing specific to this update. Binding services to individual IP addresses has always been discouraged as per the documentation that was also already cited multiple times in this thread:
https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces
If it worked before you were lucky. It's never been expected to work reliably.
I'm also experiencing that issue; apologies for adding to the noise.
In an attempt to minimise exposure (I'd argue this is good practice in sec infra [1]), my Web GUI is indeed restricted to listen to a MGMT interface with a static IPv4 address, with IPv6 config set to 'None' as I don't have a use for it here. This used to work fine (I know, until it doesn't...)
I also get the smoking gun noted above:
/usr/obj/usr/ports/www/lighttpd/work/lighttpd-1.4.76/src/network.c.604) bind() [fe80::5054:ff:febb:5a2b]:443: Can't assign requested address
Is it right for the WebUI to attempt to bind to a disabled IPv6 interface? Many thanks!!
[1] https://en.wikipedia.org/wiki/Defense_in_depth_(computing) (https://en.wikipedia.org/wiki/Defense_in_depth_(computing))
Using the recommended settings and restricting access on VLANs in scope is a much more reliable avenue
Quote from: franco on June 22, 2024, 11:20:59 AM
Correct. Though the described loopback approach is much safer if you require explicit single point access.
Cheers,
Franco
Hi! I'm very new to opnsense and I read everything about the new "issue". I made it work again, but I would really love to only have access to the web gui from the local IPs - 192.168.0.0/24 (LAN interface). I read something about loopback address, but I don't understand nothing. Can you please explain step by step, what and where to click, in order to achieve this? Maybe there are more like me and it will help us more. Thank you in advance!