Re: Re: Troubleshooting WireGuard connections

Re: Re: Troubleshooting WireGuard connections

[Riccardo Berto]

I wasn't clear in the previous email, I'm only seeing ICMP requests and 
not answers so no traffic through the tunnel.
Also, I have not setup forwarding to another interface, maybe that's the 
next step for a road-warrior OpenVPN-like setup, but at the moment I'm 
keeping things simple and I'm just trying to figure out how to have an 
internal private network only.
As for the ports, the different ports per host is silly but I needed 
that because 3 of my hosts are under the same Wi-Fi and I needed to open 
different ports in the router to forward traffic to the right devices 
easily.

This is the output of the command requested:

rpi3-two pi # tcpdump -ni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 
262144 bytes
10:35:02.177750 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
1, length 64
10:35:03.232761 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
2, length 64
10:35:04.272760 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
3, length 64
10:35:05.312754 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
4, length 64
10:35:06.352767 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
5, length 64
10:35:07.392772 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
6, length 64
10:35:08.432740 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
7, length 64
10:35:09.472758 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
8, length 64
10:35:10.512756 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
9, length 64
10:35:11.552763 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
10, length 64
10:35:12.592774 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
11, length 64
10:35:13.632778 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
12, length 64
10:35:14.672774 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
13, length 64
10:35:15.712755 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
14, length 64
10:35:16.752756 IP 10.0.0.3 > 10.0.0.1: ICMP echo request, id 25708, seq 
15, length 64
^C
15 packets captured
15 packets received by filter
0 packets dropped by kernel

This was run from a Raspberry Pi. I only have requests to 10.0.0.1 but 
no answer, while on 10.0.0.4 (my laptop) I get:

clevo-W230SD riccardo # tcpdump -ni any icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol 
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 
262144 bytes
11:17:04.666013 IP 10.0.0.4 > 10.0.0.1: ICMP echo request, id 3840, seq 
1, length 64
11:17:04.785000 IP 10.0.0.1 > 10.0.0.4: ICMP echo reply, id 3840, seq 1, 
length 64
11:17:05.667080 IP 10.0.0.4 > 10.0.0.1: ICMP echo request, id 3840, seq 
2, length 64
11:17:05.808343 IP 10.0.0.1 > 10.0.0.4: ICMP echo reply, id 3840, seq 2, 
length 64
11:17:06.668457 IP 10.0.0.4 > 10.0.0.1: ICMP echo request, id 3840, seq 
3, length 64
11:17:06.832267 IP 10.0.0.1 > 10.0.0.4: ICMP echo reply, id 3840, seq 3, 
length 64
11:17:07.670317 IP 10.0.0.4 > 10.0.0.1: ICMP echo request, id 3840, seq 
4, length 64
11:17:07.820143 IP 10.0.0.1 > 10.0.0.4: ICMP echo reply, id 3840, seq 4, 
length 64

As it should be, I get replies on this host.

I must repeat that "sometimes" also 10.0.0.3 works, so I'd exclude a 
firewall/pubkeys configuration error. Without touching it it breaks, 
though.
Last time it worked I let it ping for hours at a fast pace just to keep 
it working. I then stopped to ping and a certain amount of time later I 
tried again and the wg0 interface wasn't working anymore.

Great WireGuard guide on your blog by the way.

Re: Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

When you type "wg", does it show you a "latest handshake"? If not,
perhaps they're not even communicating at all. For this, you could
look for udp packets on port 21 and see what's up.

Also, you might simplify things a bit by:
- Removing all mentions of Endpoint on the server, since the server
will learn these from roaming
- Removing all mentions of Port on the clients, since these can be
randomly selected

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

I didn't think about using tcpdump by checking the default interface, 
thanks for the suggestion!

I updated to the April 2018 snapshot on every peer.

I removed the server endpoints and since I was there, switched the 
server port to 51820, the protocol "default" one. It still works for the 
laptop but not on the 2 Raspberry Pis. When I run `ping 10.0.0.1` from 
one of them and `tcpdump -i ens3 'port 51820'` on the server, I promptly 
get this message:

00:20:36.146370 IP (tos 0x0, ttl 52, id 16258, offset 0, flags [none], 
proto UDP (17), length 176)
     net-2-34-88-190.cust.vodafonedsl.it.51821 > rcrd-online.51820: [udp 
sum ok] UDP, length 148

and it stops there, with no ping answers. When I stop the ping command 
with Ctrl-C, after a few moments I get:

