Since upgrading to FC33, which of course implements systemd-resolved, I cannot get wireguard connections to my VPN provider to work.
Unlike some other distros, Fedora’s version of the NetworkManager doesn’t (yet?) provide a wireguard plugin for a VPN connection that you can toggle on and off in the gui, but I was previously (FC32) able to get the connection to work with a simple:
$ sudo systemctl start wg-quick@wg0
$ sudo wg-quick up wg0
Well, the connection is made successfully (e.g. shows active to ‘sudo wg’) but there is no change in the main routing table. It seems that the wg-quick command does update the routing but does so in a separate routing table, which it names with the port number for some reason, i.e. ‘table 51820’ as shown below:
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.100.2.240/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] nft -f /dev/fd/63
The purpose of having multiple routing tables is for separate interfaces and policy routing as far as I understand, but I have to admit that I don’t know how the system would know to use one routing table or another if both have default routes.
‘resolvectl dns’ shows that link wg0 has the correct dns server but nothing goes there, presumbaly due to the apparently ‘failed’ routing.
Anyway, all subsequent attempts to use the ‘up’ wireguard connection fail. For example, a ‘dig’ to the VPN’s dns server just hangs, as does ping, curl, etc, etc. I tried manually adding a ‘regular’ route to the subnet specified for this wireguard VPN (via dev wg0), but it makes no difference - every network access attempt still hangs.
There are also similar issues if I start the connection via the alternative method of using NetworkManager’s cli interface:
$ sudo nmcli connection up test-wg0
That does update the main routing table but sets a default route to dev wg0 which is of lower priority that the existing default (i.e. metric 20050 for some reason). I can modify the latter, but end up with the same outcome as using wg-quick - i.e., nothing actually seems to go down the wireguard tunnel.
Can anyone assist ?