Core: WebGUI IPv6-only access not possible / WebGUI requires IPv4

Created on 24 Sep 2020  路  9Comments  路  Source: opnsense/core

[X] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
[X] I have searched the existing issues and I'm convinced that mine is new.

Describe the bug
After removing the IPv4 address of the only Listen Interface of the WebGUI access via IPv6 is lost

To Reproduce

  1. Configure one interface with an IPv4 and IPv6 address
  2. System->Settings->Administration-> Set Web Gui Listen Interface to dualstack interface
    2.5 Verify the Web GUI is accessible by IPv4 and IPv6
  3. Set IPv4 Configuration Type of interface to "None"

Expected behavior
Still have access to the Web GUI with its IPv6 address / with an IPv6-only configuration

Additional context
Access via IPv6 can be restored by adding an IPv4 address to the interface via SSH and restarting the Web GUI.

Additional test:
When having two interfaces set as the Listen Interfaces, the second interface has a IPv4 address and one removes the IPv4 address of the first interface: The Web GUI is still accessible via the IPv6 address of the first interface
Conclusion: The Web GUI requires an IPv4 address on at least one listen interface

Workaround: Configure a static Loopback address like 127.0.0.127 on the interface, that's enough for the Web GUI to start and bind to the IPv6 address

Environment
OPNsense 20.7.2 (amd64, OpenSSL).

bug

All 9 comments

There is not enough info here to see what's wrong. We need ifconfig output and /var/etc/lighty-webConfigurator.conf in the broken state.

That being said selective interfaces never really work 100% in dynamic environments and we've always said so and only reluctantly added such features making sure the implications are known to users from the GUI (see pop up). If the feature doesn't work it't better to simply turn it off and trust your firewall rules.

Cheers,
Franco

I'll gladly paste you the complete outputs, but I think this might be enough:
In my broken state /var/etc/lighty-webConfigurator.conf contains (my WebGUI Port is 4444):

$SERVER["socket"] == "127.0.0.1:80" {
    $HTTP["host"] =~ "(.*)" {
        url.redirect = ( "^/(.*)" => "https://%1:4444/$1" )
    }
}
$SERVER["socket"] == "127.0.0.1:4444" {
    ssl.engine = "enable"
}

A local _telnet 127.0.0.1 4444_ fails.
After adding an IPv4 address to my interface and restarting the WebGUI the telnet succeeds.

If the feature doesn't work it't better to simply turn it off and trust your firewall rules.

Yeah, that's one way. But I think I'd just stick with my workaround (loopback addr), at least until it's more stable/fixed. :-)
Thanks anyway.

That snippet isn't enough. What is server.bind in the broken state? Localhost works for me at least as long as server.bind is filled correctly.

re0_vlan202: flags=8843 metric 0 mtu 1500
ether 00:01:2e:MY:MAC:ADDR
inet6 fe80::201:2eff:feMY:MACADDR%re0_vlan202 prefixlen 64 scopeid 0x9
inet6 PRE:FIX:PRE:FIX:201:2eff:feMY:MACADDR prefixlen 64
groups: vlan
vlan: 202 vlanpcp: 0 parent interface: re0
media: Ethernet autoselect (1000baseT )
status: active
nd6 options=21

bind to port (default: 80)

server.bind = "PRE:FIX:PRE:FIX:201:2eff:feMY:MACADDR"
server.port = 4444

lighty-webConfigurator.conf.txt

Can you change this one:
https://github.com/opnsense/core/blob/a4bcbd5a92fa381c0f5e4f26990dabd21606c084/src/etc/inc/plugins.inc.d/webgui.inc#L48

to:

array_unshift($interfaces, 'lo0');

And see if that helps.

And see if that helps.

Yes, perfect: Replaced that line, restarted webgui, accessible via IPv6

Ok, lighttpd is a bit stubborn then if IPv6 is in server.bind ... https://redmine.lighttpd.net/projects/lighttpd/wiki/Server_bindDetails

There is server.use-ipv6 for this but to avoid further issues we just make sure an IPv4 is always first , either 127.0.0.1 or 0.0.0.0 for all cases now :)

Thanks again!

Was this page helpful?
0 / 5 - 0 ratings