00:20:36.146853 IP (tos 0x88, ttl 64, id 12226, offset 0, flags [none], 
proto UDP (17), length 120)
     rcrd-online.51820 > net-2-34-88-190.cust.vodafonedsl.it.51821: [bad 
udp cksum 0x8ebc -> 0xabb8!] UDP, length 92

and then STDOUT returns silent... Inexorably waiting for some other 
packet that never arrives...

Trying `ping 10.0.0.1` from the laptop (that has always worked with 0 
issues) works correctly but tcpdump on the server shows a bad UDP 
checksum, not sure if this is expected behavior.

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

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

Re: 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@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

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Hi Riccardo,

That's a confusing result. The tcpdump also shows two sequences of
completed handshakes happening, about 7 seconds apart. It might be
best in the end to hop onto IRC next week, and we can debug this in
real time. But based on the erratic behavior, my only guess remaining
is that you've mixed up the public and private keys -- perhaps sharing
a private key amongst hosts -- and so one session is interrupting the
handshake of another? Hmm...

Jason

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

Sorry for the late answer, I've been busy with exams this week.

I updated WireGuard to the latest snapshot 20180420 on both server and 
peers.

I use unique key pairs for every host and I'm using the right 
privkey/pubkey combo, I just checked manually via the `wg pubkey` 
command.
I also tried removing all the peers but one Raspberry Pi, I'm still 
getting this weird output on the server from `tcpdump -vv -ni ens3 'port 
51820'`:

15:45:49.138470 IP (tos 0x0, ttl 52, id 27235, offset 0, flags [none], 
proto UDP (17), length 176)
     raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:45:49.138883 IP (tos 0x88, ttl 64, id 2728, offset 0, flags [none], 
proto UDP (17), length 120)
     server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x0eae!] UDP, length 92
15:46:05.778398 IP (tos 0x0, ttl 52, id 27850, offset 0, flags [none], 
proto UDP (17), length 176)
     raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:46:05.778890 IP (tos 0x88, ttl 64, id 5807, offset 0, flags [none], 
proto UDP (17), length 120)
     server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x85d0!] UDP, length 92
15:46:22.419043 IP (tos 0x0, ttl 52, id 28761, offset 0, flags [none], 
proto UDP (17), length 176)
     raspberry-ip.51820 > server-ip.51820: [udp sum ok] UDP, length 148
15:46:22.419748 IP (tos 0x88, ttl 64, id 8596, offset 0, flags [none], 
proto UDP (17), length 120)
     server-ip.51820 > raspberry-ip.51820: [bad udp cksum 0x92e3 -> 
0x6d8c!] UDP, length 92

Removing everything and simply adding the "always working" peer (my 
laptop) in the server config makes it working perfectly fine.

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Hi Riccardo,

Hmm, I'm really not quite sure from looking at that tcpdump. Are you
able to do one in parallel from the raspi? (Make sure both clocks are
correct with ntpd, so we can synchronize the timestamps.)

Alternatively, maybe just log onto IRC next week and we can debug this
in real time?

Jason

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Oh, one thing that looks suspect is the bad UDP checksum. It appears
to be 0x92e3 every time, instead of the correct value (or 0).

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Could you let me know which kernel the non-working rapsis are running?
Also, have you tried this over different internet connections and
experienced the same thing?

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

On 2018-04-20 21:51, Jason A. Donenfeld wrote:
> Could you let me know which kernel the non-working rapsis are running?
> Also, have you tried this over different internet connections and
> experienced the same thing?

I haven't tried this under different internet connection but one thing I 
must add is that the laptop is under the same local network of the 
raspberrys, they have the same gateway and the laptop works in 100% of 
the cases I tried it, both while pinging from the raspberrys and not.

Parallel execution on the raspberry of `tcpdump -vv -ni eth0 'port 
51820'` while pinging the server:

22:26:50.084184 IP (tos 0x88, ttl 64, id 45462, offset 0, flags [none], 
proto UDP (17), length 176)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 -> 
0xb3e7!] UDP, length 148
22:26:50.186665 IP (tos 0x0, ttl 48, id 31466, offset 0, flags [none], 
proto UDP (17), length 120)
     server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
