Wireguard Broken after Successful Upgrade

[Schubbie]

Take a look at the list.jpg I think so.
If I type a false key in the Windows-Client I get another screen. So I think that the Server is started.

I have the issue too, that the Server didn't start, if I configure and aktivate more than 1 Client on the WireGuard-Server.

My other WireGuard-Server on my Synology runs in a VM and works after the last WireGuard Update only with WireGuard on OPNsense I have such issues.

This usually happens when endpoint has no /32

But did you see any Failure in my Screenshots?

[tezgno]

Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.

Two things to check:

First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.

[mimugmail]

Screenshots looks good.

/usr/local/etc/rc.d/wireguard restart

Output please

[Schubbie]

Code Select Expand


root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart
[#] rm -f /var/run/wireguard/wg0.sock
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90
[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[+] Backgrounding route monitor


[murmelbahn]

Sadly I have some errors too: None of my clients are able to connect to wireguard. The service is started but there is no connection. I have this error in 2 instances. One is a VM another is on an apu. When I run:

/usr/local/etc/rc.d/wireguard restart

I get the following code:

Code Select Expand

/usr/local/etc/rc.d/wireguard restart
wg-quick: `wg0' is not a WireGuard interface
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:40:08 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.IKz26dvT/sh-np.UBog8P
[#] ifconfig wg0 inet 100.65.0.1/24 100.65.0.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] resolvconf -a wg0 -x
[#] route -q -n add -inet 100.65.0.9/32 -interface wg0
[#] route -q -n add -inet 100.65.0.8/32 -interface wg0
[#] route -q -n add -inet 100.65.0.7/32 -interface wg0
[#] route -q -n add -inet 100.65.0.6/32 -interface wg0
[#] route -q -n add -inet 100.65.0.5/32 -interface wg0
[#] route -q -n add -inet 100.65.0.4/32 -interface wg0
[#] route -q -n add -inet 100.65.0.3/32 -interface wg0
[#] route -q -n add -inet 100.65.0.2/32 -interface wg0
[#] route -q -n add -inet 100.65.0.15/32 -interface wg0
[#] route -q -n add -inet 100.65.0.14/32 -interface wg0
[#] route -q -n add -inet 100.65.0.13/32 -interface wg0
[#] route -q -n add -inet 100.65.0.12/32 -interface wg0
[#] route -q -n add -inet 100.65.0.11/32 -interface wg0
[#] route -q -n add -inet 100.65.0.10/32 -interface wg0
[#] route -q -n add -inet 192.168.6.0/24 -interface wg0
[#] resolvconf -d wg0
[#] rm -f /var/run/wireguard/wg0.sock

[mimugmail]

Code Select Expand


root@OPNsense:~ # /usr/local/etc/rc.d/wireguard restart
[#] rm -f /var/run/wireguard/wg0.sock
[#] wireguard-go wg0
INFO: (wg0) 2020/08/17 09:15:09 Starting wireguard-go version 0.0.20200320
[#] wg setconf wg0 /tmp/tmp.UvX0PTXh/sh-np.B2qr90
[#] ifconfig wg0 inet 10.10.11.1/24 10.10.11.1 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[+] Backgrounding route monitor


Do you see packets in wg0 when you ping 10.10.11.1 from endpoint?

[murmelbahn]

After a little bit of testing I can give the following infos:

When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.

[mimugmail]

After a little bit of testing I can give the following infos:

When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.

Which is normal behavior except for Site 2 Site. FreeBSD was more relaxed against misconfig

[Schubbie]

Do you see packets in wg0 when you ping 10.10.11.1 from endpoint?

I don´t configure wg0 in OPNsense i use "WireGuard" under Firewall -> Rules for Rules. The Log hangs after the last Update. It works only a few minutes, so i can´t see it.

If i Ping 10.10.11.1 (WireGuard-IP) in the same Network with WireGuard running on the same Client, it is reachabel. If i connect to my mobile Network, restart WireGuard, than IP 10.10.11.1 is not reachabel, cause the Tunnel is not working.

To test i have left only one allowed IP-Range /24 on the Clients Configuration, but it dosen´t make a difference.

[mimugmail]

I mean a packet capture on wg interface, do you see incoming packets?

[gurpal2000]

Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.

Two things to check:

First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.

I think the default wg firewall entry is "all inclusive" (Any).

Anyway, previously I would have had entries like this "10.10.0.0/24, 192.168.2.0/24" in the Allowed IPs. To me, these are ranges of IP addresses.

Under the new version, I have to change these to "10.10.0.2/32,192.168.2.1/24". Now first is a very specific IP (no range) which is the only end of the tunnel in a VPS. It's fine.

The second is actually the IP address of an LXC bridge on a VPS where the wg client lives. But because /24 is a range, it includes other IP addresses on the 2.x subnet. Which is also fine.

So things work better, and I can do what I used to do before I think. I don't understand why - which is worrying for me (a newbie).

[Schubbie]

I mean a packet capture on wg interface, do you see incoming packets?

I have configured WG0 as Interface, what should not be needed, if I don't want to tunnel my Internettraffic. The Paket Capture show no entries.

[tezgno]

Thanks this seems to have fixed it for me also. Removed all entries and then put the actual wg ip address with a /32 on the end; lastly bounced wg. Although now I can't ping other subnets.

Two things to check:

First, make sure that your firewall allows for traffic from WG to your other subnets. Second, on the client side, make sure that your allowed subnets includes the ones you want to access.

I think the default wg firewall entry is "all inclusive" (Any).

Anyway, previously I would have had entries like this "10.10.0.0/24, 192.168.2.0/24" in the Allowed IPs. To me, these are ranges of IP addresses.

Under the new version, I have to change these to "10.10.0.2/32,192.168.2.1/24". Now first is a very specific IP (no range) which is the only end of the tunnel in a VPS. It's fine.

The second is actually the IP address of an LXC bridge on a VPS where the wg client lives. But because /24 is a range, it includes other IP addresses on the 2.x subnet. Which is also fine.

So things work better, and I can do what I used to do before I think. I don't understand why - which is worrying for me (a newbie).

That field doesn't do what you think it does. The only thing that should be in the "Allowed IP" is the /32. If you put the /24 in there, what you think you are doing is allowing that IP range to be accessed by the client when they connect. What's actually happening is that the IP range you put there is being assigned to the wg0 interface as a static route. When you do this, all traffic that is destined to the 192.168.2.1/24 interface range will be directed through the wg0 interface, on the VPN or off it. Your network connections will work, but you'll have a performance issue and likely even a firewall bypass issue.

Personally, I think this is a bug in how that is setup. What I'm doing to provide network segmentation like how I had it previously is I'm using the firewall to allow the certain subnets.

[murmelbahn]

After a little bit of testing I can give the following infos:

When one of the clients attached to a wireguard server contains more then one ip address / network the interface for this server seems not to be starting. if you only have clients with only one ip adress in the server subnet, the interface for the server is starting and you can connect to the server.

Which is normal behavior except for Site 2 Site. FreeBSD was more relaxed against misconfig

Aaah thank you for this. After using only the tunnel IP in the client settings everything is working. Have to use Firewall rules for access of different subnets but thats no problem.

[Schubbie]

Did you use OPNsense 20.7.1 or an older Version? I don't get it to work again after Update. I use the same Client Configuration with another Tunnel-IP and another Port for the VM. on my Synology where it works.