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!
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
Thanks Maurice, that would make a lot of sense. The loopback idea is a good one as a workaround too, thanks.
Leave the web UI set to "All (recommended)", people. Why do you think that second word is there?
I'm just extra paranoid about exposing such services to the internet!
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.
@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
@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.
@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. ;D
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 ...
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.
hello Patrick
i have a similar issue with restricting the Gui web access only to a specific client of wireguard
i have create an alias for the machine with a specific ip address
i set listen interface to all
from wireguard theclient allowed ip is 0.0.0.0/0,::/0
from firewall rule i set a rule with allow the source wireguard net to destination This firewall.
now if i want to limit the access to the firewall to a specific wireguard client i create a nat port forward rule as you suggested.
Firewall: NAT: Port Forward
Interface Proto Address Ports Address Ports IP Ports
wireguard TCP/UDP Linux_PC 443 (HTTPS) This Firewall 443(HTTPS) 127.0.0.1 443 (HTTPS)
is that will work?
Looks like it might. Why don't you just try?
it only work if i set the wireguard firewall rule as
source wireguard net and destination this firewall
which mean the all wireguard vpn have access
when i change the firewall wireguard rule to
source linux_pc and destination this firewall i loose connection with the web gui.
And "linux_pc" is the IP address of your Linux system inside the WG tunnel?
the linux_pc is the ip address of a machine inside a vlan that connect to the wireguard client
Then shouldn't that rule be placed on the VLAN interface instead of the WG tunnel interface?
Possibly I misunderstand the topology. Could you provide a drawing?
i place that rule on vlan network, but on the wireguard rule i need to include also??
if i dont while im connect from the linux_pc vlan with wireguard client i loose connection
or better what rule should i put on wireguard to allow access from linux_pc that use a wireguard client
vlan linux---->linux_pc------->wireguard client linux pc
Why do you connect to your OPNsense via WG when you are in a directly connected VLAN? Please provide a diagram.
ok i see, maybe my falt
i need to create an alias for the client defined in the wireguard vpn peers (ip) instead of the vlan client linux_pc
then i create a rule for wireguard that allow from source wireguard peer(linux_pc1) destination this firewall
is that will work
i want to connect from the wireguard instead of the vlan client to have an extra layer of security.
And in which way would that add security? You control the LAN infrastructure, don't you?
Anyway you need to connect to the firewalls address inside the tunnel from the client and put the client address inside the tunnel into the firewall alias.
If you try to connect to the VLAN address of the firewall even with the WG tunnel active, the client will use the local VLAN connection. Directly attached beats route.
thats make sense Patrick.
thank you for your explanation,you have solve my problem.