Cannot get wireguard client working on Ubuntu 20.04

Question

I have set up a WireGuard server, which is running fine: I can connect an Android phone to it successfully, also a client on a laptop running Windows. But, I can't get the Ubuntu 20.04 installed on the same laptop to connect (which is ironic since the wireguard server is also running under Ubuntu 20.04).

If it is of any importance, Ubuntu has been upgraded from 18.04, and I tried running wireguard there too (though I don't remember if successfully or not). In the meantime I have purged wireguard, made sure the ppa is removed, and reinstalled from the "official" repository. I have also tried network-manager-wireguard (using the apt sources as described here) instead of manually configuring via /etc/wireguard, with no change in outcome.

My client config is (/etc/wireguard/wg0.conf):

[Interface]
PrivateKey = clientprivatekey
Address = 192.168.1.3/32
ListenPort = clientport
DNS = ip-of-DNS-in-destination-network

[Peer]
PublicKey = serverpublickey
PresharedKey = presharedkey
Endpoint = fully.qualified.domain.server.name:serverport
AllowedIPs = 0.0.0.0/0

The respective peer section on the server also exists:

[Interface]
Address = 192.168.1.1/24
SaveConfig = false
PrivateKey = serverprivatekey
ListenPort = serverport

[Peer]
PublicKey = clientpublickey
PresharedKey = presharedkey
AllowedIPs = 192.168.1.3/32

UFW is set up to let through UDP traffic on the proper port (the ListenPort above), but I've also tried disabling UFW completely on the client to rule out any interference by it.

When connecting via sudo wg-quick up wg0, sudo wg show shows:

$ sudo wg
interface: wg0
  public key: clientpublickey
  private key: (hidden)
  listening port: clientport
  fwmark: 0xca6c

peer: serverpublickey
  preshared key: (hidden)
  endpoint: serverip:serverport
  allowed ips: 0.0.0.0/0
  transfer: 0 B received, 148 B sent

So, it seems to be connected; but it never received anything. The same command on the server shows no handshake to have taken place yet (so from the server side it looks like the client never connected).

I've also tried using the network-manager-wireguard plugin, it also shows a message saying that the connection was "successful", but the output from wg stays the same.

So something seems to be blocking the WireGuard traffic, but I don't know what, and I don't know how to debug. The client seems to think it's connected, but it's not reaching the server? Probably I'm missing something very simple, but I'm totally stuck; thanks in advance for your help!

Edit: Output of $ wg-quick up wg0 on client:

[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 192.168.1.3/24 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
[#] iptables-restore -n

ip a output once connection is configured to be up:

server:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp2s0: <NO-CARRIER,...
3: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether MAC brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.142/24 brd 192.168.0.255 scope global dynamic noprefixroute enp3s0
       valid_lft 769974sec preferred_lft 769974sec
    inet6 ...
12: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 192.168.1.1/24 scope global wg0
       valid_lft forever preferred_lft forever

client:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp59s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN  ...
4: usb0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
    link/ether MAC brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.67/24 brd 192.168.42.255 scope global dynamic noprefixroute usb0
       valid_lft 3301sec preferred_lft 3301sec
    inet6 ...
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 192.168.1.3/24 scope global wg0
       valid_lft forever preferred_lft forever

Output of route -n from the laptop when wg0 is up on both ends:

Kernel IP routing table
0.0.0.0         192.168.42.129  0.0.0.0         UG    100    0        0 usb0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 usb0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wg0
192.168.42.0    0.0.0.0         255.255.255.0   U     100    0        0 usb0

(note that I changed the internet connection - I previously tried via WiFi, since I am now at home I tried via USB tethering to my phone, hence the usb0 address getting the 192.168.42... address).

Output of ping 192.168.1.1 from the laptop when wg0 is up on both ends:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8185ms

Output of traceroute 1.1.1.1 from the laptop when wg0 is up on both ends:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 ... (you get the gist)

Output of traceroute 1.1.1.1 from the laptop when wg0 is down on the laptop:

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  _gateway (192.168.43.1)  4.736 ms  4.858 ms  5.571 ms
 2  * * *
 3  10.15.19.26 (10.15.19.26)  103.204 ms  103.372 ms  103.038 ms
 4  * * *
 5  185099072070.public.t-mobile.at (185.99.72.70)  103.646 ms  103.488 ms  103.795 ms
 6  vix.as13335.net (193.203.0.195)  103.900 ms  40.076 ms  40.039 ms
 7  one.one.one.one (1.1.1.1)  28.038 ms  32.379 ms  32.238 ms

(note that this was on a different occasion when connected via a mobile Hotspot, hence the difference in subnet (192.168.42.x above vs. 192.168.43. here)

So I'm very sure now that something on the Ubuntu client side is preventing wireguard traffic from going out. But what could it be? My current suspicions of what might go wrong include

• a protection mechanism is interfering (but it must be on the client's side, as other connections to the same server work without problem) - e.g. AppArmor/... or some firewall other than ufw (i.e. which is active even if ufw is disabled)
• some routing problem (routing should be set up automatically by wireguard, right? How can I check this?)
• some incompatibility of wireguard/wg-quick and Ubuntu 20.04

Any specific log I can check for problems maybe?

More Edit: I now tried the server/client communication via nc (as recommended by @FedonKadifeli below; and I see the Test Message on server side - so this definitely is a wireguard problem. How do I now debug the wireguard connection attempt?

Just tried a fresh Ubuntu 20.04 on a VirtualBox (as suggested in the answers) - and after a initially being able to reproduce the issue (when I had forgotten to restart the server), I could get a connection. This lead me on the right track to the solution - see below!

Solution 1

Turns out the answer was very simple (and to my shame, could not be detected by the fine people here, since I had left out the - admittedly privacy-critical - keys):

I had apparently used a private key left over from a previous install (which did not match the public key I gave to the server). Once I fixed the keys to match, the connection worked!

What I find strange though is that the wireguard on the client doesn't give any feedback that it couldn't properly establish a connection (or even better that the server did not accept its key)? That would have helped me narrow down the problem; but probably the keys should have been the first thing to double/triple-check!

Solution 2

The first thing you should do would be to check the connectivity between the WireGuard server and the client:

• Bring down WireGuard on both sides.
• On the server run: nc -lu serverport where serverport is the UDP port you used in WireGuard.
• On the client run: echo Test message | nc -4u -w1 fully.qualified.domain.server.name serverport
• The test message send by the client should be displayed on the server's terminal.

Assuming the serverport is accessible by the client, you can go on and test WireGuard.

---

In the server configuration [Peer] section

AllowedIPs = 192.168.1.3/32

is correct. However, in the client configuration [Interface] section you should enter

Address = 192.168.1.3/24

or some mask value (instead of /24) which is the same as given in the server configuration's [Interface] section. Please, check the server configuration [Interface] section and determine what network mask value you have been using in the Address line. If it is /24, then the above value I have given should be entered in the client configuration.

---

Also, the

ListenPort = clientport

line in the client configuration is not needed, because that line belongs to the server configuration: It is the server that listens, not the client.

Comments

[muru]

Please add a tag wiki and excerpt for the new tag: askubuntu.com/edit-tag-wiki/9334

[codeling]

thanks for the comments! I changed my config according to your comments, but the situation unfortunately stays the same. ListenPort is just ignored I guess; the Address lines in the other clients actually has /32, but they still work as expected; I could imagine they cannot contact other VPN'ed hosts in the 192.168.1.x subnet, haven't checked that - they do have access to other local machines (in the 192.168.0.x subnet) and the internet.

[FedKad]

I do have a very similar configuration (Ubuntu - Ubuntu) and it is working ok. I can share the details of my configuration if you want...

[codeling]

I suspect it's not the configuration, but some other protection mechanism (firewall, AppArmor, ...?) which is interfering - since wireguard thinks it has connected, but no actual packages being received ...

[Jo-Erlend Schinstad]

I'm not an expert on this, but WireGuard is based on UDP, which doesn't use connections. I'm guessing that the server just doesn't respond since your key is invalid. If so, then how would the client know that something was wrong and that the service simply wasn't up at the moment?

[codeling]

yes I guess that's it, thanks for sharing your thoughts! It might make sense to mention this behavior in wireguard setup guides a bit more prominently . But fault's definitely on me for not checking the public/private key pair as first thing ;)

[Jo-Erlend Schinstad]

One of the biggest problems in FOSS is that we grow used to things. We really need fresh eyes to bring our attention to what should be improved. You should contact them and explain your experience.

[Olaini Lature]

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker.