* Re: Re: Troubleshooting WireGuard connections
@ 2018-04-13 9:23 Riccardo Berto
2018-04-13 21:54 ` Jason A. Donenfeld
0 siblings, 1 reply; 16+ messages in thread
From: Riccardo Berto @ 2018-04-13 9:23 UTC (permalink / raw)
To: wireguard
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Re: Troubleshooting WireGuard connections
2018-04-13 9:23 Re: Troubleshooting WireGuard connections Riccardo Berto
@ 2018-04-13 21:54 ` Jason A. Donenfeld
[not found] ` <33d0fd1f4c60919b98b50e2b9d04fe78@rcrdbrt.com>
0 siblings, 1 reply; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-13 21:54 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
[not found] ` <33d0fd1f4c60919b98b50e2b9d04fe78@rcrdbrt.com>
@ 2018-04-13 22:36 ` Riccardo Berto
2018-04-14 1:26 ` Jason A. Donenfeld
0 siblings, 1 reply; 16+ messages in thread
From: Riccardo Berto @ 2018-04-13 22:36 UTC (permalink / raw)
To: jason; +Cc: wireguard
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-13 22:36 ` Riccardo Berto
@ 2018-04-14 1:26 ` Jason A. Donenfeld
2018-04-14 7:56 ` Riccardo Berto
0 siblings, 1 reply; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-14 1:26 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-14 1:26 ` Jason A. Donenfeld
@ 2018-04-14 7:56 ` Riccardo Berto
2018-04-14 23:19 ` Jason A. Donenfeld
2018-04-20 13:57 ` Riccardo Berto
0 siblings, 2 replies; 16+ messages in thread
From: Riccardo Berto @ 2018-04-14 7:56 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-14 7:56 ` Riccardo Berto
@ 2018-04-14 23:19 ` Jason A. Donenfeld
2018-04-20 13:57 ` Riccardo Berto
1 sibling, 0 replies; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-14 23:19 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-14 7:56 ` Riccardo Berto
2018-04-14 23:19 ` Jason A. Donenfeld
@ 2018-04-20 13:57 ` Riccardo Berto
2018-04-20 19:37 ` Jason A. Donenfeld
1 sibling, 1 reply; 16+ messages in thread
From: Riccardo Berto @ 2018-04-20 13:57 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-20 13:57 ` Riccardo Berto
@ 2018-04-20 19:37 ` Jason A. Donenfeld
2018-04-20 19:39 ` Jason A. Donenfeld
0 siblings, 1 reply; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-20 19:37 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-20 19:37 ` Jason A. Donenfeld
@ 2018-04-20 19:39 ` Jason A. Donenfeld
2018-04-20 19:51 ` Jason A. Donenfeld
0 siblings, 1 reply; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-20 19:39 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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).
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-20 19:39 ` Jason A. Donenfeld
@ 2018-04-20 19:51 ` Jason A. Donenfeld
2018-04-20 20:31 ` Riccardo Berto
0 siblings, 1 reply; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-20 19:51 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-20 19:51 ` Jason A. Donenfeld
@ 2018-04-20 20:31 ` Riccardo Berto
2018-04-25 11:46 ` Riccardo Berto
0 siblings, 1 reply; 16+ messages in thread
From: Riccardo Berto @ 2018-04-20 20:31 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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"
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-20 20:31 ` Riccardo Berto
@ 2018-04-25 11:46 ` Riccardo Berto
2018-04-25 11:51 ` Jason A. Donenfeld
0 siblings, 1 reply; 16+ messages in thread
From: Riccardo Berto @ 2018-04-25 11:46 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-25 11:46 ` Riccardo Berto
@ 2018-04-25 11:51 ` Jason A. Donenfeld
2018-04-25 12:40 ` logcabin
` (2 more replies)
0 siblings, 3 replies; 16+ messages in thread
From: Jason A. Donenfeld @ 2018-04-25 11:51 UTC (permalink / raw)
To: Riccardo Berto; +Cc: WireGuard mailing list
Hi Riccardo,
We really should debug this in real time. Perhaps pop into #wireguard
on Freenode?
Jason
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-25 11:51 ` Jason A. Donenfeld
@ 2018-04-25 12:40 ` logcabin
2018-04-25 22:56 ` Riccardo Berto
2018-04-26 9:52 ` Riccardo Berto
2 siblings, 0 replies; 16+ messages in thread
From: logcabin @ 2018-04-25 12:40 UTC (permalink / raw)
To: wireguard
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
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-25 11:51 ` Jason A. Donenfeld
2018-04-25 12:40 ` logcabin
@ 2018-04-25 22:56 ` Riccardo Berto
2018-04-26 9:52 ` Riccardo Berto
2 siblings, 0 replies; 16+ messages in thread
From: Riccardo Berto @ 2018-04-25 22:56 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Troubleshooting WireGuard connections
2018-04-25 11:51 ` Jason A. Donenfeld
2018-04-25 12:40 ` logcabin
2018-04-25 22:56 ` Riccardo Berto
@ 2018-04-26 9:52 ` Riccardo Berto
2 siblings, 0 replies; 16+ messages in thread
From: Riccardo Berto @ 2018-04-26 9:52 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: WireGuard mailing list
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.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2018-04-26 9:51 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-04-13 9:23 Re: Troubleshooting WireGuard connections Riccardo Berto
2018-04-13 21:54 ` Jason A. Donenfeld
[not found] ` <33d0fd1f4c60919b98b50e2b9d04fe78@rcrdbrt.com>
2018-04-13 22:36 ` Riccardo Berto
2018-04-14 1:26 ` Jason A. Donenfeld
2018-04-14 7:56 ` Riccardo Berto
2018-04-14 23:19 ` Jason A. Donenfeld
2018-04-20 13:57 ` Riccardo Berto
2018-04-20 19:37 ` Jason A. Donenfeld
2018-04-20 19:39 ` Jason A. Donenfeld
2018-04-20 19:51 ` Jason A. Donenfeld
2018-04-20 20:31 ` Riccardo Berto
2018-04-25 11:46 ` Riccardo Berto
2018-04-25 11:51 ` Jason A. Donenfeld
2018-04-25 12:40 ` logcabin
2018-04-25 22:56 ` Riccardo Berto
2018-04-26 9:52 ` Riccardo Berto
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).