22:26:50.187667 IP (tos 0x0, ttl 64, id 45466, offset 0, flags [none], 
proto UDP (17), length 156)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x0316!] UDP, length 128
22:26:51.098777 IP (tos 0x0, ttl 64, id 45520, offset 0, flags [none], 
proto UDP (17), length 156)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x6049!] UDP, length 128
22:26:52.138753 IP (tos 0x0, ttl 64, id 45595, offset 0, flags [none], 
proto UDP (17), length 156)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x5608!] UDP, length 128
22:26:53.178751 IP (tos 0x0, ttl 64, id 45691, offset 0, flags [none], 
proto UDP (17), length 156)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x7eb3!] UDP, length 128
22:26:54.218760 IP (tos 0x0, ttl 64, id 45734, offset 0, flags [none], 
proto UDP (17), length 156)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 -> 
0x240c!] UDP, length 128
22:27:05.259544 IP (tos 0x88, ttl 64, id 46342, offset 0, flags [none], 
proto UDP (17), length 176)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 -> 
0x5a78!] UDP, length 148
22:27:05.359976 IP (tos 0x0, ttl 48, id 33703, offset 0, flags [none], 
proto UDP (17), length 120)
     server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
22:27:05.360960 IP (tos 0x0, ttl 64, id 46348, offset 0, flags [none], 
proto UDP (17), length 60)
     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf5e3 -> 
0x7f66!] UDP, length 32

192.168.1.155 listed there is the static IP address of the raspberry pi 
in my local network.

Raspberry is running archlinuxarm with kernel: "Linux rpi3-two 
4.14.34-1-ARCH #1 SMP Mon Apr 16 19:15:19 UTC 2018 armv7l GNU/Linux"

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

On 2018-04-20 22:31, Riccardo Berto wrote:
> On 2018-04-20 21:51, Jason A. Donenfeld wrote:
>> Could you let me know which kernel the non-working rapsis are running?
>> Also, have you tried this over different internet connections and
>> experienced the same thing?
> 
> I haven't tried this under different internet connection but one thing
> I must add is that the laptop is under the same local network of the
> raspberrys, they have the same gateway and the laptop works in 100% of
> the cases I tried it, both while pinging from the raspberrys and not.
> 
> Parallel execution on the raspberry of `tcpdump -vv -ni eth0 'port
> 51820'` while pinging the server:
> 
> 22:26:50.084184 IP (tos 0x88, ttl 64, id 45462, offset 0, flags
> [none], proto UDP (17), length 176)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 ->
> 0xb3e7!] UDP, length 148
> 22:26:50.186665 IP (tos 0x0, ttl 48, id 31466, offset 0, flags [none],
> proto UDP (17), length 120)
>     server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
> 22:26:50.187667 IP (tos 0x0, ttl 64, id 45466, offset 0, flags [none],
> proto UDP (17), length 156)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 ->
> 0x0316!] UDP, length 128
> 22:26:51.098777 IP (tos 0x0, ttl 64, id 45520, offset 0, flags [none],
> proto UDP (17), length 156)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 ->
> 0x6049!] UDP, length 128
> 22:26:52.138753 IP (tos 0x0, ttl 64, id 45595, offset 0, flags [none],
> proto UDP (17), length 156)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 ->
> 0x5608!] UDP, length 128
> 22:26:53.178751 IP (tos 0x0, ttl 64, id 45691, offset 0, flags [none],
> proto UDP (17), length 156)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 ->
> 0x7eb3!] UDP, length 128
> 22:26:54.218760 IP (tos 0x0, ttl 64, id 45734, offset 0, flags [none],
> proto UDP (17), length 156)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf643 ->
> 0x240c!] UDP, length 128
> 22:27:05.259544 IP (tos 0x88, ttl 64, id 46342, offset 0, flags
> [none], proto UDP (17), length 176)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf657 ->
> 0x5a78!] UDP, length 148
> 22:27:05.359976 IP (tos 0x0, ttl 48, id 33703, offset 0, flags [none],
> proto UDP (17), length 120)
>     server-ip.51820 > 192.168.1.155.51820: [udp sum ok] UDP, length 92
> 22:27:05.360960 IP (tos 0x0, ttl 64, id 46348, offset 0, flags [none],
> proto UDP (17), length 60)
>     192.168.1.155.51820 > server-ip.51820: [bad udp cksum 0xf5e3 ->
> 0x7f66!] UDP, length 32
> 
> 192.168.1.155 listed there is the static IP address of the raspberry
> pi in my local network.
> 
> Raspberry is running archlinuxarm with kernel: "Linux rpi3-two
> 4.14.34-1-ARCH #1 SMP Mon Apr 16 19:15:19 UTC 2018 armv7l GNU/Linux"

I tried the RPis with another connection and they worked briefly but 
most of the time they don't respond. I configured another laptop under 
the same other network connection and everything works seamlessly. It 
seems that the RPis just don't like WireGuard. I might have some network 
misconfiguration on them but I really can't figure it out.

Re: Troubleshooting WireGuard connections

[Jason A. Donenfeld]

Hi Riccardo,

We really should debug this in real time. Perhaps pop into #wireguard
on Freenode?

Jason

