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!
