No Web_GUI if LAN is DHCP and GUI only on LAN

[ednt]

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.

[nero355]

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

[lmoore]

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

[Patrick M. Hausen]

Did you explicitly bind the UI to the LAN interface only (Listen address) or did you leave that setting at "All (recommended)"?

[lmoore]

My configuration has it explicitly set to LAN.

[Patrick M. Hausen]

That question was for @ednt. I suspect explicit listen interfaces and DHCP do not work well together.

[ednt]

Yes, of course, I set it to only listen on LAN.

[Patrick M. Hausen]

Don't. Simple as that.

[Nullman]

Don'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.

[nero355]

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

[lmoore]

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

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

[meyergru]

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, point 32.