Admin access over Wireguard

[AWBbox]

Hi everyone,

I'm experiencing a weird problem with Wireguard (os-wireguard-go plugin v1.13_5) on OPNsense 23.1.11.

I have a Wireguard endpoint client tunnelling all traffic through to my OPNsense appliance. The firewall rule for the Wireguard interface is wide open, permitting all traffic.

I want to be able to access the administrative interface of OPNsense via HTTPS and SSH on the Wireguard interface IP and so I have included the interface as a listener via System > Settings > Administration > Web GUI + Secure Shell.

If I reboot the OPNsense appliance then I can no longer access administrative interfaces via the Wireguard interface IP. However, if I remove the Wireguard interface as a listener via System > Settings > Administration > Web GUI + Secure Shell > Save > Apply, and then re-add the interface in the same way, it starts working again!

This feels like a bug and I want to make sure I'm not going crazy. If anyone else using Wireguard could test this and see if they are able to replicate, or can point out what I'm doing wrong, that would be great. Thanks!

[Maurice]

Sounds like a timing issue. The Web GUI might start before WireGuard creates the virtual interface. I've seen similar issues with binding services to "dynamic" interfaces in the past.

It probably works if you don't select specific listen interfaces? If you can't do that (e. g. if other services need to bind to port 443), I'd recommend creating a loopback interface and using this as the listen interface for the Web GUI.

Cheers
Maurice

[AWBbox]

Thanks Maurice, that would make a lot of sense. The loopback idea is a good one as a workaround too, thanks.

[Patrick M. Hausen]

Leave the web UI set to "All (recommended)", people. Why do you think that second word is there?

[AWBbox]

I'm just extra paranoid about exposing such services to the internet!

[Patrick M. Hausen]

Your firewall rules will take care of that!

"All (recommended)" is not the same as enabling all interfaces individually. Far from it. "All" means the service listens to the special address INADDR_ANY (or IN6ADDR_ANY for IPv6). These translate to 0.0.0.0 and :: respectively.

A service listening on a socket like this will we reachable via any address even as they change, come and go, VPN tunnels, PPPoE connections, ... etc.

That's why you should leave that setting as it is unless you know what you are doing - but then don't come complaining, there is no bug here. The only scenario that I can think of is a data centre firewall with everything configured statically - but even then VPN connections might come and go.

And last if you limit a service like Unbound to listen e.g. on LAN only, it might not have a valid source address to send packets from to the Internet or through a tunnel. That's another severe "gotcha" when not using "Any". And again there is no bug. This is simply how the socket API has worked since TCP/IP was integrated into Unix at Berkeley some decades ago.

To reiterate my first sentence: keeping the bad guys out is the job of the firewall, not messed up listen interface settings.

[Maurice]

@Patrick Agreed. But there is a valid use case for only binding to specific interfaces: Having multiple services listening on the same port (on different IP addresses of course). I have this situation on multiple OPNsense instances and solved it by binding to loopback interfaces.

Doesn't seem to be the case here, so I agree with 'All (recommended)' is, well, recommended.

Cheers
Maurice

[Patrick M. Hausen]

@Maurice in that case I use loopback and NAT port forwarding, too. E.g to send DNS queries to BIND for some networks and to AdGuard Home for some others.

[Maurice]

@Patrick Not sure why you'd need NAT for this. I would e.g. let BIND listen on lo1 and AdGuard on lo2. Then let some networks use the lo1 address for DNS and other networks the lo2 address.

I have Unbound set up to support DNS over HTTPS (downstream) which requires it to listen on port 443, which of course collides with the Web GUI. So the Web GUI only listens on a loopback interface which has a dedicated management IP address.

I realise we're getting off topic.

[Patrick M. Hausen]

I prefer to use the OPNsense interface address in the respective network. Then forward e.g. LAN:53 to 127.0.0.1:53 and OPT1:53 to 127.0.0.1:5053 ...

[Maurice]

Oh, so you use a non-standard port on the default lo0 interface and then not only translate the IP address, but also the port. Got it.

I prefer one loopback interface per service, so all services can use their default port with no need for port translation. And each loopback interface has routable IP addresses, so no need for address translation either.

There is no "right" way of course.