webgui fails to start when haproxy is enabled

[ssbarnea]

I managed to find a configuration setup that while resonable will render your opnsense webgui useless as it will fail to restart.

How to reproduce?

• install haproxy
• add a Virtual IP for your LAN (192.168.33.1 in my case)
• configure haproxy to use that virtual-ip (192.168.33.2 in my case)
• restart web gui (or wait till next day)
• enjoy not having a web gui anymore and not being able to start the service at all.

Apr 15 06:00:00 q opnsense: /usr/local/etc/rc.restart_webgui: The command '/usr/local/sbin/lighttpd -f /var/etc/lighty-webConfigurator.conf' returned exit code '255', the output was '2019-04-15 06:00:00: (network.c.309) can't bind to socket: 192.168.33.2:443 Address already in use'

In fact this issue could happen with any service binding on any 80/443 ports on the router, is not limited to haproxy.

If you create a Virtual IP on LAN and assign it to a service running on 80/443 you will render your web gui unable to start.

Recovery

#service haproxy stop
#service lighttpd stop
#service lighttpd onestart
Starting lighttpd.
2019-04-15 09:28:39: (network.c.166) warning: please use server.use-ipv6 only for hostnames, not without server.bind / empty address; your config will break if the kernel default for IPV6_V6ONLY changes

Now you go and disable haproxy... or reconfigure it not bind to a different interface.

[AdSchellevis]

By default the webgui listens on all interfaces, you can configure a static interface in System->Settings->Administration

[ssbarnea]

@AdSchellevis I think this is a genuine bug: once you add a Virtual IP, the webgui will try to bind to it when services is restarted. This means that you cannot really use ports 80/443 on any LAN Virtual IPs.

Configuring only one interface does not save you ending up locked.

[AdSchellevis]

It could be a feature request, not a bug. when selecting an interface, it will listen on all addresses for that interface.

[fichtner]

Since the gist here is that you want to bind to the same port on the same IP this is not a bug. We cannot inspect if someone already uses the port and lighttpd will simply fail to start so it is what it is.

[ssbarnea]

Considering that the outcome is rendering the UI broken (even locking out some poor folks that missed to configure ssh) while doing normal operations, it would count as a bug, clearly not something to be closed. Probably it should not have huge priority because few people use haproxy.

In fact this bug is not even caused by haproxy itself, is a bug in the way the lightttpd is configurable: that it binds to all ip_addresses on an interface and from the web interface it is not possible to force it to bind to a single IP, even if the product supports this: https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_bindDetails

Another way to prevent suck lock-down would be if the web interface would be restarted when a virtual ip is added to its interface, assuring that no other service could start using it (so when someone tries to configure haproxy, they will realise that they cannot bind to the new IP). I do not like this approach because it only protects UI without providing a solution for those wanting to start other services using the same port.

[fichtner]

In fact this bug is not even caused by haproxy itself, is a bug in the way the lightttpd is configurable:

This is debatable. You know my opinion and I will continue to prioritise "core" over "plugins" and consider "plugins" breaking "core" an unfortunate misconfiguration.

that it binds to all ip_addresses on an interface and from the web interface it is not possible to force it to bind to a single IP, even if the product supports this: https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_bindDetails

And this is definitely untrue. :)