FC33 - Cannot connect to VPN with wireguard

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 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 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 ?

1 Like

This works fine for me: WireGuard + NetworkManager + systemd-resolved + Fedora 33

Just import the proper connection profile:

1 Like

Thanks, but as I said above I’ve tried the nmcli route and it doesn’t work for me. The only difference from prior is an upgrade from FC32 to FC33. For completeness, I just tried again by importing a new wireguard conf file to a different VPN location and the result was the same - ‘sudo wg’ shows connected but the network is ‘frozen’ until I take the connection down.

However, after investing EUR 5.00 in a new account at mullvad.net, I can readily connect using their app to their various wireguard servers. It’s just the wg-quick and nmcli that don’t work for me but I’d really like to get them working as mullvad servers seem often more geo-blocked than some other VPNs.

It wasn’t clear whether you tried to run a working client profile, i.e.:

sudo wg-quick up wg.conf

Also try to import the same config on another device, e.g. Android.

Does it show a handshake?

Run monitoring while trying to activate the connection:

sudo tcpdump -n -i any udp port 51820

Well, having downloaded and successfully used the mullvad wireguard conf files outside of their app, it then became a simple question of why my other VPN (Keepsolid/VPNunlimited) didn’t work in the same software environment.

After a quick test with their app in a Windows 10 VM which worked, I was eventually advised to redownload their conf files and found they now worked fine. All of the keys had changed as had the endpoint IP address. So, it seems just an unfortunate coincidence of timing that their changes were more or less the same day that I upgraded to FC33. I’d had quite a few issues in my Rawhide VM with upgrades to FC33 and to the current FC34 (e.g. NetworkManager crashes requiring downgrade of Glib2) so was kind of expecting there might also be problems with the release of FC33.

Thanks again to those who offered assistance - much appreciated.

1 Like

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.