Re: Troubleshooting WireGuard connections

[logcabin]

Strange. I've been running WG on an RPI 3 with Raspbian (Stretch) with no problems. The Pi is reached via a squid proxy which tunnels out to a server in the US.

On Wed, Apr 25, 2018, at 7:51 AM, Jason A. Donenfeld wrote:
> Hi Riccardo,
> 
> We really should debug this in real time. Perhaps pop into #wireguard
> on Freenode?
> 
> Jason
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

It's really great to hear that RPi3 can run WireGuard. That excludes the 
architectural difference from the issues I'm having.

I tried to reach you on freenode in 2 occasions last week, I also 
mentioned you but the channel wasn't active. I'm travelling atm and I'll 
be afk until monday, so next week is good for you?

Should I just mention you again and leave the IRC client open?

Thanks for the interest in my noob problem, though.

Re: Troubleshooting WireGuard connections

[Riccardo Berto]

On 2018-04-25 13:51, Jason A. Donenfeld wrote:
> Hi Riccardo,
> 
> We really should debug this in real time. Perhaps pop into #wireguard
> on Freenode?
> 
> Jason

I investigated the issue I was having with the 2 rpi3s and I finally got 
it working somehow (aka without knowing exactly what I did wrong).

I've just arrived in my hometown and accessed a rpi2 that runs the alarm 
system of my parents' house. I completely ignored the firewall and port 
associations, I just configured a new WireGuard interface with my main 
WireGuard hub as a peer and it worked flawlessly.

So I disabled the firewall on both the rpi3s, got someone to disable the 
port associations of my apartment's router and managed to get both the 
"randomly" working rpi3s to work in outgoing and incoming traffic! There 
was a HUGE warm-up delay, though:

rpi3 pi # ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=238 ttl=64 time=98.8 ms
64 bytes from 10.0.0.1: icmp_seq=239 ttl=64 time=97.2 ms
64 bytes from 10.0.0.1: icmp_seq=240 ttl=64 time=97.3 ms
64 bytes from 10.0.0.1: icmp_seq=241 ttl=64 time=97.1 ms
64 bytes from 10.0.0.1: icmp_seq=242 ttl=64 time=98.1 ms
64 bytes from 10.0.0.1: icmp_seq=243 ttl=64 time=97.0 ms
64 bytes from 10.0.0.1: icmp_seq=244 ttl=64 time=97.2 ms
64 bytes from 10.0.0.1: icmp_seq=245 ttl=64 time=97.5 ms
64 bytes from 10.0.0.1: icmp_seq=246 ttl=64 time=97.1 ms
64 bytes from 10.0.0.1: icmp_seq=247 ttl=64 time=97.1 ms
64 bytes from 10.0.0.1: icmp_seq=248 ttl=64 time=97.2 ms
^C
--- 10.0.0.1 ping statistics ---
248 packets transmitted, 11 received, 95% packet loss, time 256349ms
rtt min/avg/max/mdev = 97.068/97.463/98.844/0.524 ms

This got solved somehow by the `PersistentKeepalive` feature.

I think the whole issue I was having was related to the firewall/port 
associations and systemd's services start order that sometimes was right 
and some other time wasn't, hence the randomly working peers. I really 
don't know what I did wrong on the firewall side, though. Maybe it was 
the port association thing that got my network confused.

Ending morale: if you happen to have multiple peers on the same network, 
be very well aware of what you are doing with the ports/firewalls.

I'm still having quite a lot of bad UDP checksums though, from every 
peer. But the whole network works fine so I should just ignore them, 
right?

Kudos to Jason for this awesome Virtual Private Network, I'm speechless.

Re: Troubleshooting WireGuard connections

[Eric Light]

Hi Riccardo,

Welcome!  Not off-topic at all.

Your config looks fine to my eyes; I don't think you _need_ different ports per endpoint, but I might be wrong.

With your tcpdump, if you can see incoming ICMP requests you should see outgoing ones too -- make sure they're not coming in on wg0 and going out on eth0; I've had that happen to me before.  Can you send through the output of: `tcpdump -ni any icmp`?

E

--------------------------------------------
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

