Troubleshooting WireGuard connections

[Riccardo Berto]

On 2018-04-14 03:26, Jason A. Donenfeld wrote:
> Hi Riccardo,
> 
> Based on those tcpdump timestamps, it looks like the handshake
> response happens nearly immediately after the handshake initiation.
> Yet from your description, it appears only after many moments. In my
> experience, tcpdump blocks like this when it has to do too many DNS
> resolutions and the resolver is slow. You might get a more accurate
> picture of what is going on if you additionally pass `-n` to tcpdump,
> which should make the packets appear more instantaneously.
> 
> Jason

I used tne -n flag on tcpdump now and I'm having the exact same problem. 
Now DNS servers aren't involved.
It worked briefly the first time I tried. I was happily getting ICMP 
requests and responses on the client. Then I stopped `ping 10.0.0.1` 
and, without touching anything, ran it again and it hung.

#################
# Client output #
#################
rpi3-two pi # ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
^C
--- 10.0.0.1 ping statistics ---
25 packets transmitted, 0 received, 100% packet loss, time 24954ms


#################
# Server output #
#################
╭─root at rcrd-online /etc/wireguard
╰─# tcpdump -vv -ni ens3 'port 51820'
tcpdump: listening on ens3, link-type EN10MB (Ethernet), capture size 
262144 bytes
09:49:43.996538 IP (tos 0x0, ttl 52, id 25142, offset 0, flags [none], 
proto UDP (17), length 176)
     ---.51821 > ---.51820: [udp sum ok] UDP, length 148
09:49:43.997138 IP (tos 0x88, ttl 64, id 42124, offset 0, flags [none], 
proto UDP (17), length 120)
     ---.51820 > ---.51821: [bad udp cksum 0x92e3 -> 0xb363!] UDP, length 
92
09:50:00.636714 IP (tos 0x0, ttl 52, id 26161, offset 0, flags [none], 
proto UDP (17), length 176)
     ---.51821 > ---.51820: [udp sum ok] UDP, length 148
09:50:00.637240 IP (tos 0x88, ttl 64, id 48907, offset 0, flags [none], 
proto UDP (17), length 120)
     ---.51820 > ---.51821: [bad udp cksum 0x92e3 -> 0xefc7!] UDP, length 
92