Re: Troubleshooting WireGuard connections
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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" ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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? ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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). ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Re: Troubleshooting WireGuard connections
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Troubleshooting WireGuard connections
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 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Troubleshooting WireGuard connections
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