On Thu, 12 Apr 2018, at 21:09, Riccardo Berto wrote:
> WireGuard doesn't always work with my devices.
> I ran out of options for troubleshooting it so I'm writing here, hoping 
> for a stable solution. I see it's not a strict devel-only mailing list 
> but if I'm off-topic I apologize in advance and I'll fade-out in the 
> background, waiting for better times.
> 
> Here's my problem: WireGuard "sometimes" works. I have a client that 
> always talks with the server without problems (the laptop, 10.0.0.4), it 
> always pings and trasfers data correctly. It just works as expected. I 
> have 2 others (Raspberry Pis: 10.0.0.2, 10.0.0.3) that don't work most 
> of the time. I tried enabling the PersistentKeepalive feature on those 
> and the WireGuard interface has some low traffic due to it but no chance 
> of pinging or having traffic with them 99 times out of 100. "tcpdump -i 
> wg0" shows ping requests, from both sides, but no answers.
> In the rare occasions they work, I can ping everyone from every client, 
> as expected with my configuration files.
> 
> Also, with all the devices I tried both the new systemd-networkd's 
> WireGuard implementation and systemd's wg-quick@wg0.service method, as 
> well as testing manually with wg-quick. The systemd version is 238.
> Archlinux is running on every node and I'm using the latest publicly 
> available WireGuard snapshot as of writing this, 20180304.
> 
> 
> #####################################
> # Server config (VPS on vultr.com): #
> #####################################
> [Interface]
> Address = 10.0.0.1/24
> SaveConfig = true
> ListenPort = 21
> PrivateKey = ------------
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.3/32
> Endpoint = Client1:51820
> PersistentKeepalive = 30
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.4/32
> Endpoint = Client3:51821
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.2/32
> Endpoint = Client2:21
> PersistentKeepalive = 30
> 
> 
> #####################################
> # Client 1 config (Raspberry Pi 3): #
> #####################################
> [Interface]
> Address = 10.0.0.3/24
> ListenPort = 51820
> PrivateKey = ------------
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.1/24
> Endpoint = VPS:21
> 
> 
> #####################################
> # Client 2 config (Raspberry Pi 3): #
> #####################################
> [Interface]
> Address = 10.0.0.2/24
> PrivateKey = ------------
> ListenPort = 21
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.1/24
> Endpoint = VPS:21
> 
> 
> ##############################################
> # Client 3 config (personal laptop, x86_64): #
> ##############################################
> [Interface]
> Address = 10.0.0.4/24
> ListenPort = 51821
> PrivateKey = ------------
> 
> [Peer]
> PublicKey = ------------
> AllowedIPs = 10.0.0.0/24
> Endpoint = VPS:21
> 
> 
> 
> Any help is appreciated.
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard

Troubleshooting WireGuard connections

[Riccardo Berto]

WireGuard doesn't always work with my devices.
I ran out of options for troubleshooting it so I'm writing here, hoping 
for a stable solution. I see it's not a strict devel-only mailing list 
but if I'm off-topic I apologize in advance and I'll fade-out in the 
background, waiting for better times.

Here's my problem: WireGuard "sometimes" works. I have a client that 
always talks with the server without problems (the laptop, 10.0.0.4), it 
always pings and trasfers data correctly. It just works as expected. I 
have 2 others (Raspberry Pis: 10.0.0.2, 10.0.0.3) that don't work most 
of the time. I tried enabling the PersistentKeepalive feature on those 
and the WireGuard interface has some low traffic due to it but no chance 
of pinging or having traffic with them 99 times out of 100. "tcpdump -i 
wg0" shows ping requests, from both sides, but no answers.
In the rare occasions they work, I can ping everyone from every client, 
as expected with my configuration files.

Also, with all the devices I tried both the new systemd-networkd's 
WireGuard implementation and systemd's wg-quick@wg0.service method, as 
well as testing manually with wg-quick. The systemd version is 238.
Archlinux is running on every node and I'm using the latest publicly 
available WireGuard snapshot as of writing this, 20180304.


#####################################
# Server config (VPS on vultr.com): #
#####################################
[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 21
PrivateKey = ------------

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.3/32
Endpoint = Client1:51820
PersistentKeepalive = 30

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.4/32
Endpoint = Client3:51821

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.2/32
Endpoint = Client2:21
PersistentKeepalive = 30


#####################################
# Client 1 config (Raspberry Pi 3): #
#####################################
[Interface]
Address = 10.0.0.3/24
ListenPort = 51820
PrivateKey = ------------

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.1/24
Endpoint = VPS:21


#####################################
# Client 2 config (Raspberry Pi 3): #
#####################################
[Interface]
Address = 10.0.0.2/24
PrivateKey = ------------
ListenPort = 21

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.1/24
Endpoint = VPS:21


##############################################
# Client 3 config (personal laptop, x86_64): #
##############################################
[Interface]
Address = 10.0.0.4/24
ListenPort = 51821
PrivateKey = ------------

[Peer]
PublicKey = ------------
AllowedIPs = 10.0.0.0/24
Endpoint = VPS:21



Any help is appreciated.