Messages

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.

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.

So, finally dug into this quite a bit and it would appear as though the way the instructions state to setup Wireguard may have worked fine in 20.1, but definitely shouldn't work in 20.1 either. The allowed IP range needs to be the /32 Wireguard address only. I think I saw another post where this is stated as well. Once I did that, problem is resolved.

[unique]

To expand on this further, it appears as though wg0 needs a unique route. Whatever you put into Allowed IP's creates a static route. If the route exists already, Wireguard fails to start. I created a Allowed IP range and mask that includes the 3 subnets that I want to allow and it is now working. But, if I specify the IP's like I previously had them, it fails.

Update:

I figured out the problem and it appears as though if the client allowed IP range has multiple ranges, it breaks. If I change it to a single range, then it works just fine. Looking like a bug here.

Attached are the screenshots.

Yesterday, I performed the upgrade from 20.1 to 20.7. After upgrading, everything appeared to be in working order. However, last night, I discovered that Wireguard, which I had installed and configured prior to the upgrade, was broken. While the enable, server, and client screens appear to work, the other screens (configuration and handshake) are broken and do not load. Uninstalling the packages or reinstalling the packages require reboots in order for the plugins to actually be visible. I'm not seeing anything in the logs either so I'm not sure if the packages are installing but not enabling or if something is failing.

Any help (or somewhere to look for the logs) would be appreciated. I would prefer to use Wireguard over OpenVPN for my VPN.