Hi,
for a special case (frr/bgp) we allowed GUI only on LAN, for the first setup we used DHCP on LAN, with an address from our management network.
I was not able to acces the GUI.
Ping was Ok.
On the console I can see that 443 listen is:
tcp4 127.0.0.1:443
tcp6 ::1:443
But not on the LAN address.
I think that the DHCP address was not available at web_gui start.
An uggly situation.
Ok, I solved it by using a fixed address.
But still, it should also work with a DHCP address on that interface.
Quote from: ednt on August 03, 2026, 10:23:20 AMBut still, it should also work with a DHCP address on that interface.
IMHO that should always be a Backup Configuration and not the Primary Configuration.
However since we are talking about a Router here then there is only the Primary Configuration.
The Backup Configuration can be the Serial Console or some kind of IPMI/iDRAC/iLO-like solution...
Quote from: ednt on August 03, 2026, 10:23:20 AMBut still, it should also work with a DHCP address on that interface
I've set up a test system to trial the upgrade from 26.1 to 26.7.
For the purpose of testing, I set the LAN interface to use DHCPv4 - I have an IPv4 environment but no BGP.
The Web GUI is available every time OPNsense boots.
If your DHCP server is slow to respond, it may be the interface doesn't have an address when the Web GUI service starts, or, FRR/BGP is in some way affecting it as you wouldn't normally have DHCP assigned addresses on the internal interfaces of a router.
Did you explicitly bind the UI to the LAN interface only (Listen address) or did you leave that setting at "All (recommended)"?
My configuration has it explicitly set to LAN.
That question was for @ednt. I suspect explicit listen interfaces and DHCP do not work well together.
Yes, of course, I set it to only listen on LAN.
Don't. Simple as that.
Quote from: Patrick M. Hausen on August 05, 2026, 10:41:20 PMDon't. Simple as that.
Why not? Im using opnsense for god knows how long, and i allow webgui access only on LAN interface. And my LAN interface has DHCPv4 server running on it. Never ever had issues accessing it. These options exist for a reason.
Quote from: Nullman on August 05, 2026, 10:49:45 PMQuote from: Patrick M. Hausen on August 05, 2026, 10:41:20 PMDon't. Simple as that.
Why not? Im using opnsense for god knows how long, and i allow webgui access only on LAN interface. And my LAN interface has DHCPv4 server running on it. Never ever had issues accessing it. These options exist for a reason.
+1 here :)
But in this topic the LAN Interface is a DHCP Client instead of Server which I think is really weird and no one should ever configure it like that !!!
However there is another reason to not bind the webGUI to the LAN or simply just one Interface :
If the single Interface the webGUI is bound to goes DOWN and then UP again it can become unreachable until you reboot OPNsense.
But...
Since the webGUI (and also SSH by the way!) is also bound to Localhost both via IPv4 and IPv6 my opinion is that this should not occur ?!
#NeedsTesting :)
Quote from: Nullman on August 05, 2026, 10:49:45 PMWhy not?
Refer to the fine manual - https://docs.opnsense.org/manual/settingsmenu.html#listen-interfaces.
If you don't want to bind to all interfaces a tip is provided in this section where you set an address on a
Loopback interface. The next step will be to include the newly created interface to the
Listen Interfaces bindings.
After applying the settings, open a connection using the address you assigned to the
Loopback interface. When you've signed in remove the LAN interface bindings.
Note, the
anti-lockout rule rule will apply just as it did before.
Quote from: nero355 on August 06, 2026, 01:38:12 AMIf the single Interface the webGUI is bound to goes DOWN and then UP again it can become unreachable
FWIW, I performed some tests where the DHCP server was unavailable. Rebooting OPNsense from the WebGUI,
dhclient eventually assigned an address to the interface using the one it obtained earlier, as it was within its lease time. When the address was applied the OPNsense login banner appeared - just stating an observation.
By courtesy of Patrick, who more than once explained this (not his exact words):
To answer the "why" (not to bind a service to a specific interface):
When you do that, the interface must be configured before the service is started. Often times, that is beyond your control, so it won't always work - and if it fails, you wonder why, just like in this thread.
If instead you leave that out, the service will bind to "any", which includes interfaces that pop up later.
You should restrict access via firewall rules instead.
This now made it to here (https://forum.opnsense.org/index.php?topic=42985.0), point 32.
I agree with you.
But ... why does opnsense simply don't do that?
Handle the access to the web-GUI and SSH by setting system rules and listen general on 0.0.0.0
instead of really doing a bind.
I think this would be the best way.
Thats entirely your choice. You can disable the default Anti Lockout rule, keep the bind on all interfaces, and use firewall rules yourself to restrict access.
Of course if you use some Any Any Any... allow rules, that also includes services hosted by the Firewall itself, aka Webgui.
So you just have to be careful and intentional with your ruleset.
Quote from: ednt on August 06, 2026, 01:00:23 PMBut ... why does opnsense simply don't do that?
Handle the access to the web-GUI and SSH by setting system rules and listen general on 0.0.0.0
instead of really doing a bind.
It does do that (by default). You changed it (as you admitted in comment #6).
BTW (technicality), the socket is always bound - it wouldn't receive any connections if it wasn't - the difference is that binding to INADDR_ANY (0.0.0.0) means that it can receive connections with destination address belonging to any local interface (at connection time).
Quote from: ednt on August 06, 2026, 01:00:23 PMBut ... why does opnsense simply don't do that?
Handle the access to the web-GUI and SSH by setting system rules and listen general on 0.0.0.0
instead of really doing a bind.
It does do exactly that when you leave the listen interface at "All (recommended)". 0.0.0.0 is what that setting means. You did explicitly set it to only listen on LAN but LAN does not have an IP address at the time the UI starts.
That's why I told you "simply don't do that".
🤷