From hsaber at gmail.com  Wed Sep  1 09:03:16 2021
From: hsaber at gmail.com (=?UTF-8?B?2K3Yp9mF2K8g2LXYp9io2LE=?=)
Date: Wed, 1 Sep 2021 13:33:16 +0430
Subject: =?UTF-8?Q?Unexpected_experience_of_site=2Dto=2Dsite_wireguard_tunn?=
 =?UTF-8?Q?eling=E2=80=8F=E2=80=8F?=
In-Reply-To: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
References: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
Message-ID: <CAECraRro-ZQrZbxBkQg=o1bnWmf1V4C65D0jkdkt2rMCCe+6bg@mail.gmail.com>

Dear friends,
I have configured 3 wireguard interfaces on 2 servers to act as a
chained VPN for me (to bypass the internet censorship in my country),
with this schema:

client -- wg0 on middle-node -- wg1 on middle node -- wg2 on exit node
(to free internet)

Everything works fine, but after a while, the connection between wg1
and wg2 drops and I can't find the reason. The connection comes back
to action by simply switching the wg1 down and up again using
wg-quick. And the amazing behaviour is that sometimes the connection
comes back to work automatically  after some random time passes,
without any actions from my side (sometimes after a few tens of
minutes, sometimes after a few hours).
When the wg1-wg2 connection is not working, anything else between 2
servers (middle-node and exit-node) works fine. I mean I can ping the
public IP of each server from another part, but the local wireguard ip
of none of them are accessible.

I tried to monitor the situation and read the logs but couldn't find
what is happening here, so please help!

The configuration:
======================

client (my mobile phone):
-------------------------------------------
[Interface]
Address = 10.10.20.2/32
PrivateKey =  <private key of client>
DNS = 10.10.10.1

### Middle Node
[Peer]
PublicKey =  <public key of wg0>
PresharedKey =  <preshared key>
AllowedIPs = 0.0.0.0/0
Endpoint = middle-node:50842
======================

wg0 (in middle-node server):
-------------------------------------------
[Interface]
Address = 10.10.20.1/24
ListenPort = 50842
PrivateKey =  <private key of wg0>

### Client
[Peer]
PublicKey =  <public key of client>
PresharedKey =  <preshared key>
AllowedIPs = 10.10.20.2/32
======================

wg1 (again in middle-node server):
-------------------------------------------
[Interface]
Address = 10.10.10.2/32
PrivateKey =  <private key of wg1>

PostUp = ip route add default dev wg1 table middle
PostUp = ip rule add iif wg0 lookup middle
PostUp = wg set wg1 peer <publickey of wg2 (in exit-node)> allowed-ips 0.0.0.0/0

PreDown = ip route del default dev wg1 table middle
PreDown = ip rule del iif wg0 lookup middle

### Exit Node
[Peer]
PublicKey =  <publickey of wg2 (in exit-node)>
PresharedKey =  <preshared key>
AllowedIPs = 10.10.10.1/32
Endpoint = exit-node:50842
PersistentKeepalive = 25
======================

wg2 (in exit-node server):
-------------------------------------------
[Interface]
Address = 10.10.10.1/24
ListenPort = 50842
PrivateKey =  <private key of wg2>

PostUp   = iptables -A FORWARD -i eth0 -o wg2 -j ACCEPT
PostUp   = iptables -A FORWARD -i wg2 -j ACCEPT
PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

PostDown = iptables -D FORWARD -i eth0 -o wg2 -j ACCEPT
PostDown = iptables -D FORWARD -i wg2 -j ACCEPT
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

### Middle Node
[Peer]
PublicKey =  <publickey of wg1 (in middle-node)>
PresharedKey =  <preshared key>
AllowedIPs = 10.0.0.0/8
======================
======================
======================

Sample log of dmesg when the wg1-wg2 connection is not working:
-------------------------------------------
[Wed Sep  1 11:19:32 2021] wireguard: wg1: Sending keepalive packet to
peer 12 (~exit-node-ip~:50842)
[Wed Sep  1 11:19:44 2021] wireguard: wg0: Sending keepalive packet to
peer 8 (~client-ip~:65323)
[Wed Sep  1 11:19:44 2021] wireguard: wg1: Receiving keepalive packet
from peer 12 (~exit-node-ip~:50842)
[Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving handshake
initiation from peer 8 (~client-ip~:65323)
[Wed Sep  1 11:20:09 2021] wireguard: wg0: Sending handshake response
to peer 8 (~client-ip~:65323)
[Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2867 destroyed for peer 8
[Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2871 created for peer 8
[Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving keepalive packet
from peer 8 (~client-ip~:65323)
[Wed Sep  1 11:21:19 2021] wireguard: wg0: Sending keepalive packet to
peer 8 (~client-ip~:65323)
[Wed Sep  1 11:21:24 2021] wireguard: wg1: Retrying handshake with
peer 12 (~exit-node-ip~:50842) because we stopped hearing back after
15 seconds
[Wed Sep  1 11:21:24 2021] wireguard: wg1: Sending handshake
initiation to peer 12 (~exit-node-ip~:50842)
[Wed Sep  1 11:21:30 2021] wireguard: wg1: Handshake for peer 12
(~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
2)
======================

Sample log of dmesg when the wg1-wg2 connection is coming back using
manual restart:
-------------------------------------------
[Wed Sep  1 11:45:52 2021] wireguard: wg1: Sending handshake
initiation to peer 12 (~exit-node-ip~:50842)
[Wed Sep  1 11:45:52 2021] wireguard: wg0: Sending keepalive packet to
peer 8 (~client-ip~:2335)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Handshake for peer 12
(~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
3)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
initiation to peer 12 (~exit-node-ip~:50842)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2878 destroyed for peer 12
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 12
(~exit-node-ip~:50842) destroyed
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface destroyed
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface created
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 13 created
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending keepalive packet to
peer 13 (~exit-node-ip~:50842)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
initiation to peer 13 (~exit-node-ip~:50842)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Receiving handshake
response from peer 13 (~exit-node-ip~:50842)
[Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2881 created for peer 13
[Wed Sep  1 11:46:12 2021] wireguard: wg0: Receiving keepalive packet
from peer 8 (~client-ip~:2335)
[Wed Sep  1 11:46:14 2021] wireguard: wg1: Receiving keepalive packet
from peer 13 (~exit-node-ip~:50842)
[Wed Sep  1 11:46:27 2021] wireguard: wg0: Sending keepalive packet to
peer 8 (~client-ip~:2335)
[Wed Sep  1 11:46:28 2021] wireguard: wg1: Receiving keepalive packet
from peer 13 (~exit-node-ip~:50842)
[Wed Sep  1 11:46:52 2021] wireguard: wg1: Receiving keepalive packet
from peer 13 (~exit-node-ip~:50842)


Thanks in advance for your kind help

From Jason at zx2c4.com  Wed Sep  1 13:46:14 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 1 Sep 2021 15:46:14 +0200
Subject: [PATCH v2 07/63] skbuff: Switch structure bounds to struct_group()
In-Reply-To: <20210818060533.3569517-8-keescook@chromium.org>
References: <20210818060533.3569517-1-keescook@chromium.org>
 <20210818060533.3569517-8-keescook@chromium.org>
Message-ID: <CAHmME9pmXsfgiavSrv6+Eh8C0qrfuYRoQoLvT5EQZz4OdZj=Ww@mail.gmail.com>

For the drivers/net/wireguard part,

Reviewed-by: Jason A. Donenfeld <Jason at zx2c4.com>

From Jason at zx2c4.com  Wed Sep  1 13:55:43 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 1 Sep 2021 15:55:43 +0200
Subject: [PATCH net] wireguard: remove peer cache in netns_pre_exit
In-Reply-To: <20210901122904.9094-1-liuhangbin@gmail.com>
References: <20210901122904.9094-1-liuhangbin@gmail.com>
Message-ID: <YS+GX/Y85bch4gMU@zx2c4.com>

Hi Hangbin,

Thanks for the patch and especially for the test. While I see that
you've pointed to a real problem, I don't think that this particular way
of fixing it is correct, because it will cause issues for userspace that
expects to be able to read back the list of peers for, for example,
keeping track of the latest endpoint addresses or rx/tx transfer
quantities.

I think the real solution here is to simply clear the endpoint src cache
and consequently the dst_cache. This is slightly complicated by the fact
that dst_cache releases dsts lazily, so I needed to add a little utility
function for that, but that was pretty easy to do.

Can you take a look at the below patch and let me know if it works for
you and passes other testing you and Toke might be doing with it? (Also,
please CC the wireguard mailing list in addition to netdev next time?)
If the patch looks good to you and works well, I'll include it in the
next series of wireguard patches I send back out to netdev. I'm back
from travels next week and will begin working on the next series then.

Regards,
Jason

---------8<-------------8<-----------------

>From f9984a41eeaebfdcef5aba8a71966b77ba0de8c0 Mon Sep 17 00:00:00 2001
From: "Jason A. Donenfeld" <Jason at zx2c4.com>
Date: Wed, 1 Sep 2021 14:53:39 +0200
Subject: [PATCH] wireguard: device: reset peer src endpoint when netns exits
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Each peer's endpoint contains a dst_cache entry that takes a reference
to another netdev. When the containing namespace exits, we take down the
socket and prevent future sockets from being created (by setting
creating_net to NULL), which removes that potential reference on the
netns. However, it doesn't release references to the netns that a netdev
cached in dst_cache might be taking, so the netns still might fail to
exit. Since the socket is gimped anyway, we can simply clear all the
dst_caches (by way of clearing the endpoint src), which will release all
references.

However, the current dst_cache_reset function only releases those
references lazily. But it turns out that all of our usages of
wg_socket_clear_peer_endpoint_src are called from contexts that are not
exactly high-speed or bottle-necked. For example, when there's
connection difficulty, or when userspace is reconfiguring the interface.
And in particular for this patch, when the netns is exiting. So for
those cases, it makes more sense to call dst_release immediately. For
that, we add a small helper function to dst_cache.

This patch also adds a test to netns.sh from Hangbin Liu to ensure this
doesn't regress.

Test-by: Hangbin Liu <liuhangbin at gmail.com>
Reported-by: Xiumei Mu <xmu at redhat.com>
Cc: Hangbin Liu <liuhangbin at gmail.com>
Cc: Toke H?iland-J?rgensen <toke at redhat.com>
Cc: Paolo Abeni <pabeni at redhat.com>
Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references")
Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
---
 drivers/net/wireguard/device.c             |  3 +++
 drivers/net/wireguard/socket.c             |  2 +-
 include/net/dst_cache.h                    | 11 ++++++++++
 net/core/dst_cache.c                       | 19 +++++++++++++++++
 tools/testing/selftests/wireguard/netns.sh | 24 +++++++++++++++++++++-
 5 files changed, 57 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
index 551ddaaaf540..77e64ea6be67 100644
--- a/drivers/net/wireguard/device.c
+++ b/drivers/net/wireguard/device.c
@@ -398,6 +398,7 @@ static struct rtnl_link_ops link_ops __read_mostly = {
 static void wg_netns_pre_exit(struct net *net)
 {
 	struct wg_device *wg;
+	struct wg_peer *peer;
 
 	rtnl_lock();
 	list_for_each_entry(wg, &device_list, device_list) {
@@ -407,6 +408,8 @@ static void wg_netns_pre_exit(struct net *net)
 			mutex_lock(&wg->device_update_lock);
 			rcu_assign_pointer(wg->creating_net, NULL);
 			wg_socket_reinit(wg, NULL, NULL);
+			list_for_each_entry(peer, &wg->peer_list, peer_list)
+				wg_socket_clear_peer_endpoint_src(peer);
 			mutex_unlock(&wg->device_update_lock);
 		}
 	}
diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c
index 8c496b747108..6f07b949cb81 100644
--- a/drivers/net/wireguard/socket.c
+++ b/drivers/net/wireguard/socket.c
@@ -308,7 +308,7 @@ void wg_socket_clear_peer_endpoint_src(struct wg_peer *peer)
 {
 	write_lock_bh(&peer->endpoint_lock);
 	memset(&peer->endpoint.src6, 0, sizeof(peer->endpoint.src6));
-	dst_cache_reset(&peer->endpoint_cache);
+	dst_cache_reset_now(&peer->endpoint_cache);
 	write_unlock_bh(&peer->endpoint_lock);
 }
 
diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
index 67634675e919..df6622a5fe98 100644
--- a/include/net/dst_cache.h
+++ b/include/net/dst_cache.h
@@ -79,6 +79,17 @@ static inline void dst_cache_reset(struct dst_cache *dst_cache)
 	dst_cache->reset_ts = jiffies;
 }
 
+/**
+ *	dst_cache_reset_now - invalidate the cache contents immediately
+ *	@dst_cache: the cache
+ *
+ *	The caller must be sure there are no concurrent users, as this frees
+ *	all dst_cache users immediately, rather than waiting for the next
+ *	per-cpu usage like dst_cache_reset does. Most callers should use the
+ *	higher speed lazily-freed dst_cache_reset function instead.
+ */
+void dst_cache_reset_now(struct dst_cache *dst_cache);
+
 /**
  *	dst_cache_init - initialize the cache, allocating the required storage
  *	@dst_cache: the cache
diff --git a/net/core/dst_cache.c b/net/core/dst_cache.c
index be74ab4551c2..0ccfd5fa5cb9 100644
--- a/net/core/dst_cache.c
+++ b/net/core/dst_cache.c
@@ -162,3 +162,22 @@ void dst_cache_destroy(struct dst_cache *dst_cache)
 	free_percpu(dst_cache->cache);
 }
 EXPORT_SYMBOL_GPL(dst_cache_destroy);
+
+void dst_cache_reset_now(struct dst_cache *dst_cache)
+{
+	int i;
+
+	if (!dst_cache->cache)
+		return;
+
+	dst_cache->reset_ts = jiffies;
+	for_each_possible_cpu(i) {
+		struct dst_cache_pcpu *idst = per_cpu_ptr(dst_cache->cache, i);
+		struct dst_entry *dst = idst->dst;
+
+		idst->cookie = 0;
+		idst->dst = NULL;
+		dst_release(dst);
+	}
+}
+EXPORT_SYMBOL_GPL(dst_cache_reset_now);
diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh
index 2e5c1630885e..8a9461aa0878 100755
--- a/tools/testing/selftests/wireguard/netns.sh
+++ b/tools/testing/selftests/wireguard/netns.sh
@@ -613,6 +613,28 @@ ip0 link set wg0 up
 kill $ncat_pid
 ip0 link del wg0
 
+# Ensure that dst_cache references don't outlive netns lifetime
+ip1 link add dev wg0 type wireguard
+ip2 link add dev wg0 type wireguard
+configure_peers
+ip1 link add veth1 type veth peer name veth2
+ip1 link set veth2 netns $netns2
+ip1 addr add fd00:aa::1/64 dev veth1
+ip2 addr add fd00:aa::2/64 dev veth2
+ip1 link set veth1 up
+ip2 link set veth2 up
+waitiface $netns1 veth1
+waitiface $netns2 veth2
+ip1 -6 route add default dev veth1 via fd00:aa::2
+ip2 -6 route add default dev veth2 via fd00:aa::1
+n1 wg set wg0 peer "$pub2" endpoint [fd00:aa::2]:2
+n2 wg set wg0 peer "$pub1" endpoint [fd00:aa::1]:1
+n1 ping6 -c 1 fd00::2
+pp ip netns delete $netns1
+pp ip netns delete $netns2
+pp ip netns add $netns1
+pp ip netns add $netns2
+
 # Ensure there aren't circular reference loops
 ip1 link add wg1 type wireguard
 ip2 link add wg2 type wireguard
@@ -631,7 +653,7 @@ while read -t 0.1 -r line 2>/dev/null || [[ $? -ne 142 ]]; do
 done < /dev/kmsg
 alldeleted=1
 for object in "${!objects[@]}"; do
-	if [[ ${objects["$object"]} != *createddestroyed ]]; then
+	if [[ ${objects["$object"]} != *createddestroyed && ${objects["$object"]} != *createdcreateddestroyeddestroyed ]]; then
 		echo "Error: $object: merely ${objects["$object"]}" >&3
 		alldeleted=0
 	fi
-- 
2.32.0

From tech at tootai.net  Wed Sep  1 17:44:47 2021
From: tech at tootai.net (Daniel)
Date: Wed, 1 Sep 2021 19:44:47 +0200
Subject: ipv6 connexion fail - ipv4 OK
In-Reply-To: <d7095107-050f-2075-00cb-fdaa86d6daf5@tootai.net>
References: <ec8fe61d-06a9-9544-ab2c-3dfc26905d74@tootai.net>
 <e4b50341-6f90-92fe-7728-a518768a1b51@tootai.net>
 <20210827211412.3ed5f170@natsu>
 <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net>
 <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net>
 <20210828024454.1766744f@natsu>
 <7437f3e0-26ba-5e33-a175-0cf233635b3f@tootai.net>
 <20210830214312.6a332333@natsu>
 <e620ed11-2664-fa06-1497-a0f18facac7e@tootai.net>
 <20210830223836.5384badd@natsu>
 <e949b3e2-eab7-fc4c-2b15-8820a2c17374@tootai.net>
 <20210830225927.6df90edb@natsu>
 <d7095107-050f-2075-00cb-fdaa86d6daf5@tootai.net>
Message-ID: <eda71620-a941-e2c1-b7b3-bdc67d53e72b@tootai.net>

Again :)

Le 31/08/2021 ? 19:50, Daniel a ?crit?:
> Hi
>
> Le 30/08/2021 ? 19:59, Roman Mamedov a ?crit?:
>> On Mon, 30 Aug 2021 19:44:21 +0200
>> Daniel <tech at tootai.net> wrote:
>>
>>>> Do you get WG working at all, between some other two hosts (not 
>>>> involving this
>>>> particular server for now)?
>>> Yes. Clients are shown on both sides as connected, trafic seems to go
>>> out on each side but other one as received near to nothing.
>> I mean not just "shown as connected", but have you got actual traffic 
>> working
>> between any two hosts. Even just forgetting this server for a while. 
>> So that
>> you can rule out some general issue and concentrate on just the 
>> particular
>> machine setup.
>
> I went a step further. Server has a /64 on eth0, his address being 
> .1/64 Interface I gave to wireguard is called wigserver and get .a2/64 
> as address when up. Now I start the client which is a .24/64 while 
> tcpdump -ni any udp and port 38194 is running on the server. Output is
>
> 19:28:45.790295 eth0? In? IP6 2001:db8:16e:10::24.50012 > 
> 2001:db8:c2c:7c50::a2.38194: UDP, length 148
> 19:28:45.790629 eth0? Out IP6 2001:db8:c2c:7c50::a2.38194 > 
> 2001:db8:16e:10::24.50012: UDP, length 92
> 19:29:06.572059 eth0? Out IP6 2001:db8:c2c:7c50::1.38194 > 
> 2001:db8:16e:10::24.50012: UDP, length 148
> 19:29:11.947969 eth0? Out IP6 2001:db8:c2c:7c50::1.38194 > 
> 2001:db8:16e:10::24.50012: UDP, length 148
> 19:29:17.324065 eth0? Out IP6 2001:db8:c2c:7c50::1.38194 > 
> 2001:db8:16e:10::24.50012: UDP, length 148
>
> As you can see, the original request is going to the right IP which 
> respond with the right source IP (line 1 and 2) From here, all packets 
> are going out with the IP of eth0 not the one from wigserver which is 
> .a2/64. The client has "allowed ips = 10.99.98.0/27, ::/0"
>
> Remember, no FW involved. Before this test I bring up interfaces 
> without wireguard configuration and did server/client test like nc -lu 
> IP PORT on the server while on the client I used nc -u IP PORT 
> Everything worked well. I also started the client while server was not 
> running and got the ICMP6 respons "unreachable port" sended to the 
> client. I also tried to tell to the client to connect to the .1/64 
> insteed of the .a2/64, didn't work
>
> If someone had an idea on what's going on here, would be helpful ;)

I continue my investigations and modify client to connect to eth0 ipv6 
address .1/64 as well that I set debug using # modprobe wireguard && 
echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control 
command. I get the same result that when I connect to the .a2/64 IP 
address from the wireguard server.

Clearly, the first step seems to go well as I see

Sep? 1 19:00:51 kirsch kernel: [ 3597.830187] wireguard: wigserver: 
Receiving handshake initiation from peer 1 ([2001:db8:16e:10::24]:42602/0%0)
Sep? 1 19:00:51 kirsch kernel: [ 3597.830193] wireguard: wigserver: 
Sending handshake response to peer 1 ([2001:db8:16e:10::24]:42602/0%0)
Sep? 1 19:00:51 kirsch kernel: [ 3597.830487] wireguard: wigserver: 
Keypair 1 created for peer 1

but then appear the problem, server did not receive the answer and try 
again and again and again. Please note that it tell 5s but it is in the 
same second or so.

Sep? 1 19:00:52 kirsch kernel: [ 3599.369652] wireguard: wigserver: 
Handshake for peer 1 ([2001:db8:16e:10::24]:42602/0%0) did not complete 
after 5 seconds, r
etrying (try 13)

On the client, the answer is sended with the newly ipv6 address from the 
wireguard interface to the ipv6 address of the server wireguard interface

19:00:57.309251 IP6 2001:db8:c2c:7c50::24.42602 > 
2001:db8:c2c:7c50::1.38194: UDP, length 148

and this too, again and again and again.

Hints ?

Thanks for your support

-- 
Daniel

From dotneutron at protonmail.ch  Thu Sep  2 00:57:30 2021
From: dotneutron at protonmail.ch (Neutron)
Date: Thu, 02 Sep 2021 00:57:30 +0000
Subject: [wireguard-apple] [iOS] Running WireGuard on a simulator
Message-ID: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>

Hello,

I've tried running wireguard-apple on an iOS simulator and encountered some
trouble during the compilation of WireGuardKitGo. I did this on an Apple M1,
which I thought at first would be the culprit.

The Go version is "go1.16 darwin/arm64". The build process fails at
# runtime/cgo
Undefined symbols for architecture arm64:
  "_darwin_arm_init_mach_exception_handler", referenced from:
      _x_cgo_init in _x004.o
  "_darwin_arm_init_thread_exception_port", referenced from:
      _threadentry in _x004.o
      _x_cgo_init in _x004.o
ld: symbol(s) not found for architecture arm64

This issue was reported a few times in Go's issues section, e.g.,
https://github.com/golang/go/issues/45772#issuecomment-874616905

Further head banging lead me to the discovery that

xcodebuild -target WireGuardiOS -sdk iphoneos14.5

actually builds successfully. I looked through the Makefile and applied some
monkey see, monkey do. It turns out I could get it to link by adding
GOOS_iphonesimulator := ios.

For a moment I thought this was a definite win, but it turns out connecting to
one of the test tunnels doesn't do anything. I hit a dead end after finding this
answer on a forum thread.

https://developer.apple.com/forums/thread/651779?answerId=617050022#617050022

"If you?re talking about the iOS Simulator here, be aware that, because of the
way they interact with the networking stack, NetworkExtension providers only
work on real hardware."

I don't have an actual iPhone on hand at the moment, so I guess the question is,
is the project supposed to work only on real hardware? Was that flag left out
intentionally? If so, is there a way to get it to run properly on simulators?

I'm a neophyte when it comes to anything iOS related, so perhaps someone
with more experience can shed some light on the subject.

Neutron

From noloader at gmail.com  Thu Sep  2 01:20:36 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 1 Sep 2021 21:20:36 -0400
Subject: [wireguard-apple] [iOS] Running WireGuard on a simulator
In-Reply-To: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
References: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
Message-ID: <CAH8yC8=T82_UUcWsp3Q6Bv-YgAb2P5rVm-JD7uHRU1+-bmyoOg@mail.gmail.com>

On Wed, Sep 1, 2021 at 9:00 PM Neutron <dotneutron at protonmail.ch> wrote:
>
> I've tried running wireguard-apple on an iOS simulator and encountered some
> trouble during the compilation of WireGuardKitGo. I did this on an Apple M1,
> which I thought at first would be the culprit.
>
> The Go version is "go1.16 darwin/arm64". The build process fails at
> # runtime/cgo
> Undefined symbols for architecture arm64:
>   "_darwin_arm_init_mach_exception_handler", referenced from:
>       _x_cgo_init in _x004.o
>   "_darwin_arm_init_thread_exception_port", referenced from:
>       _threadentry in _x004.o
>       _x_cgo_init in _x004.o
> ld: symbol(s) not found for architecture arm64
>
> This issue was reported a few times in Go's issues section, e.g.,
> https://github.com/golang/go/issues/45772#issuecomment-874616905
>
> Further head banging lead me to the discovery that
>
> xcodebuild -target WireGuardiOS -sdk iphoneos14.5

Yeah, whenever you start seeing problems with missing symbols related
to exception handlers, you should look at the target SDK. I see it a
lot when trying to cross compile for Apple WatchOS and AppleTV when
using the wrong SDK.

Besides -sdk, other ones to look for are -miphoneos-version-min,
-miphonesimulator-version-min, -mappletvos-version-min,
-mappletvsimulator-version-min, -mwatchos-version-min and
-mwatchsimulator-version-min. If you drop them too low, you will break
during link with the missing exception handlers.

I think what happens is, the headers mostly work with a lot of
different targets. But the exception handlers are specific to a
particular SDK, and you only have a limited range of them installed
(otherwise, you have to install older versions of Xcode and older
SDKs).

I don't know how Go affects things. I usually work with native C/C++/ObjC code.

> I don't have an actual iPhone on hand at the moment,
> so I guess the question is, is the project supposed to
> work only on real hardware? Was that flag left out
> intentionally? If so, is there a way to get it to run
> properly on simulators?

In the past, the network stack was crippled on the simulator. I don't
know if that's the case nowadays. I think Android is about the same.
It is hard to test some of this stuff on a simulator or emulator.

Jeff

From noloader at gmail.com  Thu Sep  2 02:10:12 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 1 Sep 2021 22:10:12 -0400
Subject: [wireguard-apple] [iOS] Running WireGuard on a simulator
In-Reply-To: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
References: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
Message-ID: <CAH8yC8nHSHg=rNaXRxjX_LdbGZEFBb+gB6TJkMVkw-cRO-nf-g@mail.gmail.com>

On Wed, Sep 1, 2021 at 9:00 PM Neutron <dotneutron at protonmail.ch> wrote:
> ...
>
> The Go version is "go1.16 darwin/arm64". The build process fails at
> # runtime/cgo
> Undefined symbols for architecture arm64:
>   "_darwin_arm_init_mach_exception_handler", referenced from:
>       _x_cgo_init in _x004.o
>   "_darwin_arm_init_thread_exception_port", referenced from:
>       _threadentry in _x004.o
>       _x_cgo_init in _x004.o
> ld: symbol(s) not found for architecture arm64
>
> This issue was reported a few times in Go's issues section, e.g.,
> https://github.com/golang/go/issues/45772#issuecomment-874616905
>
> Further head banging lead me to the discovery that
>
> xcodebuild -target WireGuardiOS -sdk iphoneos14.5
>
> actually builds successfully. I looked through the Makefile and applied some
> monkey see, monkey do. It turns out I could get it to link by adding
> GOOS_iphonesimulator := ios.

This looks a little odd to me. You should not need ios there because
the M1 is its own first class platform. About all you should need is,
ensure '-arch arm64' is used. But I probably do not understand how Go
does things.

Apple uses simulators, which means your high level C code is compiled
to the host's native instruction set. The host is where the simulator
runs. On an M1, that means code is compiled to the host's arm64
instruction set, hence the reason for '-arch arm64'. You still need to
be aware of a target SDK, but that is a particular detail. The broad
stroke is '-arch arm64' for the M1.

Android uses emulators, which means the high level C code is compiled
to the target ISA, like x86_64, arm, aarch64 or mips. Then, the ISA
instructions are interpreted on the host machine. The high level C
code is not compiled to the emulator's native instruction set.

Jeff

From guy.godfroy at gugod.fr  Thu Sep  2 04:10:05 2021
From: guy.godfroy at gugod.fr (Guy Godfroy)
Date: Thu, 2 Sep 2021 04:10:05 +0000 (UTC)
Subject: Suggestion for WireGuard
In-Reply-To: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
References: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
Message-ID: <12daa07c-f2c5-483c-9c64-7e9a51efd0c6@gugod.fr>

Hello,

I'm not implied in wireguard dev, but I thinks that wouldn't match wireguard mechanism. Indeed AllowedIP isn't only about routing, it is used to match a cryptographic fingerprint to a given IP. Also, having multiple peers containing such thing as DisallowedIP could lead to nonsense.

What don't you use the firewall to block the IP range instead?

From hsaber at gmail.com  Thu Sep  2 04:17:25 2021
From: hsaber at gmail.com (=?UTF-8?B?2K3Yp9mF2K8g2LXYp9io2LE=?=)
Date: Thu, 2 Sep 2021 08:47:25 +0430
Subject: =?UTF-8?Q?Re=3A_Unexpected_experience_of_site=2Dto=2Dsite_wireguard_?=
 =?UTF-8?Q?tunneling=E2=80=8F=E2=80=8F?=
In-Reply-To: <CADGd2Dp0S5_=bPQDnRsamvraJZ5BeVV1eWh98js3wATXodfQcQ@mail.gmail.com>
References: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
 <CAECraRro-ZQrZbxBkQg=o1bnWmf1V4C65D0jkdkt2rMCCe+6bg@mail.gmail.com>
 <CADGd2Dp0S5_=bPQDnRsamvraJZ5BeVV1eWh98js3wATXodfQcQ@mail.gmail.com>
Message-ID: <CAECraRpLYEkAm+g1dg6X9RJLEDx=nOs=gPQvT_CjxwjXSbhDOw@mail.gmail.com>

-Thanks for reply.
For test reasons, I turned the firewall off on my middle-node server.
But I can't understand how this issue may be related to firewall,
because most of the time it works (and to me it means firewall is Ok),
but sometime for some unknown reason it stops working, which when I
restart the wg1 interface with this command everything comes back to
life:
wg-quick down wg1 && wg-quick up wg1

BTW here it is the firewall status of middle-node:
==================
? firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service;
disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)
-----------------------------------
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
-----------------------------------

And the firewall status of exit-node:
====================
Unit firewalld.service could not be found.
---------------------------
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:50842
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
---------------------
Regards

??John Lauro?? <?johnalauro at gmail.com??> ?? ????? ???????? ? ???????
???? ???? ??:?? ????:?
>
> Just a guess, but I would be suspicious about connection tracking causing the issue.  What are your firewall rules?
>
> ?On Wed, Sep 1, 2021 at 9:51 AM ????? ?????? <hsaber at gmail.com> wrote:?
>>
>> Dear friends,
>> I have configured 3 wireguard interfaces on 2 servers to act as a
>> chained VPN for me (to bypass the internet censorship in my country),
>> with this schema:
>>
>> client -- wg0 on middle-node -- wg1 on middle node -- wg2 on exit node
>> (to free internet)
>>
>> Everything works fine, but after a while, the connection between wg1
>> and wg2 drops and I can't find the reason. The connection comes back
>> to action by simply switching the wg1 down and up again using
>> wg-quick. And the amazing behaviour is that sometimes the connection
>> comes back to work automatically  after some random time passes,
>> without any actions from my side (sometimes after a few tens of
>> minutes, sometimes after a few hours).
>> When the wg1-wg2 connection is not working, anything else between 2
>> servers (middle-node and exit-node) works fine. I mean I can ping the
>> public IP of each server from another part, but the local wireguard ip
>> of none of them are accessible.
>>
>> I tried to monitor the situation and read the logs but couldn't find
>> what is happening here, so please help!
>>
>> The configuration:
>> ======================
>>
>> client (my mobile phone):
>> -------------------------------------------
>> [Interface]
>> Address = 10.10.20.2/32
>> PrivateKey =  <private key of client>
>> DNS = 10.10.10.1
>>
>> ### Middle Node
>> [Peer]
>> PublicKey =  <public key of wg0>
>> PresharedKey =  <preshared key>
>> AllowedIPs = 0.0.0.0/0
>> Endpoint = middle-node:50842
>> ======================
>>
>> wg0 (in middle-node server):
>> -------------------------------------------
>> [Interface]
>> Address = 10.10.20.1/24
>> ListenPort = 50842
>> PrivateKey =  <private key of wg0>
>>
>> ### Client
>> [Peer]
>> PublicKey =  <public key of client>
>> PresharedKey =  <preshared key>
>> AllowedIPs = 10.10.20.2/32
>> ======================
>>
>> wg1 (again in middle-node server):
>> -------------------------------------------
>> [Interface]
>> Address = 10.10.10.2/32
>> PrivateKey =  <private key of wg1>
>>
>> PostUp = ip route add default dev wg1 table middle
>> PostUp = ip rule add iif wg0 lookup middle
>> PostUp = wg set wg1 peer <publickey of wg2 (in exit-node)> allowed-ips 0.0.0.0/0
>>
>> PreDown = ip route del default dev wg1 table middle
>> PreDown = ip rule del iif wg0 lookup middle
>>
>> ### Exit Node
>> [Peer]
>> PublicKey =  <publickey of wg2 (in exit-node)>
>> PresharedKey =  <preshared key>
>> AllowedIPs = 10.10.10.1/32
>> Endpoint = exit-node:50842
>> PersistentKeepalive = 25
>> ======================
>>
>> wg2 (in exit-node server):
>> -------------------------------------------
>> [Interface]
>> Address = 10.10.10.1/24
>> ListenPort = 50842
>> PrivateKey =  <private key of wg2>
>>
>> PostUp   = iptables -A FORWARD -i eth0 -o wg2 -j ACCEPT
>> PostUp   = iptables -A FORWARD -i wg2 -j ACCEPT
>> PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
>>
>> PostDown = iptables -D FORWARD -i eth0 -o wg2 -j ACCEPT
>> PostDown = iptables -D FORWARD -i wg2 -j ACCEPT
>> PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
>>
>> ### Middle Node
>> [Peer]
>> PublicKey =  <publickey of wg1 (in middle-node)>
>> PresharedKey =  <preshared key>
>> AllowedIPs = 10.0.0.0/8
>> ======================
>> ======================
>> ======================
>>
>> Sample log of dmesg when the wg1-wg2 connection is not working:
>> -------------------------------------------
>> [Wed Sep  1 11:19:32 2021] wireguard: wg1: Sending keepalive packet to
>> peer 12 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:19:44 2021] wireguard: wg0: Sending keepalive packet to
>> peer 8 (~client-ip~:65323)
>> [Wed Sep  1 11:19:44 2021] wireguard: wg1: Receiving keepalive packet
>> from peer 12 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving handshake
>> initiation from peer 8 (~client-ip~:65323)
>> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Sending handshake response
>> to peer 8 (~client-ip~:65323)
>> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2867 destroyed for peer 8
>> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2871 created for peer 8
>> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving keepalive packet
>> from peer 8 (~client-ip~:65323)
>> [Wed Sep  1 11:21:19 2021] wireguard: wg0: Sending keepalive packet to
>> peer 8 (~client-ip~:65323)
>> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Retrying handshake with
>> peer 12 (~exit-node-ip~:50842) because we stopped hearing back after
>> 15 seconds
>> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Sending handshake
>> initiation to peer 12 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:21:30 2021] wireguard: wg1: Handshake for peer 12
>> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
>> 2)
>> ======================
>>
>> Sample log of dmesg when the wg1-wg2 connection is coming back using
>> manual restart:
>> -------------------------------------------
>> [Wed Sep  1 11:45:52 2021] wireguard: wg1: Sending handshake
>> initiation to peer 12 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:45:52 2021] wireguard: wg0: Sending keepalive packet to
>> peer 8 (~client-ip~:2335)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Handshake for peer 12
>> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
>> 3)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
>> initiation to peer 12 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2878 destroyed for peer 12
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 12
>> (~exit-node-ip~:50842) destroyed
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface destroyed
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface created
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 13 created
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending keepalive packet to
>> peer 13 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
>> initiation to peer 13 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Receiving handshake
>> response from peer 13 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2881 created for peer 13
>> [Wed Sep  1 11:46:12 2021] wireguard: wg0: Receiving keepalive packet
>> from peer 8 (~client-ip~:2335)
>> [Wed Sep  1 11:46:14 2021] wireguard: wg1: Receiving keepalive packet
>> from peer 13 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:46:27 2021] wireguard: wg0: Sending keepalive packet to
>> peer 8 (~client-ip~:2335)
>> [Wed Sep  1 11:46:28 2021] wireguard: wg1: Receiving keepalive packet
>> from peer 13 (~exit-node-ip~:50842)
>> [Wed Sep  1 11:46:52 2021] wireguard: wg1: Receiving keepalive packet
>> from peer 13 (~exit-node-ip~:50842)
>>
>>
>> Thanks in advance for your kind help

From lifeng1519 at gmail.com  Thu Sep  2 04:54:21 2021
From: lifeng1519 at gmail.com (Feng Li)
Date: Thu, 2 Sep 2021 12:54:21 +0800
Subject: Suggestion for WireGuard
In-Reply-To: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
References: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
Message-ID: <CAEK8JBBocnGRt7yFdVqm6Oou-UCYmtO26bzvB=YE7j9BDdjkTw@mail.gmail.com>

I have asked this question some months ago like you,
and don't get my answer, this is a workaround from me
to calculate the AllowedIPs, maybe can help you:
```
#!/usr/bin/python

import ipaddress

def address_exclude(rr, r1):
    out = []
    for r in rr:
        if r1.subnet_of(r):
            out += list(r.address_exclude(r1))
        else:
            out.append(r)
    return out

def calc_exclude(includes, excludes):
    includes_addr = [ ipaddress.ip_network(i) for i in includes ]
    excludes_addr = [ ipaddress.ip_network(e) for e in excludes ]

    for e in excludes_addr:
        includes_addr = address_exclude(includes_addr, e)
    strs = [str(i) for i in includes_addr]
    print("AllowedIPs = " + ",".join(strs))

calc_exclude(includes=['0.0.0.0/0'], excludes=['192.168.0.0/16', '10.0.0.0/8'])
```

I have asked this question here too:
https://www.reddit.com/r/WireGuard/comments/m44fi5/enhance_the_allowedips/

On Wed, Sep 1, 2021 at 9:50 PM Kassem Omega <kassemomega at gmail.com> wrote:
>
> Hi,
>
> I sent this before a couple of times to the mailing list but either it
> didn't go through or it is forbidden somehow? I never got any decision
> from the list moderator that it is forbidden to send suggestions at
> all. Hopefully someone can answer with anything.
>
> I was wondering if there is any chance of adding the opposite of
> AllowedIPs option to WireGuard?
>
> Currently, WireGuard has a whitelist option only that specifies which
> IPs to go through it, however I believe adding the blacklist option
> would be beneficial and easier to configure.
>
> The use case: allowing all traffic to go through WireGuard except
> specific ranges.
>
> Right now to do this I must use this long list of ranges to achieve this:
>
> AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4,
> 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6,
> 172.0.0.0/12, 172.16.0.0/24, 172.32.0.0/11, 172.64.0.0/10,
> 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9,
> 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15,
> 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8,
> 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 8.8.8.8/32
>
> However, if the DisallowedIPs option is available, I'd simply use:
>
> DisallowedIPs = 192.168.0.0/16, 10.0.0.0/8
>
> What do you think?
>
> Thank you.
> Kassem

From dotneutron at protonmail.ch  Thu Sep  2 06:48:48 2021
From: dotneutron at protonmail.ch (Neutron)
Date: Thu, 02 Sep 2021 06:48:48 +0000
Subject: [wireguard-apple] [iOS] Running WireGuard on a simulator
In-Reply-To: <CAH8yC8nHSHg=rNaXRxjX_LdbGZEFBb+gB6TJkMVkw-cRO-nf-g@mail.gmail.com>
References: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
 <CAH8yC8nHSHg=rNaXRxjX_LdbGZEFBb+gB6TJkMVkw-cRO-nf-g@mail.gmail.com>
Message-ID: <4hMWm75HKpodCnXIg9XhHltxE-7XSQVijaKMwRC5XcKpdTEWnZ9Vn4TtWr4k1EdAMbBMMMS4BBPrvNhoisXG-oQLUj_3jErUO76UBfjM2ZY=@protonmail.ch>

Jeff, thank you for the clarification on how a simulator operates compared to an
emulator. The difference was certainly blurry in my head. I did a little more
digging and it turns out

GOOS_iphonesimulator := ios

is not required when targeting an iOS12.0 simulator. I had initially run it with
iOS14.5. Perhaps this line can be useful in the Makefile once the project's iOS
version gets bumped. Still, I would like to know why this happens.

Just like before on iOS14.5, I'm having issues with creating/editing
configurations in the simulator, with log messages like:

Saving configuration failed: Error Domain=NEVPNErrorDomain Code=5 "IPC failed"

The message I'm getting may be just as well be unrelated, but a common theme I'm
seeing is that you can't get Network Extension providers to work on simulators.
This Eskimo fellow seems to have good insight on the matter.

https://developer.apple.com/forums/thread/46004?answerId=134358022#134358022

If it really can't run on a simulator at the moment, perhaps it would be useful
for other tinkerers to see this mentioned somewhere in the README with a brief
reasoning attached. It would be a time saver, especially for those of us who are
not iOS hackers.

Neutron

From noloader at gmail.com  Thu Sep  2 07:02:32 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 2 Sep 2021 03:02:32 -0400
Subject: [wireguard-apple] [iOS] Running WireGuard on a simulator
In-Reply-To: <4hMWm75HKpodCnXIg9XhHltxE-7XSQVijaKMwRC5XcKpdTEWnZ9Vn4TtWr4k1EdAMbBMMMS4BBPrvNhoisXG-oQLUj_3jErUO76UBfjM2ZY=@protonmail.ch>
References: <-_8oxop6VI5mP0UY_0vydSMUBInbj0hR4IUPDWshTaRG0-6O9ybfu6kzIAk68XdY9N-LHiVgaiWhNQw6-iYG1cR14pfODj2o5JMStY-75ns=@protonmail.ch>
 <CAH8yC8nHSHg=rNaXRxjX_LdbGZEFBb+gB6TJkMVkw-cRO-nf-g@mail.gmail.com>
 <4hMWm75HKpodCnXIg9XhHltxE-7XSQVijaKMwRC5XcKpdTEWnZ9Vn4TtWr4k1EdAMbBMMMS4BBPrvNhoisXG-oQLUj_3jErUO76UBfjM2ZY=@protonmail.ch>
Message-ID: <CAH8yC8k--EzaMeAcrpPNjRBnMb5KNLx3aFJemNQg-pQTMxJ=Cg@mail.gmail.com>

On Thu, Sep 2, 2021 at 2:50 AM Neutron <dotneutron at protonmail.ch> wrote:
>
> Jeff, thank you for the clarification on how a simulator operates compared to an
> emulator. The difference was certainly blurry in my head. I did a little more
> digging and it turns out
>
> GOOS_iphonesimulator := ios
>
> is not required when targeting an iOS12.0 simulator. I had initially run it with
> iOS14.5. Perhaps this line can be useful in the Makefile once the project's iOS
> version gets bumped. Still, I would like to know why this happens.

Getting the environment setup correctly is tricky with Clang. With
GCC, you just run 'gcc -dumpmachine' and you can tell what you are
targeting. -dumpmachine does not work with Clang. Clang reports the
host's arch, like x86_64 even if you are targeting iPhone or
iPhoneSimulator or WatchOS or AppleTV.

To get the information from Clang you need to do something like this:
https://github.com/weidai11/cryptopp/blob/master/GNUmakefile#L50. You
have to run the preprocessor with CFLAGS or CXXFLAGS, and look for
defines like __x86_64__ or __aarch64__.

You have to use CFLAGS or CXXFLAGS because that's where you put '-arch
arm64'. Xcode sets this for you in the IDE, but you have to do it
manually when setting up a makefile.

> Just like before on iOS14.5, I'm having issues with creating/editing
> configurations in the simulator, with log messages like:
>
> Saving configuration failed: Error Domain=NEVPNErrorDomain Code=5 "IPC failed"
>
> The message I'm getting may be just as well be unrelated, but a common theme I'm
> seeing is that you can't get Network Extension providers to work on simulators.

Yeah, Apple has some cryptic error messages at times. If you can't
find it while searching, then you have to burn one of those Apple
Support incidences.

> This Eskimo fellow seems to have good insight on the matter.
>
> https://developer.apple.com/forums/thread/46004?answerId=134358022#134358022

Quinn is usually very helpful. He's been supporting Apple development
for as long as I can remember.

Jeff

From lists at lonnie.abelbeck.com  Thu Sep  2 13:46:22 2021
From: lists at lonnie.abelbeck.com (Lonnie Abelbeck)
Date: Thu, 2 Sep 2021 08:46:22 -0500
Subject: Suggestion for WireGuard
In-Reply-To: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
References: <CAJaZ5dPHbc5s=JiCbuBKAGf1Nb3vw0xL9W7_=Na4Skt_pjnWZw@mail.gmail.com>
Message-ID: <A974F498-8534-48EC-8229-7836341BCC6A@lonnie.abelbeck.com>


> On Aug 30, 2021, at 8:19 AM, Kassem Omega <kassemomega at gmail.com> wrote:
> 
> snip...
> 
> The use case: allowing all traffic to go through WireGuard except
> specific ranges.
> 
> Right now to do this I must use this long list of ranges to achieve this:
> 
> AllowedIPs = 0.0.0.0/5, 8.0.0.0/7, 11.0.0.0/8, 12.0.0.0/6, 16.0.0.0/4,
> 32.0.0.0/3, 64.0.0.0/2, 128.0.0.0/3, 160.0.0.0/5, 168.0.0.0/6,
> 172.0.0.0/12, 172.16.0.0/24, 172.32.0.0/11, 172.64.0.0/10,
> 172.128.0.0/9, 173.0.0.0/8, 174.0.0.0/7, 176.0.0.0/4, 192.0.0.0/9,
> 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15,
> 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8,
> 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 8.8.8.8/32
> 
> However, if the DisallowedIPs option is available, I'd simply use:
> 
> DisallowedIPs = 192.168.0.0/16, 10.0.0.0/8

For the IPv4-only case, there is a handy C based tool: iprange [1]

For your example: Allow: 0.0.0.0/0  Disallow: 192.168.0.0/16, 10.0.0.0/8

$ cat allow.ipset 
0.0.0.0/0

$ cat disallow.ipset 
192.168.0.0/16
10.0.0.0/8

$ iprange allow.ipset --exclude-next disallow.ipset
0.0.0.0/5
8.0.0.0/7
11.0.0.0/8
12.0.0.0/6
16.0.0.0/4
32.0.0.0/3
64.0.0.0/2
128.0.0.0/2
192.0.0.0/9
192.128.0.0/11
192.160.0.0/13
192.169.0.0/16
192.170.0.0/15
192.172.0.0/14
192.176.0.0/12
192.192.0.0/10
193.0.0.0/8
194.0.0.0/7
196.0.0.0/6
200.0.0.0/5
208.0.0.0/4
224.0.0.0/3

The output is optimized and sorted.

Lonnie

[1] https://github.com/firehol/iprange






From toke at redhat.com  Thu Sep  2 16:26:23 2021
From: toke at redhat.com (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Thu, 02 Sep 2021 18:26:23 +0200
Subject: [PATCH net] wireguard: remove peer cache in netns_pre_exit
In-Reply-To: <YS+GX/Y85bch4gMU@zx2c4.com>
References: <20210901122904.9094-1-liuhangbin@gmail.com>
 <YS+GX/Y85bch4gMU@zx2c4.com>
Message-ID: <877dfzt040.fsf@toke.dk>

"Jason A. Donenfeld" <Jason at zx2c4.com> writes:

> Hi Hangbin,
>
> Thanks for the patch and especially for the test. While I see that
> you've pointed to a real problem, I don't think that this particular way
> of fixing it is correct, because it will cause issues for userspace that
> expects to be able to read back the list of peers for, for example,
> keeping track of the latest endpoint addresses or rx/tx transfer
> quantities.
>
> I think the real solution here is to simply clear the endpoint src cache
> and consequently the dst_cache. This is slightly complicated by the fact
> that dst_cache releases dsts lazily, so I needed to add a little utility
> function for that, but that was pretty easy to do.
>
> Can you take a look at the below patch and let me know if it works for
> you and passes other testing you and Toke might be doing with it? (Also,
> please CC the wireguard mailing list in addition to netdev next time?)
> If the patch looks good to you and works well, I'll include it in the
> next series of wireguard patches I send back out to netdev. I'm back
> from travels next week and will begin working on the next series then.

Ran this through the same series of tests as the previous patch, and
indeed it also seems to resolve the issue, so feel free to add:

Tested-by: Toke H?iland-J?rgensen <toke at redhat.com>

-Toke


From hsaber at gmail.com  Fri Sep  3 04:09:16 2021
From: hsaber at gmail.com (=?UTF-8?B?2K3Yp9mF2K8g2LXYp9io2LE=?=)
Date: Fri, 3 Sep 2021 08:39:16 +0430
Subject: =?UTF-8?Q?Re=3A_Unexpected_experience_of_site=2Dto=2Dsite_wireguard_?=
 =?UTF-8?Q?tunneling=E2=80=8F=E2=80=8F?=
In-Reply-To: <CAECraRpLYEkAm+g1dg6X9RJLEDx=nOs=gPQvT_CjxwjXSbhDOw@mail.gmail.com>
References: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
 <CAECraRro-ZQrZbxBkQg=o1bnWmf1V4C65D0jkdkt2rMCCe+6bg@mail.gmail.com>
 <CADGd2Dp0S5_=bPQDnRsamvraJZ5BeVV1eWh98js3wATXodfQcQ@mail.gmail.com>
 <CAECraRpLYEkAm+g1dg6X9RJLEDx=nOs=gPQvT_CjxwjXSbhDOw@mail.gmail.com>
Message-ID: <CAECraRra33vTSb3KW_siHrQx3tLSb-boJUQ1=hVDt5Lo6xXcUw@mail.gmail.com>

Hi again,
Something new happened which makes me more confused.
I wrote a small shell-script to check the connection between wg1 and
wg2, so whenever it drops, the script restarts the wg1 and everything
comes back.
Yes yes I don't like this way of addressing issues, but what could I
do if no meaningful debug information exists, and I predict that it
might be a bug of Wireguard itself?
BTW this system worked fine and the anti-censorship VPN chain was up
and running till this morning.
The connection went down at 7:49 and didn't come back with
auto-restart. The process of restarting continued for about 6 minutes,
and at last at 7:55 it came back.
During the outage I checked both sides and everything seemed fine.
Sides could ping the public ip of each other, their wg udp ports were
accessible to each other, and even handshake seemed to be finished
correctly (using wg-show command) but peers couldn't ping each other.
And the most confusing part is everything came back to life without
any action from my side. Just after 6 minutes of continuously
restarting the wg1 interface!
Isn't there a bug? Somebody please help me to debug this problem and
find the cause.

Here I bring you my shell-script code, and then its related log:

-------------------------
#!/bin/bash

exec >>/var/log/wg-ping 2>&1
while true
do
        connection=$(ping -c 1 10.10.10.1)
        time=$(date +%H:%M)
        seconds=$(date +%S)
        seconds=${seconds#0}
        if [[ "$connection" != *"icmp"* ]]; then
          echo " "
          date
          wg-quick down wg1
          echo " "
          wg-quick up wg1
          connection=$(ping -c 1 10.10.10.1)
          time=$(date +%T)
          if [[ "$connection" != *"icmp"* ]]; then
            echo "$time ERROR"
          else
            echo "$time OK"
            echo " "
          fi
        elif [[ $seconds -lt 5  ]]; then
          echo "$time OK"
        fi
        sleep 5
done
===============
Sample log of simply restarting the wg1 which makes everything fine
(and happens every few hours):
-----------------------
01:17 OK
01:18 OK
01:19 OK
01:20 OK
01:21 OK
01:22 OK
01:23 OK
01:24 OK
01:25 OK
01:26 OK

Fri Sep  3 01:26:41 +0430 2021
[#] ip route del default dev wg1 table middle
[#] ip rule del iif wg0 lookup middle
[#] ip link delete dev wg1

[#] ip link add wg1 type wireguard
[#] wg setconf wg1 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg1
[#] ip link set mtu 1420 up dev wg1
[#] ip -4 route add 10.10.10.1/32 dev wg1
[#] ip route add default dev wg1 table middle
[#] ip rule add iif wg0 lookup middle
[#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
01:26:42 OK

01:27 OK
01:28 OK
01:30 OK
01:31 OK
01:32 OK
01:33 OK
01:34 OK
=====================================================
And the log for the confusing situation I explained:
-----------------------
07:45 OK
07:46 OK
07:47 OK
07:48 OK
07:49 OK

Fri Sep  3 07:49:42 +0430 2021
[#] ip route del default dev wg1 table middle
[#] ip rule del iif wg0 lookup middle
[#] ip link delete dev wg1

[#] ip link add wg1 type wireguard
[#] wg setconf wg1 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg1
[#] ip link set mtu 1420 up dev wg1
[#] ip -4 route add 10.10.10.1/32 dev wg1
[#] ip route add default dev wg1 table middle
[#] ip rule add iif wg0 lookup middle
[#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
07:49:53 ERROR

Fri Sep  3 07:50:08 +0430 2021
[#] ip route del default dev wg1 table middle
[#] ip rule del iif wg0 lookup middle
[#] ip link delete dev wg1

[#] ip link add wg1 type wireguard
[#] wg setconf wg1 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg1
[#] ip link set mtu 1420 up dev wg1
[#] ip -4 route add 10.10.10.1/32 dev wg1
[#] ip route add default dev wg1 table middle
[#] ip rule add iif wg0 lookup middle
[#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
07:50:18 ERROR

======
LOTS OF RETRY LOGS CROPPED
======

Fri Sep  3 07:55:13 +0430 2021
[#] ip route del default dev wg1 table middle
[#] ip rule del iif wg0 lookup middle
[#] ip link delete dev wg1

[#] ip link add wg1 type wireguard
[#] wg setconf wg1 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg1
[#] ip link set mtu 1420 up dev wg1
[#] ip -4 route add 10.10.10.1/32 dev wg1
[#] ip route add default dev wg1 table middle
[#] ip rule add iif wg0 lookup middle
[#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
07:55:23 ERROR

Fri Sep  3 07:55:38 +0430 2021
[#] ip route del default dev wg1 table middle
[#] ip rule del iif wg0 lookup middle
[#] ip link delete dev wg1

[#] ip link add wg1 type wireguard
[#] wg setconf wg1 /dev/fd/63
[#] ip -4 address add 10.10.10.2/32 dev wg1
[#] ip link set mtu 1420 up dev wg1
[#] ip -4 route add 10.10.10.1/32 dev wg1
[#] ip route add default dev wg1 table middle
[#] ip rule add iif wg0 lookup middle
[#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
07:55:39 OK

07:56 OK
07:57 OK
07:58 OK
07:59 OK
08:00 OK
---------------------------------------



????? ???? <?hsaber at gmail.com??> ?? ????? ??????? ? ??????? ???? ????
?:?? ????:?
>
> -Thanks for reply.
> For test reasons, I turned the firewall off on my middle-node server.
> But I can't understand how this issue may be related to firewall,
> because most of the time it works (and to me it means firewall is Ok),
> but sometime for some unknown reason it stops working, which when I
> restart the wg1 interface with this command everything comes back to
> life:
> wg-quick down wg1 && wg-quick up wg1
>
> BTW here it is the firewall status of middle-node:
> ==================
> ? firewalld.service - firewalld - dynamic firewall daemon
>    Loaded: loaded (/usr/lib/systemd/system/firewalld.service;
> disabled; vendor preset: enabled)
>    Active: inactive (dead)
>      Docs: man:firewalld(1)
> -----------------------------------
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> -----------------------------------
>
> And the firewall status of exit-node:
> ====================
> Unit firewalld.service could not be found.
> ---------------------------
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:50842
> ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> ---------------------
> Regards
>
> ??John Lauro?? <?johnalauro at gmail.com??> ?? ????? ???????? ? ???????
> ???? ???? ??:?? ????:?
> >
> > Just a guess, but I would be suspicious about connection tracking causing the issue.  What are your firewall rules?
> >
> > ?On Wed, Sep 1, 2021 at 9:51 AM ????? ?????? <hsaber at gmail.com> wrote:?
> >>
> >> Dear friends,
> >> I have configured 3 wireguard interfaces on 2 servers to act as a
> >> chained VPN for me (to bypass the internet censorship in my country),
> >> with this schema:
> >>
> >> client -- wg0 on middle-node -- wg1 on middle node -- wg2 on exit node
> >> (to free internet)
> >>
> >> Everything works fine, but after a while, the connection between wg1
> >> and wg2 drops and I can't find the reason. The connection comes back
> >> to action by simply switching the wg1 down and up again using
> >> wg-quick. And the amazing behaviour is that sometimes the connection
> >> comes back to work automatically  after some random time passes,
> >> without any actions from my side (sometimes after a few tens of
> >> minutes, sometimes after a few hours).
> >> When the wg1-wg2 connection is not working, anything else between 2
> >> servers (middle-node and exit-node) works fine. I mean I can ping the
> >> public IP of each server from another part, but the local wireguard ip
> >> of none of them are accessible.
> >>
> >> I tried to monitor the situation and read the logs but couldn't find
> >> what is happening here, so please help!
> >>
> >> The configuration:
> >> ======================
> >>
> >> client (my mobile phone):
> >> -------------------------------------------
> >> [Interface]
> >> Address = 10.10.20.2/32
> >> PrivateKey =  <private key of client>
> >> DNS = 10.10.10.1
> >>
> >> ### Middle Node
> >> [Peer]
> >> PublicKey =  <public key of wg0>
> >> PresharedKey =  <preshared key>
> >> AllowedIPs = 0.0.0.0/0
> >> Endpoint = middle-node:50842
> >> ======================
> >>
> >> wg0 (in middle-node server):
> >> -------------------------------------------
> >> [Interface]
> >> Address = 10.10.20.1/24
> >> ListenPort = 50842
> >> PrivateKey =  <private key of wg0>
> >>
> >> ### Client
> >> [Peer]
> >> PublicKey =  <public key of client>
> >> PresharedKey =  <preshared key>
> >> AllowedIPs = 10.10.20.2/32
> >> ======================
> >>
> >> wg1 (again in middle-node server):
> >> -------------------------------------------
> >> [Interface]
> >> Address = 10.10.10.2/32
> >> PrivateKey =  <private key of wg1>
> >>
> >> PostUp = ip route add default dev wg1 table middle
> >> PostUp = ip rule add iif wg0 lookup middle
> >> PostUp = wg set wg1 peer <publickey of wg2 (in exit-node)> allowed-ips 0.0.0.0/0
> >>
> >> PreDown = ip route del default dev wg1 table middle
> >> PreDown = ip rule del iif wg0 lookup middle
> >>
> >> ### Exit Node
> >> [Peer]
> >> PublicKey =  <publickey of wg2 (in exit-node)>
> >> PresharedKey =  <preshared key>
> >> AllowedIPs = 10.10.10.1/32
> >> Endpoint = exit-node:50842
> >> PersistentKeepalive = 25
> >> ======================
> >>
> >> wg2 (in exit-node server):
> >> -------------------------------------------
> >> [Interface]
> >> Address = 10.10.10.1/24
> >> ListenPort = 50842
> >> PrivateKey =  <private key of wg2>
> >>
> >> PostUp   = iptables -A FORWARD -i eth0 -o wg2 -j ACCEPT
> >> PostUp   = iptables -A FORWARD -i wg2 -j ACCEPT
> >> PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> >>
> >> PostDown = iptables -D FORWARD -i eth0 -o wg2 -j ACCEPT
> >> PostDown = iptables -D FORWARD -i wg2 -j ACCEPT
> >> PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> >>
> >> ### Middle Node
> >> [Peer]
> >> PublicKey =  <publickey of wg1 (in middle-node)>
> >> PresharedKey =  <preshared key>
> >> AllowedIPs = 10.0.0.0/8
> >> ======================
> >> ======================
> >> ======================
> >>
> >> Sample log of dmesg when the wg1-wg2 connection is not working:
> >> -------------------------------------------
> >> [Wed Sep  1 11:19:32 2021] wireguard: wg1: Sending keepalive packet to
> >> peer 12 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:19:44 2021] wireguard: wg0: Sending keepalive packet to
> >> peer 8 (~client-ip~:65323)
> >> [Wed Sep  1 11:19:44 2021] wireguard: wg1: Receiving keepalive packet
> >> from peer 12 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving handshake
> >> initiation from peer 8 (~client-ip~:65323)
> >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Sending handshake response
> >> to peer 8 (~client-ip~:65323)
> >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2867 destroyed for peer 8
> >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2871 created for peer 8
> >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving keepalive packet
> >> from peer 8 (~client-ip~:65323)
> >> [Wed Sep  1 11:21:19 2021] wireguard: wg0: Sending keepalive packet to
> >> peer 8 (~client-ip~:65323)
> >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Retrying handshake with
> >> peer 12 (~exit-node-ip~:50842) because we stopped hearing back after
> >> 15 seconds
> >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Sending handshake
> >> initiation to peer 12 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:21:30 2021] wireguard: wg1: Handshake for peer 12
> >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> >> 2)
> >> ======================
> >>
> >> Sample log of dmesg when the wg1-wg2 connection is coming back using
> >> manual restart:
> >> -------------------------------------------
> >> [Wed Sep  1 11:45:52 2021] wireguard: wg1: Sending handshake
> >> initiation to peer 12 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:45:52 2021] wireguard: wg0: Sending keepalive packet to
> >> peer 8 (~client-ip~:2335)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Handshake for peer 12
> >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> >> 3)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> >> initiation to peer 12 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2878 destroyed for peer 12
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 12
> >> (~exit-node-ip~:50842) destroyed
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface destroyed
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface created
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 13 created
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending keepalive packet to
> >> peer 13 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> >> initiation to peer 13 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Receiving handshake
> >> response from peer 13 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2881 created for peer 13
> >> [Wed Sep  1 11:46:12 2021] wireguard: wg0: Receiving keepalive packet
> >> from peer 8 (~client-ip~:2335)
> >> [Wed Sep  1 11:46:14 2021] wireguard: wg1: Receiving keepalive packet
> >> from peer 13 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:46:27 2021] wireguard: wg0: Sending keepalive packet to
> >> peer 8 (~client-ip~:2335)
> >> [Wed Sep  1 11:46:28 2021] wireguard: wg1: Receiving keepalive packet
> >> from peer 13 (~exit-node-ip~:50842)
> >> [Wed Sep  1 11:46:52 2021] wireguard: wg1: Receiving keepalive packet
> >> from peer 13 (~exit-node-ip~:50842)
> >>
> >>
> >> Thanks in advance for your kind help

From liuhangbin at gmail.com  Fri Sep  3 12:16:19 2021
From: liuhangbin at gmail.com (Hangbin Liu)
Date: Fri, 3 Sep 2021 20:16:19 +0800
Subject: [PATCH net] wireguard: remove peer cache in netns_pre_exit
In-Reply-To: <877dfzt040.fsf@toke.dk>
References: <20210901122904.9094-1-liuhangbin@gmail.com>
 <YS+GX/Y85bch4gMU@zx2c4.com> <877dfzt040.fsf@toke.dk>
Message-ID: <YTISE6AI3y3Le9ww@Laptop-X1>

On Thu, Sep 02, 2021 at 06:26:23PM +0200, Toke H?iland-J?rgensen wrote:
> Ran this through the same series of tests as the previous patch, and
> indeed it also seems to resolve the issue, so feel free to add:
> 
> Tested-by: Toke H?iland-J?rgensen <toke at redhat.com>


Thanks Toke for the testing during my PTO. I will try also do the test.
Toke has all my reproducer. So please feel free to send the patch if I
can't finish the test before next week.

Thanks
Hangbin

From toke at redhat.com  Fri Sep  3 13:10:37 2021
From: toke at redhat.com (Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?=)
Date: Fri, 03 Sep 2021 15:10:37 +0200
Subject: [PATCH net] wireguard: remove peer cache in netns_pre_exit
In-Reply-To: <YTISE6AI3y3Le9ww@Laptop-X1>
References: <20210901122904.9094-1-liuhangbin@gmail.com>
 <YS+GX/Y85bch4gMU@zx2c4.com> <877dfzt040.fsf@toke.dk>
 <YTISE6AI3y3Le9ww@Laptop-X1>
Message-ID: <8735qlst2q.fsf@toke.dk>

Hangbin Liu <liuhangbin at gmail.com> writes:

> On Thu, Sep 02, 2021 at 06:26:23PM +0200, Toke H?iland-J?rgensen wrote:
>> Ran this through the same series of tests as the previous patch, and
>> indeed it also seems to resolve the issue, so feel free to add:
>> 
>> Tested-by: Toke H?iland-J?rgensen <toke at redhat.com>
>
>
> Thanks Toke for the testing during my PTO. I will try also do the test.
> Toke has all my reproducer. So please feel free to send the patch if I
> can't finish the test before next week.

You're welcome - yeah, I ran both the scripts you provided me with, and
Jason's patch fixes the issue in both :)

-Toke


From tech at tootai.net  Fri Sep  3 13:59:32 2021
From: tech at tootai.net (Daniel)
Date: Fri, 3 Sep 2021 15:59:32 +0200
Subject: ipv6 connexion fail - ipv4 OK (SOLVED)
In-Reply-To: <20210830225927.6df90edb@natsu>
References: <ec8fe61d-06a9-9544-ab2c-3dfc26905d74@tootai.net>
 <e4b50341-6f90-92fe-7728-a518768a1b51@tootai.net>
 <20210827211412.3ed5f170@natsu>
 <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net>
 <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net>
 <20210828024454.1766744f@natsu>
 <7437f3e0-26ba-5e33-a175-0cf233635b3f@tootai.net>
 <20210830214312.6a332333@natsu>
 <e620ed11-2664-fa06-1497-a0f18facac7e@tootai.net>
 <20210830223836.5384badd@natsu>
 <e949b3e2-eab7-fc4c-2b15-8820a2c17374@tootai.net>
 <20210830225927.6df90edb@natsu>
Message-ID: <461a963d-c216-b3fc-521d-e45e89ac1191@tootai.net>

Hello

Le 30/08/2021 ? 19:59, Roman Mamedov a ?crit?:
> On Mon, 30 Aug 2021 19:44:21 +0200
> Daniel <tech at tootai.net> wrote:
>
>>> Do you get WG working at all, between some other two hosts (not involving this
>>> particular server for now)?
>> Yes. Clients are shown on both sides as connected, trafic seems to go
>> out on each side but other one as received near to nothing.
> I mean not just "shown as connected", but have you got actual traffic working
> between any two hosts. Even just forgetting this server for a while. So that
> you can rule out some general issue and concentrate on just the particular
> machine setup.

I got it.

1. you can't use ipv6 IP from the range of /64 (or other) that you 
connect to. As workaround, I build an ULA/64 network to connect both 
ends using one ipv6 from the /64 range of the server to connect
2. once the tunnel is up nothing is shown on wg show until first packet 
arrive. If you try to ping from server to client -which was my case- you 
get an error destination address has to be specified. But as soon as the 
client has send a packet (ping or keepalive), tunnel is open both ways
3. the MTU I have to use is 1436

Thanks all for your help.

-- 
Daniel

From liuhangbin at gmail.com  Sat Sep  4 08:43:09 2021
From: liuhangbin at gmail.com (Hangbin Liu)
Date: Sat, 4 Sep 2021 16:43:09 +0800
Subject: [PATCH net] wireguard: remove peer cache in netns_pre_exit
In-Reply-To: <YS+GX/Y85bch4gMU@zx2c4.com>
References: <20210901122904.9094-1-liuhangbin@gmail.com>
 <YS+GX/Y85bch4gMU@zx2c4.com>
Message-ID: <YTMxnfkJVA8b6lAV@Laptop-X1>

On Wed, Sep 01, 2021 at 03:55:43PM +0200, Jason A. Donenfeld wrote:
> Hi Hangbin,
> 
> Thanks for the patch and especially for the test. While I see that
> you've pointed to a real problem, I don't think that this particular way
> of fixing it is correct, because it will cause issues for userspace that
> expects to be able to read back the list of peers for, for example,
> keeping track of the latest endpoint addresses or rx/tx transfer
> quantities.
> 
> I think the real solution here is to simply clear the endpoint src cache
> and consequently the dst_cache. This is slightly complicated by the fact
> that dst_cache releases dsts lazily, so I needed to add a little utility
> function for that, but that was pretty easy to do.
> 
> Can you take a look at the below patch and let me know if it works for
> you and passes other testing you and Toke might be doing with it? (Also,
> please CC the wireguard mailing list in addition to netdev next time?)
> If the patch looks good to you and works well, I'll include it in the
> next series of wireguard patches I send back out to netdev. I'm back
> from travels next week and will begin working on the next series then.

Hi Jason,

I tested your patch on both physical and virtual machines. All works fine.

So please feel free to add

Tested-by: Hangbin Liu <liuhangbin at gmail.com>

Thanks
Hangbin
> 
> Regards,
> Jason
> 
> ---------8<-------------8<-----------------
> 
> From f9984a41eeaebfdcef5aba8a71966b77ba0de8c0 Mon Sep 17 00:00:00 2001
> From: "Jason A. Donenfeld" <Jason at zx2c4.com>
> Date: Wed, 1 Sep 2021 14:53:39 +0200
> Subject: [PATCH] wireguard: device: reset peer src endpoint when netns exits
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
> 
> Each peer's endpoint contains a dst_cache entry that takes a reference
> to another netdev. When the containing namespace exits, we take down the
> socket and prevent future sockets from being created (by setting
> creating_net to NULL), which removes that potential reference on the
> netns. However, it doesn't release references to the netns that a netdev
> cached in dst_cache might be taking, so the netns still might fail to
> exit. Since the socket is gimped anyway, we can simply clear all the
> dst_caches (by way of clearing the endpoint src), which will release all
> references.
> 
> However, the current dst_cache_reset function only releases those
> references lazily. But it turns out that all of our usages of
> wg_socket_clear_peer_endpoint_src are called from contexts that are not
> exactly high-speed or bottle-necked. For example, when there's
> connection difficulty, or when userspace is reconfiguring the interface.
> And in particular for this patch, when the netns is exiting. So for
> those cases, it makes more sense to call dst_release immediately. For
> that, we add a small helper function to dst_cache.
> 
> This patch also adds a test to netns.sh from Hangbin Liu to ensure this
> doesn't regress.
> 
> Test-by: Hangbin Liu <liuhangbin at gmail.com>
> Reported-by: Xiumei Mu <xmu at redhat.com>
> Cc: Hangbin Liu <liuhangbin at gmail.com>
> Cc: Toke H?iland-J?rgensen <toke at redhat.com>
> Cc: Paolo Abeni <pabeni at redhat.com>
> Fixes: 900575aa33a3 ("wireguard: device: avoid circular netns references")
> Signed-off-by: Jason A. Donenfeld <Jason at zx2c4.com>
> ---
>  drivers/net/wireguard/device.c             |  3 +++
>  drivers/net/wireguard/socket.c             |  2 +-
>  include/net/dst_cache.h                    | 11 ++++++++++
>  net/core/dst_cache.c                       | 19 +++++++++++++++++
>  tools/testing/selftests/wireguard/netns.sh | 24 +++++++++++++++++++++-
>  5 files changed, 57 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireguard/device.c b/drivers/net/wireguard/device.c
> index 551ddaaaf540..77e64ea6be67 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -398,6 +398,7 @@ static struct rtnl_link_ops link_ops __read_mostly = {
>  static void wg_netns_pre_exit(struct net *net)
>  {
>  	struct wg_device *wg;
> +	struct wg_peer *peer;
>  
>  	rtnl_lock();
>  	list_for_each_entry(wg, &device_list, device_list) {
> @@ -407,6 +408,8 @@ static void wg_netns_pre_exit(struct net *net)
>  			mutex_lock(&wg->device_update_lock);
>  			rcu_assign_pointer(wg->creating_net, NULL);
>  			wg_socket_reinit(wg, NULL, NULL);
> +			list_for_each_entry(peer, &wg->peer_list, peer_list)
> +				wg_socket_clear_peer_endpoint_src(peer);
>  			mutex_unlock(&wg->device_update_lock);
>  		}
>  	}
> diff --git a/drivers/net/wireguard/socket.c b/drivers/net/wireguard/socket.c
> index 8c496b747108..6f07b949cb81 100644
> --- a/drivers/net/wireguard/socket.c
> +++ b/drivers/net/wireguard/socket.c
> @@ -308,7 +308,7 @@ void wg_socket_clear_peer_endpoint_src(struct wg_peer *peer)
>  {
>  	write_lock_bh(&peer->endpoint_lock);
>  	memset(&peer->endpoint.src6, 0, sizeof(peer->endpoint.src6));
> -	dst_cache_reset(&peer->endpoint_cache);
> +	dst_cache_reset_now(&peer->endpoint_cache);
>  	write_unlock_bh(&peer->endpoint_lock);
>  }
>  
> diff --git a/include/net/dst_cache.h b/include/net/dst_cache.h
> index 67634675e919..df6622a5fe98 100644
> --- a/include/net/dst_cache.h
> +++ b/include/net/dst_cache.h
> @@ -79,6 +79,17 @@ static inline void dst_cache_reset(struct dst_cache *dst_cache)
>  	dst_cache->reset_ts = jiffies;
>  }
>  
> +/**
> + *	dst_cache_reset_now - invalidate the cache contents immediately
> + *	@dst_cache: the cache
> + *
> + *	The caller must be sure there are no concurrent users, as this frees
> + *	all dst_cache users immediately, rather than waiting for the next
> + *	per-cpu usage like dst_cache_reset does. Most callers should use the
> + *	higher speed lazily-freed dst_cache_reset function instead.
> + */
> +void dst_cache_reset_now(struct dst_cache *dst_cache);
> +
>  /**
>   *	dst_cache_init - initialize the cache, allocating the required storage
>   *	@dst_cache: the cache
> diff --git a/net/core/dst_cache.c b/net/core/dst_cache.c
> index be74ab4551c2..0ccfd5fa5cb9 100644
> --- a/net/core/dst_cache.c
> +++ b/net/core/dst_cache.c
> @@ -162,3 +162,22 @@ void dst_cache_destroy(struct dst_cache *dst_cache)
>  	free_percpu(dst_cache->cache);
>  }
>  EXPORT_SYMBOL_GPL(dst_cache_destroy);
> +
> +void dst_cache_reset_now(struct dst_cache *dst_cache)
> +{
> +	int i;
> +
> +	if (!dst_cache->cache)
> +		return;
> +
> +	dst_cache->reset_ts = jiffies;
> +	for_each_possible_cpu(i) {
> +		struct dst_cache_pcpu *idst = per_cpu_ptr(dst_cache->cache, i);
> +		struct dst_entry *dst = idst->dst;
> +
> +		idst->cookie = 0;
> +		idst->dst = NULL;
> +		dst_release(dst);
> +	}
> +}
> +EXPORT_SYMBOL_GPL(dst_cache_reset_now);
> diff --git a/tools/testing/selftests/wireguard/netns.sh b/tools/testing/selftests/wireguard/netns.sh
> index 2e5c1630885e..8a9461aa0878 100755
> --- a/tools/testing/selftests/wireguard/netns.sh
> +++ b/tools/testing/selftests/wireguard/netns.sh
> @@ -613,6 +613,28 @@ ip0 link set wg0 up
>  kill $ncat_pid
>  ip0 link del wg0
>  
> +# Ensure that dst_cache references don't outlive netns lifetime
> +ip1 link add dev wg0 type wireguard
> +ip2 link add dev wg0 type wireguard
> +configure_peers
> +ip1 link add veth1 type veth peer name veth2
> +ip1 link set veth2 netns $netns2
> +ip1 addr add fd00:aa::1/64 dev veth1
> +ip2 addr add fd00:aa::2/64 dev veth2
> +ip1 link set veth1 up
> +ip2 link set veth2 up
> +waitiface $netns1 veth1
> +waitiface $netns2 veth2
> +ip1 -6 route add default dev veth1 via fd00:aa::2
> +ip2 -6 route add default dev veth2 via fd00:aa::1
> +n1 wg set wg0 peer "$pub2" endpoint [fd00:aa::2]:2
> +n2 wg set wg0 peer "$pub1" endpoint [fd00:aa::1]:1
> +n1 ping6 -c 1 fd00::2
> +pp ip netns delete $netns1
> +pp ip netns delete $netns2
> +pp ip netns add $netns1
> +pp ip netns add $netns2
> +
>  # Ensure there aren't circular reference loops
>  ip1 link add wg1 type wireguard
>  ip2 link add wg2 type wireguard
> @@ -631,7 +653,7 @@ while read -t 0.1 -r line 2>/dev/null || [[ $? -ne 142 ]]; do
>  done < /dev/kmsg
>  alldeleted=1
>  for object in "${!objects[@]}"; do
> -	if [[ ${objects["$object"]} != *createddestroyed ]]; then
> +	if [[ ${objects["$object"]} != *createddestroyed && ${objects["$object"]} != *createdcreateddestroyeddestroyed ]]; then
>  		echo "Error: $object: merely ${objects["$object"]}" >&3
>  		alldeleted=0
>  	fi
> -- 
> 2.32.0

From hsaber at gmail.com  Sat Sep  4 16:55:15 2021
From: hsaber at gmail.com (=?UTF-8?B?2K3Yp9mF2K8g2LXYp9io2LE=?=)
Date: Sat, 4 Sep 2021 21:25:15 +0430
Subject: =?UTF-8?Q?Re=3A_Unexpected_experience_of_site=2Dto=2Dsite_wireguard_?=
 =?UTF-8?Q?tunneling=E2=80=8F=E2=80=8F?=
In-Reply-To: <CAECraRra33vTSb3KW_siHrQx3tLSb-boJUQ1=hVDt5Lo6xXcUw@mail.gmail.com>
References: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
 <CAECraRro-ZQrZbxBkQg=o1bnWmf1V4C65D0jkdkt2rMCCe+6bg@mail.gmail.com>
 <CADGd2Dp0S5_=bPQDnRsamvraJZ5BeVV1eWh98js3wATXodfQcQ@mail.gmail.com>
 <CAECraRpLYEkAm+g1dg6X9RJLEDx=nOs=gPQvT_CjxwjXSbhDOw@mail.gmail.com>
 <CAECraRra33vTSb3KW_siHrQx3tLSb-boJUQ1=hVDt5Lo6xXcUw@mail.gmail.com>
Message-ID: <CAECraRpgfySdLsk_HtW8NSph3B==oX_2fdbJrOnS9vn3MWokwg@mail.gmail.com>

UPDATE:
During the outage, I ran a simple test to check if both sides have
access to each other's specified UDP ports, then I found something
interesting:
Some 148 bytes length packets are transferred between parties which I
can't recognize what are them.
By the way here I copy my test results.
Anybody can spot what's going on here?
The middle-node host name which runs wg1 is ir-pp and the exit-note
(to free internet) which runs wg2 is sf-do:
(these two parts happened at the same time and are copied from 2
different servers):

========================
root at ir-pp:~# nc -u sf-do 50840
123456
1234
12
^C
root at ir-pp:~# tcpdump 'port 50841'
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:56:57.607342 IP ir-pp.50841 > sf-do.50840: UDP, length 148
20:57:01.042471 IP sf-do.43161 > ir-pp.50841: UDP, length 3
20:57:02.361827 IP ir-pp.50841 > sf-do.50840: UDP, length 148
20:57:03.635754 IP sf-do.43161 > ir-pp.50841: UDP, length 5
20:57:06.740922 IP sf-do.43161 > ir-pp.50841: UDP, length 7
20:57:07.552305 IP ir-pp.50841 > sf-do.50840: UDP, length 148
^C
6 packets captured
15 packets received by filter
0 packets dropped by kernel
root at ir-pp:~#


========================
root at sf-do:~# tcpdump 'port 50840'
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
20:56:09.126958 IP sf-do.50840 > ir-pp.50841: UDP, length 148
20:56:14.758974 IP sf-do.50840 > ir-pp.50841: UDP, length 148
20:56:18.222814 IP ir-pp.38136 > sf-do.50840: UDP, length 7
20:56:20.391041 IP sf-do.50840 > ir-pp.50841: UDP, length 148
20:56:22.307488 IP ir-pp.38136 > sf-do.50840: UDP, length 5
20:56:24.702590 IP ir-pp.38136 > sf-do.50840: UDP, length 3
20:56:25.510985 IP sf-do.50840 > ir-pp.50841: UDP, length 148
20:56:30.630917 IP sf-do.50840 > ir-pp.50841: UDP, length 148
20:56:35.750965 IP sf-do.50840 > ir-pp.50841: UDP, length 148
^C
9 packets captured
9 packets received by filter
0 packets dropped by kernel
root at sf-do:~# nc -u ir-pp 50841
12
1234
123456
^C
root at sf-do:~#

????? ???? <?hsaber at gmail.com??> ?? ????? ???? ? ??????? ???? ???? ?:?? ????:?
>
> Hi again,
> Something new happened which makes me more confused.
> I wrote a small shell-script to check the connection between wg1 and
> wg2, so whenever it drops, the script restarts the wg1 and everything
> comes back.
> Yes yes I don't like this way of addressing issues, but what could I
> do if no meaningful debug information exists, and I predict that it
> might be a bug of Wireguard itself?
> BTW this system worked fine and the anti-censorship VPN chain was up
> and running till this morning.
> The connection went down at 7:49 and didn't come back with
> auto-restart. The process of restarting continued for about 6 minutes,
> and at last at 7:55 it came back.
> During the outage I checked both sides and everything seemed fine.
> Sides could ping the public ip of each other, their wg udp ports were
> accessible to each other, and even handshake seemed to be finished
> correctly (using wg-show command) but peers couldn't ping each other.
> And the most confusing part is everything came back to life without
> any action from my side. Just after 6 minutes of continuously
> restarting the wg1 interface!
> Isn't there a bug? Somebody please help me to debug this problem and
> find the cause.
>
> Here I bring you my shell-script code, and then its related log:
>
> -------------------------
> #!/bin/bash
>
> exec >>/var/log/wg-ping 2>&1
> while true
> do
>         connection=$(ping -c 1 10.10.10.1)
>         time=$(date +%H:%M)
>         seconds=$(date +%S)
>         seconds=${seconds#0}
>         if [[ "$connection" != *"icmp"* ]]; then
>           echo " "
>           date
>           wg-quick down wg1
>           echo " "
>           wg-quick up wg1
>           connection=$(ping -c 1 10.10.10.1)
>           time=$(date +%T)
>           if [[ "$connection" != *"icmp"* ]]; then
>             echo "$time ERROR"
>           else
>             echo "$time OK"
>             echo " "
>           fi
>         elif [[ $seconds -lt 5  ]]; then
>           echo "$time OK"
>         fi
>         sleep 5
> done
> ===============
> Sample log of simply restarting the wg1 which makes everything fine
> (and happens every few hours):
> -----------------------
> 01:17 OK
> 01:18 OK
> 01:19 OK
> 01:20 OK
> 01:21 OK
> 01:22 OK
> 01:23 OK
> 01:24 OK
> 01:25 OK
> 01:26 OK
>
> Fri Sep  3 01:26:41 +0430 2021
> [#] ip route del default dev wg1 table middle
> [#] ip rule del iif wg0 lookup middle
> [#] ip link delete dev wg1
>
> [#] ip link add wg1 type wireguard
> [#] wg setconf wg1 /dev/fd/63
> [#] ip -4 address add 10.10.10.2/32 dev wg1
> [#] ip link set mtu 1420 up dev wg1
> [#] ip -4 route add 10.10.10.1/32 dev wg1
> [#] ip route add default dev wg1 table middle
> [#] ip rule add iif wg0 lookup middle
> [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> 01:26:42 OK
>
> 01:27 OK
> 01:28 OK
> 01:30 OK
> 01:31 OK
> 01:32 OK
> 01:33 OK
> 01:34 OK
> =====================================================
> And the log for the confusing situation I explained:
> -----------------------
> 07:45 OK
> 07:46 OK
> 07:47 OK
> 07:48 OK
> 07:49 OK
>
> Fri Sep  3 07:49:42 +0430 2021
> [#] ip route del default dev wg1 table middle
> [#] ip rule del iif wg0 lookup middle
> [#] ip link delete dev wg1
>
> [#] ip link add wg1 type wireguard
> [#] wg setconf wg1 /dev/fd/63
> [#] ip -4 address add 10.10.10.2/32 dev wg1
> [#] ip link set mtu 1420 up dev wg1
> [#] ip -4 route add 10.10.10.1/32 dev wg1
> [#] ip route add default dev wg1 table middle
> [#] ip rule add iif wg0 lookup middle
> [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> 07:49:53 ERROR
>
> Fri Sep  3 07:50:08 +0430 2021
> [#] ip route del default dev wg1 table middle
> [#] ip rule del iif wg0 lookup middle
> [#] ip link delete dev wg1
>
> [#] ip link add wg1 type wireguard
> [#] wg setconf wg1 /dev/fd/63
> [#] ip -4 address add 10.10.10.2/32 dev wg1
> [#] ip link set mtu 1420 up dev wg1
> [#] ip -4 route add 10.10.10.1/32 dev wg1
> [#] ip route add default dev wg1 table middle
> [#] ip rule add iif wg0 lookup middle
> [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> 07:50:18 ERROR
>
> ======
> LOTS OF RETRY LOGS CROPPED
> ======
>
> Fri Sep  3 07:55:13 +0430 2021
> [#] ip route del default dev wg1 table middle
> [#] ip rule del iif wg0 lookup middle
> [#] ip link delete dev wg1
>
> [#] ip link add wg1 type wireguard
> [#] wg setconf wg1 /dev/fd/63
> [#] ip -4 address add 10.10.10.2/32 dev wg1
> [#] ip link set mtu 1420 up dev wg1
> [#] ip -4 route add 10.10.10.1/32 dev wg1
> [#] ip route add default dev wg1 table middle
> [#] ip rule add iif wg0 lookup middle
> [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> 07:55:23 ERROR
>
> Fri Sep  3 07:55:38 +0430 2021
> [#] ip route del default dev wg1 table middle
> [#] ip rule del iif wg0 lookup middle
> [#] ip link delete dev wg1
>
> [#] ip link add wg1 type wireguard
> [#] wg setconf wg1 /dev/fd/63
> [#] ip -4 address add 10.10.10.2/32 dev wg1
> [#] ip link set mtu 1420 up dev wg1
> [#] ip -4 route add 10.10.10.1/32 dev wg1
> [#] ip route add default dev wg1 table middle
> [#] ip rule add iif wg0 lookup middle
> [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> 07:55:39 OK
>
> 07:56 OK
> 07:57 OK
> 07:58 OK
> 07:59 OK
> 08:00 OK
> ---------------------------------------
>
>
>
> ????? ???? <?hsaber at gmail.com??> ?? ????? ??????? ? ??????? ???? ????
> ?:?? ????:?
> >
> > -Thanks for reply.
> > For test reasons, I turned the firewall off on my middle-node server.
> > But I can't understand how this issue may be related to firewall,
> > because most of the time it works (and to me it means firewall is Ok),
> > but sometime for some unknown reason it stops working, which when I
> > restart the wg1 interface with this command everything comes back to
> > life:
> > wg-quick down wg1 && wg-quick up wg1
> >
> > BTW here it is the firewall status of middle-node:
> > ==================
> > ? firewalld.service - firewalld - dynamic firewall daemon
> >    Loaded: loaded (/usr/lib/systemd/system/firewalld.service;
> > disabled; vendor preset: enabled)
> >    Active: inactive (dead)
> >      Docs: man:firewalld(1)
> > -----------------------------------
> > Chain INPUT (policy ACCEPT)
> > target     prot opt source               destination
> >
> > Chain FORWARD (policy ACCEPT)
> > target     prot opt source               destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target     prot opt source               destination
> > -----------------------------------
> >
> > And the firewall status of exit-node:
> > ====================
> > Unit firewalld.service could not be found.
> > ---------------------------
> > Chain INPUT (policy ACCEPT)
> > target     prot opt source               destination
> > ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:50842
> > ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
> >
> > Chain FORWARD (policy ACCEPT)
> > target     prot opt source               destination
> > ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> > ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> >
> > Chain OUTPUT (policy ACCEPT)
> > target     prot opt source               destination
> > ---------------------
> > Regards
> >
> > ??John Lauro?? <?johnalauro at gmail.com??> ?? ????? ???????? ? ???????
> > ???? ???? ??:?? ????:?
> > >
> > > Just a guess, but I would be suspicious about connection tracking causing the issue.  What are your firewall rules?
> > >
> > > ?On Wed, Sep 1, 2021 at 9:51 AM ????? ?????? <hsaber at gmail.com> wrote:?
> > >>
> > >> Dear friends,
> > >> I have configured 3 wireguard interfaces on 2 servers to act as a
> > >> chained VPN for me (to bypass the internet censorship in my country),
> > >> with this schema:
> > >>
> > >> client -- wg0 on middle-node -- wg1 on middle node -- wg2 on exit node
> > >> (to free internet)
> > >>
> > >> Everything works fine, but after a while, the connection between wg1
> > >> and wg2 drops and I can't find the reason. The connection comes back
> > >> to action by simply switching the wg1 down and up again using
> > >> wg-quick. And the amazing behaviour is that sometimes the connection
> > >> comes back to work automatically  after some random time passes,
> > >> without any actions from my side (sometimes after a few tens of
> > >> minutes, sometimes after a few hours).
> > >> When the wg1-wg2 connection is not working, anything else between 2
> > >> servers (middle-node and exit-node) works fine. I mean I can ping the
> > >> public IP of each server from another part, but the local wireguard ip
> > >> of none of them are accessible.
> > >>
> > >> I tried to monitor the situation and read the logs but couldn't find
> > >> what is happening here, so please help!
> > >>
> > >> The configuration:
> > >> ======================
> > >>
> > >> client (my mobile phone):
> > >> -------------------------------------------
> > >> [Interface]
> > >> Address = 10.10.20.2/32
> > >> PrivateKey =  <private key of client>
> > >> DNS = 10.10.10.1
> > >>
> > >> ### Middle Node
> > >> [Peer]
> > >> PublicKey =  <public key of wg0>
> > >> PresharedKey =  <preshared key>
> > >> AllowedIPs = 0.0.0.0/0
> > >> Endpoint = middle-node:50842
> > >> ======================
> > >>
> > >> wg0 (in middle-node server):
> > >> -------------------------------------------
> > >> [Interface]
> > >> Address = 10.10.20.1/24
> > >> ListenPort = 50842
> > >> PrivateKey =  <private key of wg0>
> > >>
> > >> ### Client
> > >> [Peer]
> > >> PublicKey =  <public key of client>
> > >> PresharedKey =  <preshared key>
> > >> AllowedIPs = 10.10.20.2/32
> > >> ======================
> > >>
> > >> wg1 (again in middle-node server):
> > >> -------------------------------------------
> > >> [Interface]
> > >> Address = 10.10.10.2/32
> > >> PrivateKey =  <private key of wg1>
> > >>
> > >> PostUp = ip route add default dev wg1 table middle
> > >> PostUp = ip rule add iif wg0 lookup middle
> > >> PostUp = wg set wg1 peer <publickey of wg2 (in exit-node)> allowed-ips 0.0.0.0/0
> > >>
> > >> PreDown = ip route del default dev wg1 table middle
> > >> PreDown = ip rule del iif wg0 lookup middle
> > >>
> > >> ### Exit Node
> > >> [Peer]
> > >> PublicKey =  <publickey of wg2 (in exit-node)>
> > >> PresharedKey =  <preshared key>
> > >> AllowedIPs = 10.10.10.1/32
> > >> Endpoint = exit-node:50842
> > >> PersistentKeepalive = 25
> > >> ======================
> > >>
> > >> wg2 (in exit-node server):
> > >> -------------------------------------------
> > >> [Interface]
> > >> Address = 10.10.10.1/24
> > >> ListenPort = 50842
> > >> PrivateKey =  <private key of wg2>
> > >>
> > >> PostUp   = iptables -A FORWARD -i eth0 -o wg2 -j ACCEPT
> > >> PostUp   = iptables -A FORWARD -i wg2 -j ACCEPT
> > >> PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > >>
> > >> PostDown = iptables -D FORWARD -i eth0 -o wg2 -j ACCEPT
> > >> PostDown = iptables -D FORWARD -i wg2 -j ACCEPT
> > >> PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> > >>
> > >> ### Middle Node
> > >> [Peer]
> > >> PublicKey =  <publickey of wg1 (in middle-node)>
> > >> PresharedKey =  <preshared key>
> > >> AllowedIPs = 10.0.0.0/8
> > >> ======================
> > >> ======================
> > >> ======================
> > >>
> > >> Sample log of dmesg when the wg1-wg2 connection is not working:
> > >> -------------------------------------------
> > >> [Wed Sep  1 11:19:32 2021] wireguard: wg1: Sending keepalive packet to
> > >> peer 12 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:19:44 2021] wireguard: wg0: Sending keepalive packet to
> > >> peer 8 (~client-ip~:65323)
> > >> [Wed Sep  1 11:19:44 2021] wireguard: wg1: Receiving keepalive packet
> > >> from peer 12 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving handshake
> > >> initiation from peer 8 (~client-ip~:65323)
> > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Sending handshake response
> > >> to peer 8 (~client-ip~:65323)
> > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2867 destroyed for peer 8
> > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2871 created for peer 8
> > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving keepalive packet
> > >> from peer 8 (~client-ip~:65323)
> > >> [Wed Sep  1 11:21:19 2021] wireguard: wg0: Sending keepalive packet to
> > >> peer 8 (~client-ip~:65323)
> > >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Retrying handshake with
> > >> peer 12 (~exit-node-ip~:50842) because we stopped hearing back after
> > >> 15 seconds
> > >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Sending handshake
> > >> initiation to peer 12 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:21:30 2021] wireguard: wg1: Handshake for peer 12
> > >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> > >> 2)
> > >> ======================
> > >>
> > >> Sample log of dmesg when the wg1-wg2 connection is coming back using
> > >> manual restart:
> > >> -------------------------------------------
> > >> [Wed Sep  1 11:45:52 2021] wireguard: wg1: Sending handshake
> > >> initiation to peer 12 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:45:52 2021] wireguard: wg0: Sending keepalive packet to
> > >> peer 8 (~client-ip~:2335)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Handshake for peer 12
> > >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> > >> 3)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> > >> initiation to peer 12 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2878 destroyed for peer 12
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 12
> > >> (~exit-node-ip~:50842) destroyed
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface destroyed
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface created
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 13 created
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending keepalive packet to
> > >> peer 13 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> > >> initiation to peer 13 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Receiving handshake
> > >> response from peer 13 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2881 created for peer 13
> > >> [Wed Sep  1 11:46:12 2021] wireguard: wg0: Receiving keepalive packet
> > >> from peer 8 (~client-ip~:2335)
> > >> [Wed Sep  1 11:46:14 2021] wireguard: wg1: Receiving keepalive packet
> > >> from peer 13 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:46:27 2021] wireguard: wg0: Sending keepalive packet to
> > >> peer 8 (~client-ip~:2335)
> > >> [Wed Sep  1 11:46:28 2021] wireguard: wg1: Receiving keepalive packet
> > >> from peer 13 (~exit-node-ip~:50842)
> > >> [Wed Sep  1 11:46:52 2021] wireguard: wg1: Receiving keepalive packet
> > >> from peer 13 (~exit-node-ip~:50842)
> > >>
> > >>
> > >> Thanks in advance for your kind help

From vojtech.kane at gmail.com  Fri Sep  3 07:24:38 2021
From: vojtech.kane at gmail.com (=?UTF-8?B?Vm9qdMSbY2ggS8OhbsSb?=)
Date: Fri, 3 Sep 2021 09:24:38 +0200
Subject: Strange behavior when a peer has the same key as the interface
Message-ID: <c538301f-980c-99c9-4857-65867127aba3@gmail.com>

Hello,

I would like to report a strange behavior of the Wireguard Linux kernel 
implementation ? when you try to create a peer whose public key matches 
the public key of the interface, the call returns success, but nothing 
is done.


I don't have an opinion (and relevant deep understanding of the crypto 
involved) whether such a call should succeed or not. Especially since 
it's 99% not what you want. I came across this issue by mistake anyway. 
However I think an error should be returned when such a peer is rejected.


Steps to reproduce:

`wg genkey > priv`

`wg pubkey > pub < priv`

`ip link add wg type wireguard`

`wg set wg private-key priv`

`wg set wg peer $(cat pub) allowed-ips 1.1.1.1/32`

Observe:

The return code is 0.

`wg show wg` does not print any peer.


The same happens when using the wgctrl golang library.


Regards,

Vojt?ch K?n?


From wade at wades.im  Fri Sep  3 14:57:36 2021
From: wade at wades.im (Wade Simmons)
Date: Fri, 3 Sep 2021 10:57:36 -0400
Subject: Invoking sendmmsg from Go.
In-Reply-To: <03143d09-112a-d28c-f79e-d97c01f7b1d2@sys.casa>
References: <03143d09-112a-d28c-f79e-d97c01f7b1d2@sys.casa>
Message-ID: <CAF63tRoz2pRTJe=sJoiZNPW-gqajQObqc2m0HDvwUfBw0v2TAA@mail.gmail.com>

On Wed, Sep 1, 2021 at 9:59 AM john at sys.casa <john at sys.casa> wrote:
> Given that, I was wondering if anybody knows a way to interface with
> sendmmsg from Go?

As an example, the golang.org/x/net/ipv4 package implements WriteBatch
using sendmmsg:

- https://pkg.go.dev/golang.org/x/net/ipv4#PacketConn.WriteBatch

You can either use that method, or peek at the source code to see how
the syscall is called.

-- 
Wade Simmons

From davidventura27 at gmail.com  Fri Sep  3 16:41:12 2021
From: davidventura27 at gmail.com (David Ventura)
Date: Fri, 3 Sep 2021 18:41:12 +0200
Subject: Wireguard-go behavior on network-interface change
Message-ID: <CA+UPfZ7bqKdff147=trSRWGGhbCg8VP2WHePWFT8JYZD3YarHg@mail.gmail.com>

Hi
I am running wireguard-go on linux (as a fallback for no kernel
modules available on some devices, that is being worked on in
parallel) and hitting an unexpected issue:

When a mobile device changes network, the interfaces (or an unknown,
to me, part of the network stack) are temporarily unavailable.
Depending on the timing of these changes, sometimes wireguard-go will
shut down and sometimes it will time-out for up to 15 seconds and
recover:

Recovery-1:
DEBUG: (wg0) 2021/09/03 18:13:35 peer(B3D6?YQVk) - Sending keepalive packet
ERROR: (wg0) 2021/09/03 18:13:35 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
DEBUG: (wg0) 2021/09/03 18:13:41 peer(B3D6?YQVk) - Received handshake initiation

Recovery-2:
DEBUG: (wg0) 2021/09/03 18:13:57 peer(B3D6?YQVk) - Sending keepalive packet
ERROR: (wg0) 2021/09/03 18:14:11 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:12 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:13 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:14 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:15 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:16 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:17 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
ERROR: (wg0) 2021/09/03 18:14:18 peer(B3D6?YQVk) - Failed to send data
packet network is unreachable
DEBUG: (wg0) 2021/09/03 18:14:31 peer(B3D6?YQVk) - Sending keepalive packet
DEBUG: (wg0) 2021/09/03 18:15:41 peer(B3D6?YQVk) - Received handshake initiation

Recovery-3:
DEBUG: (wg0) 2021/09/03 18:16:06 peer(B3D6?YQVk) - Sending keepalive packet
DEBUG: (wg0) 2021/09/03 18:16:24 peer(B3D6?YQVk) - Retrying handshake
because we stopped hearing back after 15 seconds
DEBUG: (wg0) 2021/09/03 18:16:24 peer(B3D6?YQVk) - Sending handshake initiation


These cases are fine with me, however, sometimes this happens:

ERROR: (wg0) 2021/09/03 18:16:38 Failed to read packet from TUN
device: netlink socket closed: resource temporarily unavailable

After which `device.Close()` is called and the program exits.

Is it possible to change this behavior?

I don't know much about wg internals _or_ golang, so I tried this silly patch:

diff --git a/device/send.go b/device/send.go
index c4aa5b9..b02814f 100644
--- a/device/send.go
+++ b/device/send.go
@@ -272,7 +272,9 @@ func (device *Device) RoutineReadFromTUN() {
                if err != nil {
                        if !device.isClosed.Get() {
                                logError.Println("Failed to read
packet from TUN device:", err)
-                               device.Close()
+                               device.PutMessageBuffer(elem.buffer)
+                               device.PutOutboundElement(elem)
+                               continue
                        }

which, as you could expect, did not work. It does leave wireguard
running and the interface is still there, but the communication is
broken.

David


-- 
Stack is the new term for "I have no idea what I'm actually using".

From vkhatte at gmail.com  Fri Sep  3 23:07:52 2021
From: vkhatte at gmail.com (Veerabhushan Hatte)
Date: Fri, 3 Sep 2021 16:07:52 -0700
Subject: Unable to load wintun library for Windows
Message-ID: <CAC6DygdBVsk2Sa3LFLLs5WdOUUOi1Vs0+v6gXV7d+h-noy8v1A@mail.gmail.com>

Hi All,

We are trying to use wintun DLL to create SSL tunnel. I copied
wintun.dll into c:\Windows\system32\ and tried the example provided to
load the library (LoadLibraryExW(wintun.dll,...)). I am unable to load
library and I am getting error 126 for LoadLibraryEXW.

How do I solve this issue?

Thanks,
Veera

From luca at z3ntu.xyz  Sat Sep  4 11:46:54 2021
From: luca at z3ntu.xyz (Luca Weiss)
Date: Sat, 04 Sep 2021 13:46:54 +0200
Subject: build.wireguard.com down
Message-ID: <1126168D-D01E-48E8-B3F4-308F16666C61@z3ntu.xyz>

Hey all,

It seems that build.wireguard.com is down which is hosting the distros.txt used by the android_kernel_wireguard script and also used by the main homepage (distros.json there).

Regards
Luca

From Jason at zx2c4.com  Sun Sep  5 12:23:32 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Sep 2021 14:23:32 +0200
Subject: build.wireguard.com down
In-Reply-To: <1126168D-D01E-48E8-B3F4-308F16666C61@z3ntu.xyz>
References: <1126168D-D01E-48E8-B3F4-308F16666C61@z3ntu.xyz>
Message-ID: <CAHmME9o3p-z+geceaHybP_RjUmotwddLCV5RQhdxTZBGf1fyiA@mail.gmail.com>

Sorry for that.

We're all set now, though I don't yet understand root cause.
Apparently it shutdown on Sept 2 and returned with different NICs (I
think?), which had a different stable identifier and so an IP address
wasn't configured on them. Going to begin analyzing the situation now
that connectivity is restored.

Jason

From Jason at zx2c4.com  Sun Sep  5 13:22:36 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Sep 2021 15:22:36 +0200
Subject: Unable to load wintun library for Windows
In-Reply-To: <CAC6DygdBVsk2Sa3LFLLs5WdOUUOi1Vs0+v6gXV7d+h-noy8v1A@mail.gmail.com>
References: <CAC6DygdBVsk2Sa3LFLLs5WdOUUOi1Vs0+v6gXV7d+h-noy8v1A@mail.gmail.com>
Message-ID: <CAHmME9qH9T3O04YG+DMdq79BgkUBxSTzHfgfL5m0CaymvGJ3LQ@mail.gmail.com>

Copy it to "C:\Program Files\Something" and execute your exe from
there too. Never copy files into C:\windows\system32.

From Jason at zx2c4.com  Sun Sep  5 13:24:47 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Sep 2021 15:24:47 +0200
Subject: Strange behavior when a peer has the same key as the interface
In-Reply-To: <c538301f-980c-99c9-4857-65867127aba3@gmail.com>
References: <c538301f-980c-99c9-4857-65867127aba3@gmail.com>
Message-ID: <CAHmME9p0hTuYXar6LN2GyjF64k62z9vcokOE6La6eW-H06NVow@mail.gmail.com>

This is by design across all implementations, so that multiple peers
can share the same stanzas after the [Interface] section. We don't
allow peers talking to themselves simply because it made the formal
analysis of the crypto slightly more complicated.

From vojtech.kane at gmail.com  Sun Sep  5 20:27:25 2021
From: vojtech.kane at gmail.com (=?UTF-8?B?Vm9qdMSbY2ggS8OhbsSb?=)
Date: Sun, 5 Sep 2021 22:27:25 +0200
Subject: Strange behavior when a peer has the same key as the interface
In-Reply-To: <CAHmME9p0hTuYXar6LN2GyjF64k62z9vcokOE6La6eW-H06NVow@mail.gmail.com>
References: <c538301f-980c-99c9-4857-65867127aba3@gmail.com>
 <CAHmME9p0hTuYXar6LN2GyjF64k62z9vcokOE6La6eW-H06NVow@mail.gmail.com>
Message-ID: <57e7c370-026a-1456-496f-cf069d392772@gmail.com>

> This is by design across all implementations, so that multiple peers can share the same stanzas after the [Interface] section.
Does that mean it's unfixable in the meaning you cannot detect it and 
return appropriate error?


While being clearly my mistake, it took me multiple hours to understand 
the problem instead of simply getting `cannot set peer foo as it already 
is a public key of interface bar`.


From Jason at zx2c4.com  Sun Sep  5 20:54:11 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 5 Sep 2021 22:54:11 +0200
Subject: Strange behavior when a peer has the same key as the interface
In-Reply-To: <57e7c370-026a-1456-496f-cf069d392772@gmail.com>
References: <c538301f-980c-99c9-4857-65867127aba3@gmail.com>
 <CAHmME9p0hTuYXar6LN2GyjF64k62z9vcokOE6La6eW-H06NVow@mail.gmail.com>
 <57e7c370-026a-1456-496f-cf069d392772@gmail.com>
Message-ID: <CAHmME9q=XVvkj8dPGKdzEFSXg2thisDMkUWqXHGtAfmW2==ZRA@mail.gmail.com>

On Sun, Sep 5, 2021 at 10:27 PM Vojt?ch K?n? <vojtech.kane at gmail.com> wrote:
>
> > This is by design across all implementations, so that multiple peers can share the same stanzas after the [Interface] section.
> Does that mean it's unfixable in the meaning you cannot detect it and
> return appropriate error?
>
>
> While being clearly my mistake, it took me multiple hours to understand
> the problem instead of simply getting `cannot set peer foo as it already
> is a public key of interface bar`.
>

It sounds like we really need to document that in more obvious places,
like wg(8), as that kind of confusion indeed must have been really
frustrating.

Jason

From h.shirosaki at gmail.com  Mon Sep  6 11:49:37 2021
From: h.shirosaki at gmail.com (Hiroshi Shirosaki)
Date: Mon, 6 Sep 2021 20:49:37 +0900
Subject: Wireguard Windows tunnel editing does not draw correctly with
 vertical scroll down
Message-ID: <CAOWZXk1LsG_kr3JD8kTkY1U1pp4uq5Vc3DR29hX_Af+XD=QDBA@mail.gmail.com>

Hi,

When I edit my tunnel setting that has multiple peers and input keys
with vertical scroll down,
the inputted characters are not shown correctly.
It looks like the old contents remain.

Without vertical scroll down the inputted characters are shown correctly.

It seems EM_SETCHARFORMAT and RedrawWindow don't play nicely together.

I use Wireguard-windows amd64 0.4.5.

I've found that adding window hide/show around EM_SETCHARFORMAT seems
to fix the redraw issue.
Here is a patch.

diff --git a/ui/syntax/syntaxedit.go b/ui/syntax/syntaxedit.go
index 42f6e7b7..7b88271a 100644
--- a/ui/syntax/syntaxedit.go
+++ b/ui/syntax/syntaxedit.go
@@ -247,6 +247,8 @@ func (se *SyntaxEdit) highlightText() error {
  win.SendMessage(hWnd, win.EM_SETBKGNDCOLOR, 0, uintptr(bgColor))
  numSpans := len(spans)
  foundPrivateKey := false
+ // Workaround to redraw correctly with vertical scroll down
+ win.ShowWindow(hWnd, win.SW_HIDE)
  for i := range spans {
  span := &spans[i]
  if numSpans <= 2048 {
@@ -262,6 +264,7 @@ func (se *SyntaxEdit) highlightText() error {
  foundPrivateKey = true
  }
  }
+ win.ShowWindow(hWnd, win.SW_SHOW)
  win.SendMessage(hWnd, win.EM_SETSCROLLPOS, 0,
uintptr(unsafe.Pointer(&origScroll)))
  win.SendMessage(hWnd, win.EM_EXSETSEL, 0,
uintptr(unsafe.Pointer(&origSelection)))
  win.SendMessage(hWnd, win.EM_HIDESELECTION, win.FALSE, 0)

-- 
Hiroshi Shirosaki

From tech at tootai.net  Mon Sep  6 15:51:08 2021
From: tech at tootai.net (Daniel)
Date: Mon, 6 Sep 2021 17:51:08 +0200
Subject: WG ipv6tunnel - ipv4 and ipv6 issues
Message-ID: <e490b0c3-ef5f-2725-e1a5-5cdc1b10da2e@tootai.net>

Hi list,

I setup a wg connection using only ipv6 addresses for wg IFACE. One end 
is fd99:1234:beef:cafe::10:1/64 -named S1- other one being 
fd99:1234:beef:cafe::70:1/64 -named S2- Each end can ping or ssh to the 
other one.

1. I would like to pass ipv4 traffic inside so I add on S1

sudo ip r add 10.0.70.0/24 via inet6 fd99:1234:beef:cafe::70:1 dev wig0

Destination server has a virbr0 bridge (kvm libvirt) with 2 addresses: 
10.0.70.1/32 and fd99:1234:beef:cafe::70:ff1/120

 From S1 I can ping or ssh the ipv6 address from virbr0 but get no 
answer when pinging or ssh the ipv4 address despite the fact that 
wig0 at S2 get's the original traffic (tcpdump -ni wig0)

2. VMs from server S2 have ipv6 addresses like 
fd99:1234:beef:cafe::70:ff1[2-9]/120 They can ping S2 and virbr0 ipv6 
addresses but are not reachable from S1 nor they can ping ipv6 endpoints 
behind S1 (network fd53:9b48:337:8b38::/64) despite the fact that route 
exist

fd53:9b48:337:8b38::/64 via fd99:1234:beef:cafe::10:1 dev wig0 metric 
1024 pref medium

and there is no problem from S2. From iptables vue wig0 is accepted in 
INPUT, FORWARD and OUTPUT on S2. Both servers are running Debian11 with 
5.10 kernel.

What am I missing here ?


-- 
Daniel

From vkhatte at gmail.com  Tue Sep  7 16:50:07 2021
From: vkhatte at gmail.com (Veerabhushan Hatte)
Date: Tue, 7 Sep 2021 09:50:07 -0700
Subject: Unable to load wintun library for Windows
In-Reply-To: <CAHmME9qH9T3O04YG+DMdq79BgkUBxSTzHfgfL5m0CaymvGJ3LQ@mail.gmail.com>
References: <CAC6DygdBVsk2Sa3LFLLs5WdOUUOi1Vs0+v6gXV7d+h-noy8v1A@mail.gmail.com>
 <CAHmME9qH9T3O04YG+DMdq79BgkUBxSTzHfgfL5m0CaymvGJ3LQ@mail.gmail.com>
Message-ID: <CAC6DygcvH2HB+2PjipYkDTsQ=G+FahHnYTSkzvW+T72MiYcuDw@mail.gmail.com>

Hi Jason,

Thanks for the help. I copied wintun.dll into same directory where exe
file is located and library loaded library successfully.

Thanks,
Veera

On Sun, Sep 5, 2021 at 6:22 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Copy it to "C:\Program Files\Something" and execute your exe from
> there too. Never copy files into C:\windows\system32.

From alex at giurgiu.io  Tue Sep  7 11:35:10 2021
From: alex at giurgiu.io (Alex Giurgiu)
Date: Tue, 7 Sep 2021 14:35:10 +0300
Subject: architectural question regarding the use of wireguard
Message-ID: <55393D98-0B32-4F8F-948A-C7AA1B5BF096@giurgiu.io>

Dear wg list,

First of all, thank you for this wonderful piece of software!

I am working on a software project which manages Linux containers on one or multiple machines, and I would like to implement a networking model where a Wireguard interface is created for every application that runs on this platform. Each application will be identified by a wg key + an IPv6 address deterministically derived from that key (similarly to what yggdrasil does).

Do you think this approach makes sense and will it scale from wg's point of view for situations where there are thousands of applications and hundreds of users each having one or two devices, with a complex matrix of permissions between the users and the applications? The key mapping and synchronisation between users and apps seems straightforward to me but I can't figure out if using wg for this scenario makes sense.

Thanks!

Alex

From someguy at effective-light.com  Wed Sep  8 10:27:24 2021
From: someguy at effective-light.com (Hamza Mahfooz)
Date: Wed, 08 Sep 2021 06:27:24 -0400
Subject: [PATCH] wireguard: convert index_hashtable and pubkey_hashtable
 into rhashtables
In-Reply-To: <20210806044315.169657-1-someguy@effective-light.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
Message-ID: <OD24ZQ.IQOQXX8U0YST@effective-light.com>

ping

On Fri, Aug 6 2021 at 12:43:14 AM -0400, Hamza Mahfooz 
<someguy at effective-light.com> wrote:
> It is made mention of in commit e7096c131e516 ("net: WireGuard secure
> network tunnel"), that it is desirable to move away from the 
> statically
> sized hash-table implementation.
> 
> Signed-off-by: Hamza Mahfooz <someguy at effective-light.com>
> ---
>  drivers/net/wireguard/device.c     |   4 +
>  drivers/net/wireguard/device.h     |   2 +-
>  drivers/net/wireguard/noise.c      |   1 +
>  drivers/net/wireguard/noise.h      |   1 +
>  drivers/net/wireguard/peer.h       |   2 +-
>  drivers/net/wireguard/peerlookup.c | 190 
> ++++++++++++++---------------
>  drivers/net/wireguard/peerlookup.h |  27 ++--
>  7 files changed, 112 insertions(+), 115 deletions(-)
> 
> diff --git a/drivers/net/wireguard/device.c 
> b/drivers/net/wireguard/device.c
> index 551ddaaaf540..3bd43c9481ef 100644
> --- a/drivers/net/wireguard/device.c
> +++ b/drivers/net/wireguard/device.c
> @@ -243,7 +243,9 @@ static void wg_destruct(struct net_device *dev)
>  	skb_queue_purge(&wg->incoming_handshakes);
>  	free_percpu(dev->tstats);
>  	free_percpu(wg->incoming_handshakes_worker);
> +	wg_index_hashtable_destroy(wg->index_hashtable);
>  	kvfree(wg->index_hashtable);
> +	wg_pubkey_hashtable_destroy(wg->peer_hashtable);
>  	kvfree(wg->peer_hashtable);
>  	mutex_unlock(&wg->device_update_lock);
> 
> @@ -382,8 +384,10 @@ static int wg_newlink(struct net *src_net, 
> struct net_device *dev,
>  err_free_tstats:
>  	free_percpu(dev->tstats);
>  err_free_index_hashtable:
> +	wg_index_hashtable_destroy(wg->index_hashtable);
>  	kvfree(wg->index_hashtable);
>  err_free_peer_hashtable:
> +	wg_pubkey_hashtable_destroy(wg->peer_hashtable);
>  	kvfree(wg->peer_hashtable);
>  	return ret;
>  }
> diff --git a/drivers/net/wireguard/device.h 
> b/drivers/net/wireguard/device.h
> index 854bc3d97150..24980eb766af 100644
> --- a/drivers/net/wireguard/device.h
> +++ b/drivers/net/wireguard/device.h
> @@ -50,7 +50,7 @@ struct wg_device {
>  	struct multicore_worker __percpu *incoming_handshakes_worker;
>  	struct cookie_checker cookie_checker;
>  	struct pubkey_hashtable *peer_hashtable;
> -	struct index_hashtable *index_hashtable;
> +	struct rhashtable *index_hashtable;
>  	struct allowedips peer_allowedips;
>  	struct mutex device_update_lock, socket_update_lock;
>  	struct list_head device_list, peer_list;
> diff --git a/drivers/net/wireguard/noise.c 
> b/drivers/net/wireguard/noise.c
> index c0cfd9b36c0b..d42a0ff2be5d 100644
> --- a/drivers/net/wireguard/noise.c
> +++ b/drivers/net/wireguard/noise.c
> @@ -797,6 +797,7 @@ bool wg_noise_handshake_begin_session(struct 
> noise_handshake *handshake,
>  	new_keypair->i_am_the_initiator = handshake->state ==
>  					  HANDSHAKE_CONSUMED_RESPONSE;
>  	new_keypair->remote_index = handshake->remote_index;
> +	new_keypair->entry.index = handshake->entry.index;
> 
>  	if (new_keypair->i_am_the_initiator)
>  		derive_keys(&new_keypair->sending, &new_keypair->receiving,
> diff --git a/drivers/net/wireguard/noise.h 
> b/drivers/net/wireguard/noise.h
> index c527253dba80..ea705747e4e4 100644
> --- a/drivers/net/wireguard/noise.h
> +++ b/drivers/net/wireguard/noise.h
> @@ -72,6 +72,7 @@ struct noise_handshake {
> 
>  	u8 ephemeral_private[NOISE_PUBLIC_KEY_LEN];
>  	u8 remote_static[NOISE_PUBLIC_KEY_LEN];
> +	siphash_key_t skey;
>  	u8 remote_ephemeral[NOISE_PUBLIC_KEY_LEN];
>  	u8 precomputed_static_static[NOISE_PUBLIC_KEY_LEN];
> 
> diff --git a/drivers/net/wireguard/peer.h 
> b/drivers/net/wireguard/peer.h
> index 76e4d3128ad4..d5403fb7a6a0 100644
> --- a/drivers/net/wireguard/peer.h
> +++ b/drivers/net/wireguard/peer.h
> @@ -48,7 +48,7 @@ struct wg_peer {
>  	atomic64_t last_sent_handshake;
>  	struct work_struct transmit_handshake_work, clear_peer_work, 
> transmit_packet_work;
>  	struct cookie latest_cookie;
> -	struct hlist_node pubkey_hash;
> +	struct rhash_head pubkey_hash;
>  	u64 rx_bytes, tx_bytes;
>  	struct timer_list timer_retransmit_handshake, timer_send_keepalive;
>  	struct timer_list timer_new_handshake, timer_zero_key_material;
> diff --git a/drivers/net/wireguard/peerlookup.c 
> b/drivers/net/wireguard/peerlookup.c
> index f2783aa7a88f..2ea2ba85a33d 100644
> --- a/drivers/net/wireguard/peerlookup.c
> +++ b/drivers/net/wireguard/peerlookup.c
> @@ -7,18 +7,29 @@
>  #include "peer.h"
>  #include "noise.h"
> 
> -static struct hlist_head *pubkey_bucket(struct pubkey_hashtable 
> *table,
> -					const u8 pubkey[NOISE_PUBLIC_KEY_LEN])
> +struct pubkey_pair {
> +	u8 key[NOISE_PUBLIC_KEY_LEN];
> +	siphash_key_t skey;
> +};
> +
> +static u32 pubkey_hash(const void *data, u32 len, u32 seed)
>  {
> +	const struct pubkey_pair *pair = data;
> +
>  	/* siphash gives us a secure 64bit number based on a random key. 
> Since
> -	 * the bits are uniformly distributed, we can then mask off to get 
> the
> -	 * bits we need.
> +	 * the bits are uniformly distributed.
>  	 */
> -	const u64 hash = siphash(pubkey, NOISE_PUBLIC_KEY_LEN, &table->key);
> 
> -	return &table->hashtable[hash & (HASH_SIZE(table->hashtable) - 1)];
> +	return (u32)siphash(pair->key, len, &pair->skey);
>  }
> 
> +static const struct rhashtable_params wg_peer_params = {
> +	.key_len = NOISE_PUBLIC_KEY_LEN,
> +	.key_offset = offsetof(struct wg_peer, handshake.remote_static),
> +	.head_offset = offsetof(struct wg_peer, pubkey_hash),
> +	.hashfn = pubkey_hash
> +};
> +
>  struct pubkey_hashtable *wg_pubkey_hashtable_alloc(void)
>  {
>  	struct pubkey_hashtable *table = kvmalloc(sizeof(*table), 
> GFP_KERNEL);
> @@ -27,26 +38,25 @@ struct pubkey_hashtable 
> *wg_pubkey_hashtable_alloc(void)
>  		return NULL;
> 
>  	get_random_bytes(&table->key, sizeof(table->key));
> -	hash_init(table->hashtable);
> -	mutex_init(&table->lock);
> +	rhashtable_init(&table->hashtable, &wg_peer_params);
> +
>  	return table;
>  }
> 
>  void wg_pubkey_hashtable_add(struct pubkey_hashtable *table,
>  			     struct wg_peer *peer)
>  {
> -	mutex_lock(&table->lock);
> -	hlist_add_head_rcu(&peer->pubkey_hash,
> -			   pubkey_bucket(table, peer->handshake.remote_static));
> -	mutex_unlock(&table->lock);
> +	memcpy(&peer->handshake.skey, &table->key, sizeof(table->key));
> +	WARN_ON(rhashtable_insert_fast(&table->hashtable, 
> &peer->pubkey_hash,
> +				       wg_peer_params));
>  }
> 
>  void wg_pubkey_hashtable_remove(struct pubkey_hashtable *table,
>  				struct wg_peer *peer)
>  {
> -	mutex_lock(&table->lock);
> -	hlist_del_init_rcu(&peer->pubkey_hash);
> -	mutex_unlock(&table->lock);
> +	memcpy(&peer->handshake.skey, &table->key, sizeof(table->key));
> +	rhashtable_remove_fast(&table->hashtable, &peer->pubkey_hash,
> +			       wg_peer_params);
>  }
> 
>  /* Returns a strong reference to a peer */
> @@ -54,41 +64,54 @@ struct wg_peer *
>  wg_pubkey_hashtable_lookup(struct pubkey_hashtable *table,
>  			   const u8 pubkey[NOISE_PUBLIC_KEY_LEN])
>  {
> -	struct wg_peer *iter_peer, *peer = NULL;
> +	struct wg_peer *peer = NULL;
> +	struct pubkey_pair pair;
> +
> +	memcpy(pair.key, pubkey, NOISE_PUBLIC_KEY_LEN);
> +	memcpy(&pair.skey, &table->key, sizeof(pair.skey));
> 
>  	rcu_read_lock_bh();
> -	hlist_for_each_entry_rcu_bh(iter_peer, pubkey_bucket(table, pubkey),
> -				    pubkey_hash) {
> -		if (!memcmp(pubkey, iter_peer->handshake.remote_static,
> -			    NOISE_PUBLIC_KEY_LEN)) {
> -			peer = iter_peer;
> -			break;
> -		}
> -	}
> -	peer = wg_peer_get_maybe_zero(peer);
> +	peer = 
> wg_peer_get_maybe_zero(rhashtable_lookup_fast(&table->hashtable,
> +							     &pair,
> +							     wg_peer_params));
>  	rcu_read_unlock_bh();
> +
>  	return peer;
>  }
> 
> -static struct hlist_head *index_bucket(struct index_hashtable *table,
> -				       const __le32 index)
> +void wg_pubkey_hashtable_destroy(struct pubkey_hashtable *table)
> +{
> +	WARN_ON(atomic_read(&table->hashtable.nelems));
> +	rhashtable_destroy(&table->hashtable);
> +}
> +
> +static u32 index_hash(const void *data, u32 len, u32 seed)
>  {
> +	const __le32 *index = data;
> +
>  	/* Since the indices are random and thus all bits are uniformly
> -	 * distributed, we can find its bucket simply by masking.
> +	 * distributed, we can use them as the hash value.
>  	 */
> -	return &table->hashtable[(__force u32)index &
> -				 (HASH_SIZE(table->hashtable) - 1)];
> +
> +	return (__force u32)*index;
>  }
> 
> -struct index_hashtable *wg_index_hashtable_alloc(void)
> +static const struct rhashtable_params index_entry_params = {
> +	.key_len = sizeof(__le32),
> +	.key_offset = offsetof(struct index_hashtable_entry, index),
> +	.head_offset = offsetof(struct index_hashtable_entry, index_hash),
> +	.hashfn = index_hash
> +};
> +
> +struct rhashtable *wg_index_hashtable_alloc(void)
>  {
> -	struct index_hashtable *table = kvmalloc(sizeof(*table), 
> GFP_KERNEL);
> +	struct rhashtable *table = kvmalloc(sizeof(*table), GFP_KERNEL);
> 
>  	if (!table)
>  		return NULL;
> 
> -	hash_init(table->hashtable);
> -	spin_lock_init(&table->lock);
> +	rhashtable_init(table, &index_entry_params);
> +
>  	return table;
>  }
> 
> @@ -116,111 +139,86 @@ struct index_hashtable 
> *wg_index_hashtable_alloc(void)
>   * is another thing to consider moving forward.
>   */
> 
> -__le32 wg_index_hashtable_insert(struct index_hashtable *table,
> +__le32 wg_index_hashtable_insert(struct rhashtable *table,
>  				 struct index_hashtable_entry *entry)
>  {
>  	struct index_hashtable_entry *existing_entry;
> 
> -	spin_lock_bh(&table->lock);
> -	hlist_del_init_rcu(&entry->index_hash);
> -	spin_unlock_bh(&table->lock);
> +	wg_index_hashtable_remove(table, entry);
> 
>  	rcu_read_lock_bh();
> 
>  search_unused_slot:
>  	/* First we try to find an unused slot, randomly, while unlocked. */
>  	entry->index = (__force __le32)get_random_u32();
> -	hlist_for_each_entry_rcu_bh(existing_entry,
> -				    index_bucket(table, entry->index),
> -				    index_hash) {
> -		if (existing_entry->index == entry->index)
> -			/* If it's already in use, we continue searching. */
> -			goto search_unused_slot;
> -	}
> 
> -	/* Once we've found an unused slot, we lock it, and then 
> double-check
> -	 * that nobody else stole it from us.
> -	 */
> -	spin_lock_bh(&table->lock);
> -	hlist_for_each_entry_rcu_bh(existing_entry,
> -				    index_bucket(table, entry->index),
> -				    index_hash) {
> -		if (existing_entry->index == entry->index) {
> -			spin_unlock_bh(&table->lock);
> -			/* If it was stolen, we start over. */
> -			goto search_unused_slot;
> -		}
> +	existing_entry = rhashtable_lookup_get_insert_fast(table,
> +							   &entry->index_hash,
> +							   index_entry_params);
> +
> +	if (existing_entry) {
> +		WARN_ON(IS_ERR(existing_entry));
> +
> +		/* If it's already in use, we continue searching. */
> +		goto search_unused_slot;
>  	}
> -	/* Otherwise, we know we have it exclusively (since we're locked),
> -	 * so we insert.
> -	 */
> -	hlist_add_head_rcu(&entry->index_hash,
> -			   index_bucket(table, entry->index));
> -	spin_unlock_bh(&table->lock);
> 
>  	rcu_read_unlock_bh();
> 
>  	return entry->index;
>  }
> 
> -bool wg_index_hashtable_replace(struct index_hashtable *table,
> +bool wg_index_hashtable_replace(struct rhashtable *table,
>  				struct index_hashtable_entry *old,
>  				struct index_hashtable_entry *new)
>  {
> -	bool ret;
> +	int ret = rhashtable_replace_fast(table, &old->index_hash,
> +					  &new->index_hash,
> +					  index_entry_params);
> 
> -	spin_lock_bh(&table->lock);
> -	ret = !hlist_unhashed(&old->index_hash);
> -	if (unlikely(!ret))
> -		goto out;
> +	WARN_ON(ret == -EINVAL);
> 
> -	new->index = old->index;
> -	hlist_replace_rcu(&old->index_hash, &new->index_hash);
> -
> -	/* Calling init here NULLs out index_hash, and in fact after this
> -	 * function returns, it's theoretically possible for this to get
> -	 * reinserted elsewhere. That means the RCU lookup below might 
> either
> -	 * terminate early or jump between buckets, in which case the packet
> -	 * simply gets dropped, which isn't terrible.
> -	 */
> -	INIT_HLIST_NODE(&old->index_hash);
> -out:
> -	spin_unlock_bh(&table->lock);
> -	return ret;
> +	return ret != -ENOENT;
>  }
> 
> -void wg_index_hashtable_remove(struct index_hashtable *table,
> +void wg_index_hashtable_remove(struct rhashtable *table,
>  			       struct index_hashtable_entry *entry)
>  {
> -	spin_lock_bh(&table->lock);
> -	hlist_del_init_rcu(&entry->index_hash);
> -	spin_unlock_bh(&table->lock);
> +	rhashtable_remove_fast(table, &entry->index_hash, 
> index_entry_params);
>  }
> 
>  /* Returns a strong reference to a entry->peer */
>  struct index_hashtable_entry *
> -wg_index_hashtable_lookup(struct index_hashtable *table,
> +wg_index_hashtable_lookup(struct rhashtable *table,
>  			  const enum index_hashtable_type type_mask,
>  			  const __le32 index, struct wg_peer **peer)
>  {
> -	struct index_hashtable_entry *iter_entry, *entry = NULL;
> +	struct index_hashtable_entry *entry = NULL;
> 
>  	rcu_read_lock_bh();
> -	hlist_for_each_entry_rcu_bh(iter_entry, index_bucket(table, index),
> -				    index_hash) {
> -		if (iter_entry->index == index) {
> -			if (likely(iter_entry->type & type_mask))
> -				entry = iter_entry;
> -			break;
> -		}
> -	}
> +	entry = rhashtable_lookup_fast(table, &index, index_entry_params);
> +
>  	if (likely(entry)) {
> +		if (unlikely(!(entry->type & type_mask))) {
> +			entry = NULL;
> +			goto out;
> +		}
> +
>  		entry->peer = wg_peer_get_maybe_zero(entry->peer);
>  		if (likely(entry->peer))
>  			*peer = entry->peer;
>  		else
>  			entry = NULL;
>  	}
> +
> +out:
>  	rcu_read_unlock_bh();
> +
>  	return entry;
>  }
> +
> +void wg_index_hashtable_destroy(struct rhashtable *table)
> +{
> +	WARN_ON(atomic_read(&table->nelems));
> +	rhashtable_destroy(table);
> +}
> diff --git a/drivers/net/wireguard/peerlookup.h 
> b/drivers/net/wireguard/peerlookup.h
> index ced811797680..a3cef26cb733 100644
> --- a/drivers/net/wireguard/peerlookup.h
> +++ b/drivers/net/wireguard/peerlookup.h
> @@ -8,17 +8,14 @@
> 
>  #include "messages.h"
> 
> -#include <linux/hashtable.h>
> -#include <linux/mutex.h>
> +#include <linux/rhashtable.h>
>  #include <linux/siphash.h>
> 
>  struct wg_peer;
> 
>  struct pubkey_hashtable {
> -	/* TODO: move to rhashtable */
> -	DECLARE_HASHTABLE(hashtable, 11);
> +	struct rhashtable hashtable;
>  	siphash_key_t key;
> -	struct mutex lock;
>  };
> 
>  struct pubkey_hashtable *wg_pubkey_hashtable_alloc(void);
> @@ -29,12 +26,7 @@ void wg_pubkey_hashtable_remove(struct 
> pubkey_hashtable *table,
>  struct wg_peer *
>  wg_pubkey_hashtable_lookup(struct pubkey_hashtable *table,
>  			   const u8 pubkey[NOISE_PUBLIC_KEY_LEN]);
> -
> -struct index_hashtable {
> -	/* TODO: move to rhashtable */
> -	DECLARE_HASHTABLE(hashtable, 13);
> -	spinlock_t lock;
> -};
> +void wg_pubkey_hashtable_destroy(struct pubkey_hashtable *table);
> 
>  enum index_hashtable_type {
>  	INDEX_HASHTABLE_HANDSHAKE = 1U << 0,
> @@ -43,22 +35,23 @@ enum index_hashtable_type {
> 
>  struct index_hashtable_entry {
>  	struct wg_peer *peer;
> -	struct hlist_node index_hash;
> +	struct rhash_head index_hash;
>  	enum index_hashtable_type type;
>  	__le32 index;
>  };
> 
> -struct index_hashtable *wg_index_hashtable_alloc(void);
> -__le32 wg_index_hashtable_insert(struct index_hashtable *table,
> +struct rhashtable *wg_index_hashtable_alloc(void);
> +__le32 wg_index_hashtable_insert(struct rhashtable *table,
>  				 struct index_hashtable_entry *entry);
> -bool wg_index_hashtable_replace(struct index_hashtable *table,
> +bool wg_index_hashtable_replace(struct rhashtable *table,
>  				struct index_hashtable_entry *old,
>  				struct index_hashtable_entry *new);
> -void wg_index_hashtable_remove(struct index_hashtable *table,
> +void wg_index_hashtable_remove(struct rhashtable *table,
>  			       struct index_hashtable_entry *entry);
>  struct index_hashtable_entry *
> -wg_index_hashtable_lookup(struct index_hashtable *table,
> +wg_index_hashtable_lookup(struct rhashtable *table,
>  			  const enum index_hashtable_type type_mask,
>  			  const __le32 index, struct wg_peer **peer);
> +void wg_index_hashtable_destroy(struct rhashtable *table);
> 
>  #endif /* _WG_PEERLOOKUP_H */
> --
> 2.32.0
> 



From Jason at zx2c4.com  Wed Sep  8 11:27:12 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 8 Sep 2021 13:27:12 +0200
Subject: [PATCH] wireguard: convert index_hashtable and pubkey_hashtable
 into rhashtables
In-Reply-To: <OD24ZQ.IQOQXX8U0YST@effective-light.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
 <OD24ZQ.IQOQXX8U0YST@effective-light.com>
Message-ID: <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>

Hi Hamza,

Thanks for this patch. I have a few concerns/questions about it:

- What's performance like? Does the abstraction of rhashtable
introduce overhead? These are used in fast paths -- for every packet
-- so being quick is important.

- How does this interact with the timing side channel concerns in the
comment of the file? Will the time required to find an unused index
leak the number of items in the hash table? Do we need stochastic
masking? Or is the construction of rhashtable such that we always get
ball-park same time?

Thanks,
Jason

From someguy at effective-light.com  Thu Sep  9 01:56:12 2021
From: someguy at effective-light.com (Hamza Mahfooz)
Date: Wed, 08 Sep 2021 21:56:12 -0400
Subject: [PATCH] wireguard: convert index_hashtable and pubkey_hashtable
 into rhashtables
In-Reply-To: <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
 <OD24ZQ.IQOQXX8U0YST@effective-light.com>
 <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>
Message-ID: <OD95ZQ.FW5WHNPSV04F@effective-light.com>

Hey Jason,
On Wed, Sep 8 2021 at 01:27:12 PM +0200, Jason A. Donenfeld 
<Jason at zx2c4.com> wrote:
> - What's performance like? Does the abstraction of rhashtable
> introduce overhead? These are used in fast paths -- for every packet
> -- so being quick is important.

Are you familiar with any (micro)benchmarks (for WireGuard) that, you
believe would be particularly informative in assessing the outlined
performance characteristics?

> - How does this interact with the timing side channel concerns in the
> comment of the file? Will the time required to find an unused index
> leak the number of items in the hash table? Do we need stochastic
> masking? Or is the construction of rhashtable such that we always get
> ball-park same time?

I think the maintainers of rhashtable are best positioned to answer 
these
questions (I have cc'd them).



From peter.whisker at gmail.com  Thu Sep  9 07:59:02 2021
From: peter.whisker at gmail.com (Peter Whisker)
Date: Thu, 9 Sep 2021 08:59:02 +0100
Subject: Issues with latest Windows build
In-Reply-To: <OD95ZQ.FW5WHNPSV04F@effective-light.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
 <OD24ZQ.IQOQXX8U0YST@effective-light.com>
 <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>
 <OD95ZQ.FW5WHNPSV04F@effective-light.com>
Message-ID: <5daec7ab-a97d-819e-56cd-c45176d355ee@gmail.com>

Hi

I have a remote Windows system which listens for multiple inbound 
connections (and creates one outbound one) on a single tunnel. It worked 
fine with the new kernel driver but with the latest release 0.4.6 it has 
now stopped working.

Although it sees incoming packets (and shows the counts going up) it 
fails to respond to any inbound connections. If I switch kernel mode off 
it works fine in legacy Go mode so there is nothing wrong with the keys 
or routing.

Peter


From Jason at zx2c4.com  Thu Sep  9 08:05:16 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 9 Sep 2021 10:05:16 +0200
Subject: Issues with latest Windows build
In-Reply-To: <5daec7ab-a97d-819e-56cd-c45176d355ee@gmail.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
 <OD24ZQ.IQOQXX8U0YST@effective-light.com>
 <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>
 <OD95ZQ.FW5WHNPSV04F@effective-light.com>
 <5daec7ab-a97d-819e-56cd-c45176d355ee@gmail.com>
Message-ID: <CAHmME9qEAUXtZSd70sO8OzBk6Rmnib07VEbPm6GWhugE_ghdyA@mail.gmail.com>

Hi Peter,

Can you describe more about your configuration, and perhaps share some
configs? As well, could you send your log and mention your operating
system version? For this to be fixed, I'll need details. I'm also
BCCing WGML to take this private.

Thanks,
Jason

From Jason at zx2c4.com  Thu Sep  9 09:21:03 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 9 Sep 2021 11:21:03 +0200
Subject: Issues with latest Windows build
In-Reply-To: <eaef596b-c75d-3f42-f43a-fa80cc98d732@gmail.com>
References: <20210806044315.169657-1-someguy@effective-light.com>
 <OD24ZQ.IQOQXX8U0YST@effective-light.com>
 <CAHmME9oSo=4BtfO+=327n=gsor5gWcvhzAMS_BpqQ-6=6yxVRA@mail.gmail.com>
 <OD95ZQ.FW5WHNPSV04F@effective-light.com>
 <5daec7ab-a97d-819e-56cd-c45176d355ee@gmail.com>
 <CAHmME9qEAUXtZSd70sO8OzBk6Rmnib07VEbPm6GWhugE_ghdyA@mail.gmail.com>
 <044be90d-1caf-08a2-3389-d60010986b16@gmail.com>
 <CAHmME9pJQ8cgOhHPZU+3o9nMgoMe_OrWg+gkY34iOMAd-AZHCQ@mail.gmail.com>
 <3329757c-b2b9-113d-b6e4-fc28f86cd704@gmail.com>
 <CAHmME9osjYgu-0CbEvpNK-Vj6CWg8njraAdegefeG1NrJUETfA@mail.gmail.com>
 <eaef596b-c75d-3f42-f43a-fa80cc98d732@gmail.com>
Message-ID: <CAHmME9qUkyAYCHqeQn=ku70uWJYaL7Oi5A9ZGQ_x1aokVLPi3w@mail.gmail.com>

On Thu, Sep 9, 2021 at 10:37 AM Peter Whisker <peter.whisker at gmail.com> wrote:
>
> Here is the [...]

Thanks for the info, Peter. Fixed here: https://w-g.pw/l/S_Ts
I'll have a new build up sometime soonish.

Jason

From Jason at zx2c4.com  Thu Sep  9 11:41:39 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 9 Sep 2021 13:41:39 +0200
Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard
 implementation for the Windows kernel
In-Reply-To: <CAHmME9p8WLAzd=W+Z6MKtke5PYb_T6iMbvBFirmCeUQzxycRwQ@mail.gmail.com>
References: <YQgrCfqIL2SWfF6G@zx2c4.com>
 <CAHmME9p8WLAzd=W+Z6MKtke5PYb_T6iMbvBFirmCeUQzxycRwQ@mail.gmail.com>
Message-ID: <CAHmME9qTWf_34Jd5rh+foOPXN6bTepweC6cK=SS=Ls3C2PkYAA@mail.gmail.com>

Hi again,

On Fri, Aug 13, 2021 at 1:52 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi everyone,
>
> On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> > Nonetheless, experimental or not, we still need people to test this and help
> > shake out issues. To that end, WireGuardNT is now available in the ordinary
> > WireGuard for Windows client -- https://www.wireguard.com/install/ -- with the
> > 0.4.z series, in addition to having full support of the venerable wg(8)
> > utility, but currently (August 2021; if you're reading this in the future this
> > might not apply) it is behind a manually set registry knob. There will be
> > three phases of the 0.4.z series:
> >
> >   Phase 1) WireGuardNT is hidden behind the "ExperimentalKernelDriver"
> >            registry knob. If you don't manually tinker around to enable it,
> >            the client will continue to use wireguard-go/Wintun like before.
>
> After the first few days, bug reports for WireGuardNT have died down
> considerably. It's hard to tell whether that's a sign that the
> software is stable or that nobody is using it. So, we're still in
> phase 1. However, with version 0.4.5 of the client, I've added a
> checkbox below the "activate" button in order to make the experimental
> testing more discoverable. I dislike such knobs, but I'd rather have
> more testing than less, before turning it on by default. Hopefully
> this will make it easier for alpha testers to give it a spin and
> report findings. If you have been testing the driver, and it's been
> working well for you, please write in to say so, simply as a signal
> that it is being tested. If things stay as quiet as they are now on
> the bug reporting front, we'll likely move into phase 2 -- enabling
> WireGuardNT by default, with a registry key to revert to the legacy
> implementation -- in 2 to 3 weeks.

We're still technically in phase 1, but with the version that should
be coming out later today, users who have enrolled in the Windows
Insider Program have "ExperimentalKernelDriver" set to always on,
unless the "IgnoreInsiderProgram" admin knob is set. In other words,
we're gradually ramping up testing coverage. I still hope to move into
phase 2 soon, but this seemed like a cautious intermediate step.

Regards,
Jason

From bspencer at blackberry.com  Thu Sep  9 14:32:01 2021
From: bspencer at blackberry.com (Brad Spencer)
Date: Thu, 9 Sep 2021 11:32:01 -0300
Subject: Wintun NeighborDiscoverySupported
Message-ID: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>

We have noticed that Windows seems to try to send ARP requests over 
Wintun interfaces.? In our configurations, these don't go anywhere and 
get no responses, but the ARP table fills up with addresses.? For example:

$? arp -a -N 10.0.0.100 |wc -l
387

Our Wintun interfaces are created with these properties:

PS C:\> Get-NetIPInterface -InterfaceIndex 69 |Select-Object -Property 
AddressFamily,NeighborDiscoverySupported,NeighborUnreachabilityDetection |fl

AddressFamily?????????????????? : IPv6
NeighborDiscoverySupported????? : Yes
NeighborUnreachabilityDetection : Enabled

AddressFamily?????????????????? : IPv4
NeighborDiscoverySupported????? : Yes
NeighborUnreachabilityDetection : Enabled

We _think_ that the NeighborDiscoverySupported property being Yes means 
that Windows issues ARP requests for addresses on the Wintun interface.? 
(The second property controls another neighbour behaviour that perhaps 
could also be disabled for Wintun interfaces.)

Microsoft's documentation for SetIpInterfaceEntry() claims that these 
properties are set "by the network stack", but offers no hint as to what 
part of the network stack does this.? It does not seem possible to 
change these properties on an existing interface.

Are these properties that either the Wintun driver or user-space API is 
able to control?? Should they be set to No and Disabled?? I don't see 
any use of the driver variant of SetIpInterfaceEntry() or 
MIB_IPINTERFACE_ROW in Wintun's driver or API code, so I'm not sure when 
these properties get determined.

-- 
Brad Spencer


From Jason at zx2c4.com  Thu Sep  9 17:42:45 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 9 Sep 2021 19:42:45 +0200
Subject: Wintun NeighborDiscoverySupported
In-Reply-To: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
References: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
Message-ID: <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>

Hi Brad,

That sure is interesting. Indeed UseNeighborUnreachabilityDetection
and SupportsNeighborDiscovery can't be set with SetIpInterfaceEntry. I
haven't (yet?) found any way for the driver itself to indicate that
these should be false, either, via OIDs or similar. This might require
some frustrating reverse engineering. I remember noticing this a long
time ago, but I deemed it "annoying but harmless". However, you now
mention:

On Thu, Sep 9, 2021 at 4:33 PM Brad Spencer <bspencer at blackberry.com> wrote:
> but the ARP table fills up with addresses.  For example:
>
> $  arp -a -N 10.0.0.100 |wc -l
> 387

If that grows indefinitely, that sounds... bad. So this might be worth
looking into again. One thing about your message, though, raised a
question in my mind, but I'm not sure whether its an artifact of your
wording or a real thing you observed:

> We have noticed that Windows seems to try to send ARP requests over
> Wintun interfaces.  In our configurations, these don't go anywhere and
> get no responses,

Indeed the ARP table fills up, as shown above, but I'm wondering how
you're observing ARP requests exactly. ARP is a layer 2 protocol, and
Wintun (and WireGuardNT) are layer 3 devices that should, in theory at
least, not have anything to do with ARP packets. So how exactly were
you "seeing" the ARP requests on the Wintun interface? Did wireshark
show it? Or did you read from the Wintun ring and actually see an ARP
frame? Or something else? Or was this just a manner of speaking and
you didn't actually observe ARP frames themselves?

Another small question:

> We _think_ that the NeighborDiscoverySupported property being Yes means
> that Windows issues ARP requests for addresses on the Wintun interface.

That seems like a good intuition. I'm wondering whether that's
something you're assuming or something you read on a Microsoft
website. I ask because this might provide a good entry point for
whatever reverse engineering I wind up doing to fix this.

Regards,
Jason

From bspencer at blackberry.com  Thu Sep  9 18:15:02 2021
From: bspencer at blackberry.com (Brad Spencer)
Date: Thu, 9 Sep 2021 15:15:02 -0300
Subject: Wintun NeighborDiscoverySupported
In-Reply-To: <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>
References: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
 <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>
Message-ID: <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>

On 2021-09-09 2:42 p.m., Jason A. Donenfeld wrote:
> So how exactly were
> you "seeing" the ARP requests on the Wintun interface? Did wireshark
> show it? Or did you read from the Wintun ring and actually see an ARP
> frame? Or something else? Or was this just a manner of speaking and
> you didn't actually observe ARP frames themselves?
You're right to suspect that I was speaking imprecisely here.? We have 
never seen an ARP request appear on the Wintun interface!? I meant to 
say that we have noticed the ARP table for the Wintun interface 
accumulating entries.

>> We _think_ that the NeighborDiscoverySupported property being Yes means
>> that Windows issues ARP requests for addresses on the Wintun interface.
> That seems like a good intuition. I'm wondering whether that's
> something you're assuming or something you read on a Microsoft
> website. I ask because this might provide a good entry point for
> whatever reverse engineering I wind up doing to fix this.
I pieced this together from a few scraps.

On the MIB_IPINTERFACE_ROW page[1], the docs only tersely say:

"A value that specifies if the IP interface support neighbor discovery."

Microsoft seems to use the same terminology when documenting 
SetIpNetEntry2()[2]:

"The SetIpNetEntry2 function sets the physical address of an existing 
neighbor IP address entry on the local computer."

And then, most importantly, MIB_IPNET_ROW2, the structure used by that 
function says this in its Remarks section[3]:

"For IPv4, this includes addresses determined used the Address 
Resolution Protocol (ARP). For IPv6, this includes addresses determined 
using the Neighbor Discovery (ND) protocol for IPv6 as specified in RFC 
2461. "

So, it seems that the "NetEntry" APIs are those that deal with ARP (and 
ND) entries, and the term Microsoft uses for that is "neighbor discovery".

I don't know if the SupportsNeighborDiscovery field of MIB_INTERFACE_ROW 
is implied by other properties of the network interface (such as "all 
Ethernet interfaces support ARP") or whether it can be individually set 
at all.

One other detail is that we have the gateway for the tunnel's routes set 
to 0.0.0.0 (or "::").? I presume that also influences how Windows 
decides which addresses might be on-link neighbours.

1. 
https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipinterface_row
2. 
https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipnetentry2
3. 
https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipnet_table2

-- 
Brad Spencer


From alan at meshify.app  Thu Sep  9 20:23:00 2021
From: alan at meshify.app (Alan Graham)
Date: Thu, 9 Sep 2021 13:23:00 -0700
Subject: Wintun NeighborDiscoverySupported
In-Reply-To: <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>
References: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
 <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>
 <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>
Message-ID: <CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com>

Hi Brad, Jason,

Adding the 0.0.0.0/0 (or ":::") to the config is what is causing some
growth of the arp table, but it is not growing indefinitely.  After
looking around for SupportsNeighborDiscovery and finding nothing, I
decided to check the repro.  When not routing all traffic through an
interface the arp cache is basically static:

PS C:\>  arp -a -N 100.0.0.2

Interface: 100.0.0.2 --- 0x38
  Internet Address      Physical Address      Type
  100.0.0.4                                   dynamic
  224.0.0.22                                  static
  224.0.0.251                                 static
  224.0.0.252                                 static
  239.255.255.250                             static

When routing all traffic through it grows more or less like an arp cache should:

PS C:\>  arp -a -N 100.0.0.2

Interface: 100.0.0.2 --- 0x38
  Internet Address      Physical Address      Type
  0.0.0.0                                     static
  8.8.4.4                                     dynamic
  8.8.8.8                                     dynamic
  13.64.180.106                               dynamic
  18.211.21.156                               dynamic
  20.98.103.204                               dynamic
  23.6.164.43                                 dynamic
  23.40.197.163                               dynamic
  23.204.103.147                              dynamic
  35.185.199.42                               dynamic
  40.83.247.108                               dynamic
  51.143.14.218                               dynamic
  54.214.97.217                               dynamic
  65.8.17.107                                 dynamic
  67.160.11.228                               dynamic
  69.1.20.242                                 dynamic
  73.118.184.4                                dynamic
  74.125.142.188                              dynamic
  74.125.197.188                              dynamic
  75.75.75.75                                 dynamic
  100.0.0.2                                   dynamic
  100.0.0.4                                   dynamic
  142.250.69.202                              dynamic
  142.250.217.99                              dynamic
  142.251.33.74                               dynamic
  142.251.33.106                              dynamic
  173.194.202.189                             dynamic
  192.168.200.2                               dynamic
  192.228.79.201                              dynamic
  224.0.0.22                                  static
  224.0.0.251                                 static
  224.0.0.252                                 static
  239.255.255.250                             static

So I tend to agree with Jason that this is "harmless" and shouldn't
cause any serious problems.  It would be nice for Microsoft to fix
Set-NetIPInterface, it looks like a bug that SupportsNeighborDiscovery
can't be set.

Best regards,
Alan Graham


On Thu, Sep 9, 2021 at 11:17 AM Brad Spencer <bspencer at blackberry.com> wrote:
>
> On 2021-09-09 2:42 p.m., Jason A. Donenfeld wrote:
> > So how exactly were
> > you "seeing" the ARP requests on the Wintun interface? Did wireshark
> > show it? Or did you read from the Wintun ring and actually see an ARP
> > frame? Or something else? Or was this just a manner of speaking and
> > you didn't actually observe ARP frames themselves?
> You're right to suspect that I was speaking imprecisely here.  We have
> never seen an ARP request appear on the Wintun interface!  I meant to
> say that we have noticed the ARP table for the Wintun interface
> accumulating entries.
>
> >> We _think_ that the NeighborDiscoverySupported property being Yes means
> >> that Windows issues ARP requests for addresses on the Wintun interface.
> > That seems like a good intuition. I'm wondering whether that's
> > something you're assuming or something you read on a Microsoft
> > website. I ask because this might provide a good entry point for
> > whatever reverse engineering I wind up doing to fix this.
> I pieced this together from a few scraps.
>
> On the MIB_IPINTERFACE_ROW page[1], the docs only tersely say:
>
> "A value that specifies if the IP interface support neighbor discovery."
>
> Microsoft seems to use the same terminology when documenting
> SetIpNetEntry2()[2]:
>
> "The SetIpNetEntry2 function sets the physical address of an existing
> neighbor IP address entry on the local computer."
>
> And then, most importantly, MIB_IPNET_ROW2, the structure used by that
> function says this in its Remarks section[3]:
>
> "For IPv4, this includes addresses determined used the Address
> Resolution Protocol (ARP). For IPv6, this includes addresses determined
> using the Neighbor Discovery (ND) protocol for IPv6 as specified in RFC
> 2461. "
>
> So, it seems that the "NetEntry" APIs are those that deal with ARP (and
> ND) entries, and the term Microsoft uses for that is "neighbor discovery".
>
> I don't know if the SupportsNeighborDiscovery field of MIB_INTERFACE_ROW
> is implied by other properties of the network interface (such as "all
> Ethernet interfaces support ARP") or whether it can be individually set
> at all.
>
> One other detail is that we have the gateway for the tunnel's routes set
> to 0.0.0.0 (or "::").  I presume that also influences how Windows
> decides which addresses might be on-link neighbours.
>
> 1.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipinterface_row
> 2.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipnetentry2
> 3.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/ns-netioapi-mib_ipnet_table2
>
> --
> Brad Spencer
>

From bspencer at blackberry.com  Fri Sep 10 17:19:03 2021
From: bspencer at blackberry.com (Brad Spencer)
Date: Fri, 10 Sep 2021 14:19:03 -0300
Subject: Wintun NeighborDiscoverySupported
In-Reply-To: <CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com>
References: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
 <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>
 <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>
 <CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com>
Message-ID: <c84c5f5f-6c47-e109-7592-cd7353761657@blackberry.com>

On 2021-09-09 5:23 p.m., Alan Graham wrote:
> Adding the 0.0.0.0/0 (or ":::") to the config is what is causing some
> growth of the arp table, but it is not growing indefinitely.  After
> looking around for SupportsNeighborDiscovery and finding nothing, I
> decided to check the repro.  When not routing all traffic through an
> interface the arp cache is basically static:

Thanks for looking into this, too.

I also suspect having the gateway set like this is probably necessary 
for Windows to start adding ARP entries.? How were you able to determine 
that it is also sufficient?? My guess is that if it is possible to 
indicate to Windows that the interface does not support neighbour 
discovery in general, doing so likely prevents ARP entries regardless of 
the gateway values.

BTW, how did you determine that it does not grow indefinitely?

> So I tend to agree with Jason that this is "harmless" and shouldn't
> cause any serious problems.  It would be nice for Microsoft to fix
> Set-NetIPInterface, it looks like a bug that SupportsNeighborDiscovery
> can't be set.

One "harm" might be that the OS keeping an easy-to-query list of all 
(recent?) destinations in the ARP table, which could be undesirable.

I'm not sure it's a bug, per se.? It seems by design that you cannot 
change the value of SupportsNeighborDiscovery after the interface is 
created.? The documentation for SetIpInterfaceEntry()[1] says:

> The MaxReassemblySize, MinRouterAdvertisementInterval, 
> MaxRouterAdvertisementInterval , Connected, SupportsWakeUpPatterns, 
> SupportsNeighborDiscovery, SupportsRouterDiscovery, ReachableTime, 
> TransmitOffload, and ReceiveOffload members of the MIB_IPINTERFACE_ROW 
> structure pointed to by the Row are ignored when the 
> SetIpInterfaceEntry function is called. These members are set by the 
> network stack and cannot be changed using the SetIpInterfaceEntry 
> function.

I noticed that the Cmdlet in PowerShell seems to treat the 
-NeighborDiscoverySupported option as an input filter vs. a value that 
you can set.? While this surprised me, it is at least consistent with 
the Win32 API docs.

1. 
https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipinterfaceentry#remarks 


-- 
Brad Spencer


From alan at meshify.app  Fri Sep 10 20:56:31 2021
From: alan at meshify.app (Alan Graham)
Date: Fri, 10 Sep 2021 13:56:31 -0700
Subject: Wintun NeighborDiscoverySupported
In-Reply-To: <c84c5f5f-6c47-e109-7592-cd7353761657@blackberry.com>
References: <00042bf6-4e8c-8638-380d-6774b37f96c2@blackberry.com>
 <CAHmME9qXieNWU_Y5rz1eDM9Bh=YjBPaeQFTrsXr4PKHyh1ePRA@mail.gmail.com>
 <310f3386-a488-9e28-2f10-3f867ece0f53@blackberry.com>
 <CAMeHLtxw939uNJcN=UZAR9wM10pB2xYOu2K_X++Z8LsfPCAmNw@mail.gmail.com>
 <c84c5f5f-6c47-e109-7592-cd7353761657@blackberry.com>
Message-ID: <CAMeHLtwY4Gia=+tkKRYUE4HTz4RGvqwTVSuaxqw9LpVg0yrKTg@mail.gmail.com>

I mainly reached the conclusion that it's not growing indefinitely by
looking at the results in the arp table.  There weren't duplicates or
other errors which might suggest the arp table wasn't working
properly.  I believe it is, in that it should be aging out entries,
etc.  I also stopped and restarted the wireguard service and it
cleared the cache as it should.

I also noticed the Powershell Cmdlet used the wrong filter parameters
when trying to set NeighborDiscoverySupported, as you did.  My
expectation would be to get an error invalid parameter like with
NeighborUnreachabilityDetection, not that the filter returned zero
results because it used the wrong query.

Best regards,
Alan Graham


On Fri, Sep 10, 2021 at 10:19 AM Brad Spencer <bspencer at blackberry.com> wrote:
>
> On 2021-09-09 5:23 p.m., Alan Graham wrote:
> > Adding the 0.0.0.0/0 (or ":::") to the config is what is causing some
> > growth of the arp table, but it is not growing indefinitely.  After
> > looking around for SupportsNeighborDiscovery and finding nothing, I
> > decided to check the repro.  When not routing all traffic through an
> > interface the arp cache is basically static:
>
> Thanks for looking into this, too.
>
> I also suspect having the gateway set like this is probably necessary
> for Windows to start adding ARP entries.  How were you able to determine
> that it is also sufficient?  My guess is that if it is possible to
> indicate to Windows that the interface does not support neighbour
> discovery in general, doing so likely prevents ARP entries regardless of
> the gateway values.
>
> BTW, how did you determine that it does not grow indefinitely?
>
> > So I tend to agree with Jason that this is "harmless" and shouldn't
> > cause any serious problems.  It would be nice for Microsoft to fix
> > Set-NetIPInterface, it looks like a bug that SupportsNeighborDiscovery
> > can't be set.
>
> One "harm" might be that the OS keeping an easy-to-query list of all
> (recent?) destinations in the ARP table, which could be undesirable.
>
> I'm not sure it's a bug, per se.  It seems by design that you cannot
> change the value of SupportsNeighborDiscovery after the interface is
> created.  The documentation for SetIpInterfaceEntry()[1] says:
>
> > The MaxReassemblySize, MinRouterAdvertisementInterval,
> > MaxRouterAdvertisementInterval , Connected, SupportsWakeUpPatterns,
> > SupportsNeighborDiscovery, SupportsRouterDiscovery, ReachableTime,
> > TransmitOffload, and ReceiveOffload members of the MIB_IPINTERFACE_ROW
> > structure pointed to by the Row are ignored when the
> > SetIpInterfaceEntry function is called. These members are set by the
> > network stack and cannot be changed using the SetIpInterfaceEntry
> > function.
>
> I noticed that the Cmdlet in PowerShell seems to treat the
> -NeighborDiscoverySupported option as an input filter vs. a value that
> you can set.  While this surprised me, it is at least consistent with
> the Win32 API docs.
>
> 1.
> https://docs.microsoft.com/en-us/windows/win32/api/netioapi/nf-netioapi-setipinterfaceentry#remarks
>
>
> --
> Brad Spencer
>

From buddybalaa at gmail.com  Sun Sep 12 12:28:24 2021
From: buddybalaa at gmail.com (Mo Balaa)
Date: Sun, 12 Sep 2021 07:28:24 -0500
Subject: Hiring: Free Software Network Security Engineer
Message-ID: <CAKmhVkpNf0b54udsaB26W7a8ivct5RO66CF-NAhYZ+FSaGHNGg@mail.gmail.com>

Hello WireGuards,

My company, Fractal Networks, is funding the development of a
self-hosted free software ecosystem targeted at self-hosting
enthusiasts and small to midsize enterprises.

Our primary mission is to empower online communities to take ownership
of their digital infrastructure and we are developing the free
software tools to make that possible.

Beyond that, we make existing free software applications highly
available, easy to deploy, manage and scale over personal (WireGuard
powered) overlay networks which brings me to the point of this post.

We are in need of free software network security engineers. Someone
who appreciates the importance of free software and would like to work
on developing network security tooling as free software.

Please email wireguardjobs at ether.ai if you would like to learn more
about this position.

Shout out to Jason and everyone else who works on WireGuard as free software.

Cheers,

Mo Balaa
CEO Founder
Fractal Networks

From Jason at zx2c4.com  Sun Sep 12 14:18:29 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 12 Sep 2021 16:18:29 +0200
Subject: Hiring: Free Software Network Security Engineer
In-Reply-To: <CAKmhVkpNf0b54udsaB26W7a8ivct5RO66CF-NAhYZ+FSaGHNGg@mail.gmail.com>
References: <CAKmhVkpNf0b54udsaB26W7a8ivct5RO66CF-NAhYZ+FSaGHNGg@mail.gmail.com>
Message-ID: <CAHmME9q9bVNfHSgNVcc+a1stXoWpotrYu_0W_55hvo8KMQoVaQ@mail.gmail.com>

Please do not advertise on this mailing list.

[There is no need to send a follow up email to this thread.]

From s.devanath at gmail.com  Sun Sep 12 15:07:46 2021
From: s.devanath at gmail.com (Devanath S)
Date: Sun, 12 Sep 2021 08:07:46 -0700
Subject: wireguard-go on windows
In-Reply-To: <CADjMg7Vp+p7n_JLMfFU4GwtNu_X3ARFJOuhxLasonuD-fvB5Hg@mail.gmail.com>
References: <CADjMg7Vp+p7n_JLMfFU4GwtNu_X3ARFJOuhxLasonuD-fvB5Hg@mail.gmail.com>
Message-ID: <CADjMg7VhY5oDjN7KPKkTZd9RhZEK_xZ4SYcs9Q13j5u2e54K_w@mail.gmail.com>

Hi All,,

I am trying to run wireguard-go (using
"golang.zx2c4.com/wireguard/wgctrl" for configure) on
container-optimized os on GCP and I am facing the below issue. The
same works on ubuntu/centos etc

1) Wireguard device creation and tunnel gets created as required. It
works as expected
2) When the admin wants to delete the wg tunnel interface and recreate
the wg interface.  It gives error "err device or resource busy"

=> To create the tunnel device
tun.CreateTUN(deviceName, mtu).
device.NewDevice(tun, deviceLogger)
=>To delete the tunnel device
func (device *Device) Close()  which is probably calling
tun.tunFile.Close(), to close the FD

----Snippet of the logs, while closing the device and creating again

^[[0m^[[1;33m[22:04:47 2021/09/09 +0000] [WARN] LIsten_WG_API:
userspace wireguard device API interface closed, error while accepting
connection, err:fd closed

^[[0m[22:04:47 2021/09/09 +0000] [INFO] .Close: closed userspace
wireguard API interface and device

^[[0m[22:04:47 2021/09/09 +0000] [INFO] CreateWg: create userspace
wireguard device wg1

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR] CreateUSWG: userspace
tunnel interface creation failed, device name wg1, err device or
resource busy

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR] CreateWgfailed to
create wg1: device or resource busy

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR]new Config:device or
resource busy


Plz let me know if I am missing something.

Regards,
Dev

From Jason at zx2c4.com  Sun Sep 12 21:06:56 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sun, 12 Sep 2021 23:06:56 +0200
Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard
 implementation for the Windows kernel
In-Reply-To: <YQgrCfqIL2SWfF6G@zx2c4.com>
References: <YQgrCfqIL2SWfF6G@zx2c4.com>
Message-ID: <CAHmME9ruyCFABTB1S1RYC5CSCBWPr2eqCZDCszDX4NZNR-vi9g@mail.gmail.com>

Hi everyone,

As described in the original announcement:

> There will be three phases of the 0.4.z series:
>
>   Phase 1) WireGuardNT is hidden behind the "ExperimentalKernelDriver"
>            registry knob. If you don't manually tinker around to enable it,
>            the client will continue to use wireguard-go/Wintun like before.
>
>   Phase 2) WireGuardNT is enabled by default and is no longer hidden.
>            However, in case there are late-stage problems that cause
>            downtime for existing infrastructure, there'll be a new hidden
>            knob called "UseUserspaceImplementation" that goes back to
>            using wireguard-go/Wintun like before.
>
>   Phase 3) WireGuardNT is enabled, and wireguard-go/Wintun is removed from
>            the client.

After quite a bit of testing, the bug reports have dried up. We've
gone through several subphases of phase 1, from being masked behind a
registry knob, to introducing a checkbox, to opting in users part of
the Windows Insider program. There's been a pretty heavy amount of
testing, from what I can gather, and I think things have shaped up
nicely.

Finally, tomorrow with the release of v0.4.8, we will move onto phase
2. That means that WireGuardNT will be on by default. If something
goes wrong, you will still be able to disable it and revert to the
older wireguard-go/Wintun using the "UseUserspaceImplementation"
switch described on this page (as of September 2021; will be removed
in the future):

    https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md

But note that if you /do/ revert to using wireguard-go/Wintun, you
*must* absolutely email team at wireguard.com with details as to why
you've done so, so that if there is a bug, we can fix it. If you do
not do this, it is possible that your bug will never be fixed, and in
a month or so, we'll move onto phase 3, and you will lose the ability
to revert to using wireguard-go/Wintun. Do not rely on other people to
report your bug for you; Windows is weird and diverse and there are no
guarantees that somebody else will run into your same problem. So
please: if you enable "UseUserspaceImplementation", send an email
saying why.

Depending on how Monday morning goes, this should be released in
around 12 hours from now. Enjoy!

Regards,
Jason

From noloader at gmail.com  Sun Sep 12 21:54:05 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 12 Sep 2021 17:54:05 -0400
Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard
 implementation for the Windows kernel
In-Reply-To: <CAHmME9ruyCFABTB1S1RYC5CSCBWPr2eqCZDCszDX4NZNR-vi9g@mail.gmail.com>
References: <YQgrCfqIL2SWfF6G@zx2c4.com>
 <CAHmME9ruyCFABTB1S1RYC5CSCBWPr2eqCZDCszDX4NZNR-vi9g@mail.gmail.com>
Message-ID: <CAH8yC8=m72gvv3U-mbs5ib3eT79m+VNAX9s3muj63mHgoaD7Ew@mail.gmail.com>

Hi Jason,

On Sun, Sep 12, 2021 at 5:11 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> ...
> Finally, tomorrow with the release of v0.4.8, we will move onto phase
> 2. That means that WireGuardNT will be on by default. If something
> goes wrong, you will still be able to disable it and revert to the
> older wireguard-go/Wintun using the "UseUserspaceImplementation"
> switch described on this page (as of September 2021; will be removed
> in the future):
>
>     https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md
>
> But note that if you /do/ revert to using wireguard-go/Wintun, you
> *must* absolutely email team at wireguard.com with details as to why
> you've done so, so that if there is a bug, we can fix it. If you do
> not do this, it is possible that your bug will never be fixed, and in
> a month or so, we'll move onto phase 3, and you will lose the ability
> to revert to using wireguard-go/Wintun. Do not rely on other people to
> report your bug for you; Windows is weird and diverse and there are no
> guarantees that somebody else will run into your same problem. So
> please: if you enable "UseUserspaceImplementation", send an email
> saying why.

One month to move into the next phase may be a bit tight for some
folks. 30 days is probably fine for a developer or standalone
installation, but some organizations cannot move that fast.

I've worked in US Financial and US Federal, and some changes take
longer to approve. Some organizations have processes in place that
require approvals from management. It may take months to get a Change
Control Request approved.

When I worked at Treasury a trivial change could take two or three
months and it required management signoffs and complete testing before
being released to the production network. Nearly everyone dreaded a
Change Control Request.

It may be noteworthy... on Windows OSes, the trend is to move stuff
out of the kernel and into userspace to reduce risk. For example,
Microsoft moved parts of the GDI out of the kernel and into userspace.
So some folks may actually want the userland architecture to reduce
risk.

Jeff

From Jason at zx2c4.com  Mon Sep 13 22:48:16 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 14 Sep 2021 00:48:16 +0200
Subject: [ANNOUNCE] wireguard-tools v1.0.20210914 released 
Message-ID: <20210913224820.A110060F3A@mail.kernel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hello,

A new version, v1.0.20210914, of wireguard-tools has been tagged in the git
repository, containing various required userspace utilities, such as the
wg(8) and wg-quick(8) commands and documentation.

== Changes ==

  * contrib/launchd: fix xml syntax error
  * wg-quick: darwin: account for "link#XX" gateways
  
  Small macOS fixes.
  
  * ipc: add wireguard-nt support
  * ipc: cache windows lookups to avoid O(n^2) with nested lookups
  * ipc: remove windows elevation
  * ipc: windows: don't display disabled adapters
  * ipc: windows: use devpkey instead of nci for name
  
  wg(8) now supports WireGuardNT.
  
  * wg-quick: android: adjust for android 12
  
  Android 12 will ship with WireGuard kernel support for more recent phones,
  which is exciting. This commit makes some changes for 12. Hopefully there'll
  be a non-root userspace in the future.
  
  * wg-quick: openbsd: set DNS with resolvd(8)
  
  OpenBSD now has resolvd(8), so we stop writing /etc/resolv.conf ourselves and
  call `route nameserver` instead.

This release contains commits from: Jason A. Donenfeld, Matt Dunwoodie, Laura 
Hausmann, and Hangbin Liu.

As always, the source is available at https://git.zx2c4.com/wireguard-tools/ and
information about the project is available at https://www.wireguard.com/ .

This release is available in compressed tarball form here:
  https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-1.0.20210914.tar.xz
  SHA2-256: 97ff31489217bb265b7ae850d3d0f335ab07d2652ba1feec88b734bc96bd05ac

A PGP signature of that file decompressed is available here:
  https://git.zx2c4.com/wireguard-tools/snapshot/wireguard-tools-1.0.20210914.tar.asc
  Signing key: AB9942E6D4A4CFC3412620A749FC7012A5DE03AE
  Remember to unxz the tarball before verifying the signature.

If you're a package maintainer, please bump your package version. If you're a
user, the WireGuard team welcomes any and all feedback on this latest version.

Finally, WireGuard development thrives on donations. By popular demand, we
have a webpage for this: https://www.wireguard.com/donations/

Thank you,
Jason Donenfeld


-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmE/1QMQHGphc29uQHp4
MmM0LmNvbQAKCRBJ/HASpd4DrvTkD/9YPIHO9JrbsOJ+4tSfCYcErC1inNy+Tz38
t0wWyEY6xnG5w+HwEFMyG9QU4NpngTosc6UkD4I1tA0oTvUKZpzwhHII1lU0Qbsf
0iP3FMXjbGppSsHJQAIBA0XDcaEN0z63PrVKxbzyFahuAJkrTJkTK2kWiPDBc8kC
0LF235hR7lHp5YjaaonCScTlXwrEsb9infggr5NNwBGtIaOZagwsG76m4+TPePlB
A35OpeYTZFM/+niJoCfVaSsC5HRkqmISC0EFrZ2/MfYrBdnTQ3Grp9SVkuT1+7DO
GaBZGH7QrWerF7WIah48aXiOXPfaEKVaQFnMpt62ZWUfuOO+aOr8hmPsPglhpPWD
8kcYZbOGSdGeTxx4oqhICmYNbQev8BMc6i7+cg5B4c6fjxV6FnJToBfCg7PWq9in
+E4FE6FMhqeeSJxYmp4TVa8mUeHQ91UHgL954gjEkBg7PbMfRFOPvZtzhVlEr5TF
2keS8NgSvvVqdemw4ZdkjKcfWV77VLganpPGcpRNyIJPeKzljYHTaTxVMseaEB+b
75SFUqyo/po7lOBaLdALXhIIPfhY20LFbAdIZKEcGZJVnv8z4rXNTcBCi8GkzbpL
IPPdTSdq/zjpXMzURYrtjDDKuufhwm8ailtklfEp+5R3dD+rnmf9WGw2W0io6ENU
9faeh8o/jg==
=r/+M
-----END PGP SIGNATURE-----

From david at bamsoftware.com  Mon Sep 13 18:07:08 2021
From: david at bamsoftware.com (David Fifield)
Date: Mon, 13 Sep 2021 12:07:08 -0600
Subject: Reports of WireGuard blocking in Russia, September =?utf-8?Q?3?=
 =?utf-8?B?4oCTOCw=?= 2021
Message-ID: <20210913180708.t4u7i4ib7fubsjty@bamsoftware.com>

Last week, between about 2021-09-03 and 2021-09-08, there were reports
of failures to establish WireGuard sessions by some users in Russia. I
have not confirmed these reports personally. Tests by users found
connection failures in some ISPs and not others, and even different
conditions in a single ISP at different times. Self-hosted WireGuard as
well as commercial VPN services were apparently affected.

Discussion is happening (in Russian) in various places:
https://ntc.party/t/vpn/1107/13
https://ntc.party/t/rkn-will-try-to-block-the-following-vpn-services/1022/45
https://ntc.party/t/nordvpn/1249
https://www.opennet.ru/openforum/vsluhforumID3/125174.html#9
https://qna.habr.com/q/1043670

I tried to write a synthesis in English:
https://github.com/net4people/bbs/issues/76#issuecomment-915544316

Of note, Roskomnadzor, the Internet regulator in Russia, has, since
early this year, been implementing a long-term plan to block a list of
VPN services, and giving advance notice to entities such as banks.
WireGuard and OpenVPN are mentioned in a letter sent by the Ministry of
Education and Science on 2021-06-15, later posted to the Roskomsvoboda
Tech Talk Telegram channel.
https://github.com/net4people/bbs/issues/76#issuecomment-868088553

During the same time period as the problems with WireGuard, the Russian
ISP Rostelecom was reportedly blocking various BitTorrent protocols.
https://github.com/net4people/bbs/issues/83
This is potentially significant because a possible pattern for matching
uTP, one of BitTorrent's UDP-based protocols, is `^\x01\x00.+`, which
would also match the first initiator-to-responder message in WireGuard.
The uTP explanation is not fully satisfactory, though, because as I
understand it, users of multiple ISPs were having trouble with
WireGuard, while it was only Rostelecom blocking BitTorrent.

In general the Internet situation in Russia seems especially volatile at
the moment, perhaps because of upcoming elections. A news article about
a one-hour block of certain DNS/DoH/DoT servers that happened on
2021-09-08 incidentally mentions a block of the WireGuard protocol:
https://vc.ru/tech/291648-it-specialisty-zayavili-o-testirovanii-roskomnadzorom-massovoy-blokirovki-publichnyh-dns-servisov-google-i-cloudflare
> ? ????????? ?????????? DNS-???????? Google ? Cloudflare ????? ???????
> ????? Telegram-?????? ??????? ????????? ?????? ?????????? ??????
> ????????. ?? ???????, ??? ????????? ??? ???????????? ? VPN-????????
> WireGuard.
>
> The partial blocking of Google and Cloudflare DNS services was also
> reported on his Telegram channel by Mikhail Klimarev, an expert of the
> Internet Defense Society Mikhail Klimarev. He noted that the WireGuard
> VPN protocol was also completely blocked.

From tech at tootai.net  Tue Sep 14 16:45:15 2021
From: tech at tootai.net (Daniel)
Date: Tue, 14 Sep 2021 18:45:15 +0200
Subject: icmp6 on wireguard iface responded by iface lo
Message-ID: <3c3e142f-99b2-732b-2912-2889d6c09a69@tootai.net>

Hi all,

I use wireguard between 2 Debian11 and face a problem: traffic goes in 
to wireguard interface/ip address but goes out with lo as interface with 
the right ip address

19:23:50.287492 wig0 In IP6 fd99:1234:beef:cafe:fade::7000 > 
fd99:1234:beef:cafe:fade::7fff: ICMP6, echo request, id 18272, seq 5, 
length 64

19:23:50.287509 lo In IP6 fd99:1234:beef:cafe:fade::7fff > 
fd99:1234:beef:cafe:fade::7000: ICMP6, echo reply, id 18272, seq 5, 
length 64

Any clue on this ?

Thanks for your support

Daniel

-- 
Daniel

From tmani at prosimo.io  Tue Sep 14 20:53:22 2021
From: tmani at prosimo.io (Manikandan Thiagarajan)
Date: Tue, 14 Sep 2021 13:53:22 -0700
Subject: Netstat bytes count doesn't match with Wireguard
Message-ID: <DBFC0427-180B-4757-A93A-0D9DECD959EE@prosimo.io>

Hi,

I use the Wireguard Go C API to integrate with my packet tunnel network extension to forward traffic to the WG tunnel on Mac OS. I also use the wgGetConfig() API to get tunnel status information.

During my testing, I noticed some differences between what the netstat -ib reports and what Wireguard reports as rx and tx bytes. Usually the Wireguard numbers are higher than netstat numbers.

Is it normal to see so much difference? Can you be able to provide me some information or point me to a doc on how Wireguard calculates the tx/rx bytes?


Netstat -ib output:
Name  Mtu   Network       Address            Ipkts Ierrs     Ibytes    Opkts Oerrs     Obytes  Coll
utun2 1420  <Link#23>                          130     0      42713      180     0      15245     0
utun2 1420  100.101.113.5 100.101.113.54       130     -      42713      180     -      15245     -

Wireguard output:
last_handshake_time_sec=1631646164
last_handshake_time_nsec=79839000
tx_bytes=21328
rx_bytes=47980
persistent_keepalive_interval=0
allowed_ip=155.2.135.28/32
allowed_ip=192.168.128.4/32

Thanks,
Mani

From me at aaronmdjones.net  Wed Sep 15 07:31:32 2021
From: me at aaronmdjones.net (Aaron Jones)
Date: Wed, 15 Sep 2021 07:31:32 +0000
Subject: Netstat bytes count doesn't match with Wireguard
In-Reply-To: <DBFC0427-180B-4757-A93A-0D9DECD959EE@prosimo.io>
References: <DBFC0427-180B-4757-A93A-0D9DECD959EE@prosimo.io>
Message-ID: <2876f8bc-9aae-31b6-3f53-97d8c95603a9@aaronmdjones.net>

Hello.

Netstat is only counting traffic sent or received on the interface; e.g.
the tunnelled bytes themselves, as it should. WireGuard however is
counting that, plus all of the encapsulation overhead (header, MAC,
etc), plus packets not sending or receiving tunnelled data (for example,
keep-alives and periodic re-handshaking), plus periodic response packets
when traffic is only flowing one way (common if you run unidirectional
protocols over it; for example, UDP video streaming).

These extra packets are documented in the WireGuard whitepaper on the
website.

Regards,
Aaron Jones

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210915/7a994c59/attachment.sig>

From tech at tootai.net  Wed Sep 15 08:13:34 2021
From: tech at tootai.net (Daniel)
Date: Wed, 15 Sep 2021 10:13:34 +0200
Subject: icmp6 on wireguard iface responded by iface lo
In-Reply-To: <3c3e142f-99b2-732b-2912-2889d6c09a69@tootai.net>
References: <3c3e142f-99b2-732b-2912-2889d6c09a69@tootai.net>
Message-ID: <db59a485-c736-9750-9b6b-773b43fa4325@tootai.net>

Hi

Le 14/09/2021 ? 18:45, Daniel a ?crit?:
> Hi all,
>
> I use wireguard between 2 Debian11 and face a problem: traffic goes in 
> to wireguard interface/ip address but goes out with lo as interface 
> with the right ip address
>
> 19:23:50.287492 wig0 In IP6 fd99:1234:beef:cafe:fade::7000 > 
> fd99:1234:beef:cafe:fade::7fff: ICMP6, echo request, id 18272, seq 5, 
> length 64
>
> 19:23:50.287509 lo In IP6 fd99:1234:beef:cafe:fade::7fff > 
> fd99:1234:beef:cafe:fade::7000: ICMP6, echo reply, id 18272, seq 5, 
> length 64
>
> Any clue on this ?

Problem is in kernel vue of routing

ip route get fd99:1234:beef:cafe:fade::7000 from 
fd99:1234:beef:cafe:fade::7fff
anycast fd99:1234:beef:cafe:fade::7000 from 
fd99:1234:beef:cafe:fade::7fff dev lo table local proto kernel src 
fd99:1234:beef:cafe:fade::7fff metric 0 pref medium

After

ip route replace fd99:1234:beef:cafe:fade::7000 from 
fd99:1234:beef:cafe:fade::7fff dev wig0 table local

evrything is going back to normal behavior.

Thanks for your support

-- 
Daniel

From dv.lnh.d at gmail.com  Thu Sep 16 09:32:34 2021
From: dv.lnh.d at gmail.com (=?UTF-8?Q?David_L=C3=B6nnhager?=)
Date: Thu, 16 Sep 2021 11:32:34 +0200
Subject: WireGuardNT: Tunnels cannot be "nested"
In-Reply-To: <CAFiEPQu-w-ZX-TMiriGpK2h4_WSGs+5mzq_5PbhbjK1yyncCbA@mail.gmail.com>
References: <CAFiEPQu-w-ZX-TMiriGpK2h4_WSGs+5mzq_5PbhbjK1yyncCbA@mail.gmail.com>
Message-ID: <CAFiEPQuqzyfQgViE5X4NfimPrcXA6Pk-rm7g8jTrM0e8dqVDfA@mail.gmail.com>

The patch below does what I want, though I suspect it has problems. Effectively,
it aims to bind the endpoint socket implicitly instead of performing a
route lookup
manually. I expected that not setting IP_PKTINFO after some route change could
cause it to not rebind the socket correctly, but it doesn't seem to
have that problem.
Feedback would be appreciated.

Expanding on my older comment slightly, what we want is for an
endpoint to connect
inside the tunnel *if no other route can be used*. With wireguard-go and other
implementations, we are able to do this by dropping traffic going
outside the tunnel
using WFP (or nftables), and adding a route for the tunnel interface
to that endpoint.
This way we can create "multihop" tunnels. wireguard-nt simply ignores
this route.

Code for reproducing the issue can be provided if it would be helpful.

David

---
driver/peer.h | 1 -
driver/socket.c | 172 ++++++++++++------------------------------------
2 files changed, 41 insertions(+), 132 deletions(-)

diff --git a/driver/peer.h b/driver/peer.h
index d5d14d7..27a81e9 100644
--- a/driver/peer.h
+++ b/driver/peer.h
@@ -33,7 +33,6 @@ typedef struct _ENDPOINT
};
};
UINT32 RoutingGeneration;
- UINT32 UpdateGeneration;
} ENDPOINT;
typedef enum _HANDSHAKE_TX_ACTION
diff --git a/driver/socket.c b/driver/socket.c
index 11e402b..854ec65 100644
--- a/driver/socket.c
+++ b/driver/socket.c
@@ -173,114 +173,6 @@ CidrMaskMatchV6(_In_ CONST IN6_ADDR *Addr, _In_
CONST IP_ADDRESS_PREFIX *Prefix)
((UINT32 *)&Prefix->Prefix.Ipv6.sin6_addr)[WholeParts];
}
-_IRQL_requires_max_(PASSIVE_LEVEL)
-_IRQL_raises_(DISPATCH_LEVEL)
-_Acquires_shared_lock_(Peer->EndpointLock)
-_Requires_lock_not_held_(Peer->EndpointLock)
-static NTSTATUS
-SocketResolvePeerEndpoint(_Inout_ WG_PEER *Peer, _Out_ _At_(*Irql,
_IRQL_saves_) KIRQL *Irql)
-{
- *Irql = ExAcquireSpinLockShared(&Peer->EndpointLock);
-retryWhileHoldingSharedLock:
- if ((Peer->Endpoint.Addr.si_family == AF_INET &&
- Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV4) &&
- Peer->Endpoint.Src4.ipi_ifindex && Peer->Endpoint.Src4.ipi_ifindex
!= Peer->Device->InterfaceIndex) ||
- (Peer->Endpoint.Addr.si_family == AF_INET6 &&
- Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV6) &&
- Peer->Endpoint.Src6.ipi6_ifindex && Peer->Endpoint.Src6.ipi6_ifindex
!= Peer->Device->InterfaceIndex))
- return STATUS_SUCCESS;
-
- SOCKADDR_INET Addr;
- UINT32 UpdateGeneration = Peer->Endpoint.UpdateGeneration;
- RtlCopyMemory(&Addr, &Peer->Endpoint.Addr, sizeof(Addr));
- ExReleaseSpinLockShared(&Peer->EndpointLock, *Irql);
- SOCKADDR_INET SrcAddr = { 0 };
- ULONG BestIndex = 0, BestCidr = 0, BestMetric = ~0UL;
- NET_LUID BestLuid = { 0 };
- MIB_IPFORWARD_TABLE2 *Table;
- NTSTATUS Status = GetIpForwardTable2(Addr.si_family, &Table);
- if (!NT_SUCCESS(Status))
- return Status;
- union
- {
- MIB_IF_ROW2 Interface;
- MIB_IPINTERFACE_ROW IpInterface;
- } *If = MemAllocate(sizeof(*If));
- if (!If)
- return STATUS_INSUFFICIENT_RESOURCES;
- for (ULONG i = 0; i < Table->NumEntries; ++i)
- {
- if (Table->Table[i].InterfaceLuid.Value == Peer->Device->InterfaceLuid.Value)
- continue;
- if (Table->Table[i].DestinationPrefix.PrefixLength < BestCidr)
- continue;
- if (Addr.si_family == AF_INET &&
!CidrMaskMatchV4(&Addr.Ipv4.sin_addr,
&Table->Table[i].DestinationPrefix))
- continue;
- if (Addr.si_family == AF_INET6 &&
!CidrMaskMatchV6(&Addr.Ipv6.sin6_addr,
&Table->Table[i].DestinationPrefix))
- continue;
- If->Interface = (MIB_IF_ROW2){ .InterfaceLuid =
Table->Table[i].InterfaceLuid };
- if (!NT_SUCCESS(GetIfEntry2(&If->Interface)) ||
If->Interface.OperStatus != IfOperStatusUp)
- continue;
- If->IpInterface =
- (MIB_IPINTERFACE_ROW){ .Family = Addr.si_family, .InterfaceLuid =
Table->Table[i].InterfaceLuid };
- if (!NT_SUCCESS(GetIpInterfaceEntry(&If->IpInterface)))
- continue;
- ULONG Metric = Table->Table[i].Metric + If->IpInterface.Metric;
- if (Table->Table[i].DestinationPrefix.PrefixLength == BestCidr &&
Metric > BestMetric)
- continue;
- BestCidr = Table->Table[i].DestinationPrefix.PrefixLength;
- BestMetric = Metric;
- BestIndex = Table->Table[i].InterfaceIndex;
- BestLuid = Table->Table[i].InterfaceLuid;
- }
- MemFree(If);
- if (Table->NumEntries && BestIndex)
- Status = GetBestRoute2(&BestLuid, 0, NULL, &Addr, 0,
&Table->Table[0], &SrcAddr);
- FreeMibTable(Table);
- if (!BestIndex)
- return STATUS_BAD_NETWORK_PATH;
- if (!NT_SUCCESS(Status))
- return Status;
-
- *Irql = ExAcquireSpinLockExclusive(&Peer->EndpointLock);
- if (UpdateGeneration != Peer->Endpoint.UpdateGeneration)
- {
- ExReleaseSpinLockExclusiveFromDpcLevel(&Peer->EndpointLock);
- ExAcquireSpinLockSharedAtDpcLevel(&Peer->EndpointLock);
- goto retryWhileHoldingSharedLock;
- }
- if (Peer->Endpoint.Addr.si_family == AF_INET)
- {
- Peer->Endpoint.Cmsg.cmsg_len = WSA_CMSG_LEN(sizeof(Peer->Endpoint.Src4));
- Peer->Endpoint.Cmsg.cmsg_level = IPPROTO_IP;
- Peer->Endpoint.Cmsg.cmsg_type = IP_PKTINFO;
- Peer->Endpoint.Src4.ipi_addr = SrcAddr.Ipv4.sin_addr;
- Peer->Endpoint.Src4.ipi_ifindex = BestIndex;
- Peer->Endpoint.CmsgHack4.cmsg_len = WSA_CMSG_LEN(0);
- Peer->Endpoint.CmsgHack4.cmsg_level = IPPROTO_IP;
- Peer->Endpoint.CmsgHack4.cmsg_type = IP_OPTIONS;
- Peer->Endpoint.RoutingGeneration = ReadNoFence(&RoutingGenerationV4);
- }
- else if (Peer->Endpoint.Addr.si_family == AF_INET6)
- {
- Peer->Endpoint.Cmsg.cmsg_len = WSA_CMSG_LEN(sizeof(Peer->Endpoint.Src6));
- Peer->Endpoint.Cmsg.cmsg_level = IPPROTO_IPV6;
- Peer->Endpoint.Cmsg.cmsg_type = IPV6_PKTINFO;
- Peer->Endpoint.Src6.ipi6_addr = SrcAddr.Ipv6.sin6_addr;
- Peer->Endpoint.Src6.ipi6_ifindex = BestIndex;
- Peer->Endpoint.CmsgHack6.cmsg_len = WSA_CMSG_LEN(0);
- Peer->Endpoint.CmsgHack6.cmsg_level = IPPROTO_IPV6;
- Peer->Endpoint.CmsgHack6.cmsg_type = IPV6_RTHDR;
- Peer->Endpoint.RoutingGeneration = ReadNoFence(&RoutingGenerationV6);
- }
- ++Peer->Endpoint.UpdateGeneration, ++UpdateGeneration;
- ExReleaseSpinLockExclusiveFromDpcLevel(&Peer->EndpointLock);
- ExAcquireSpinLockSharedAtDpcLevel(&Peer->EndpointLock);
- if (Peer->Endpoint.UpdateGeneration != UpdateGeneration)
- goto retryWhileHoldingSharedLock;
- return STATUS_SUCCESS;
-}
-
#pragma warning(suppress : 28194) /* `Nbl` is aliased in Ctx->Nbl or
freed on failure. */
#pragma warning(suppress : 28167) /* IRQL is either not raised on
SocketResolvePeerEndpoint failure, or \
restored by ExReleaseSpinLockShared */
@@ -320,10 +212,7 @@ SocketSendNblsToPeer(WG_PEER *Peer,
NET_BUFFER_LIST *First, BOOLEAN *AllKeepaliv
Ctx->Wg = Peer->Device;
IoInitializeIrp(&Ctx->Irp, sizeof(Ctx->IrpBuffer), 1);
IoSetCompletionRoutine(&Ctx->Irp, NblSendComplete, Ctx, TRUE, TRUE, TRUE);
- KIRQL Irql;
- Status = SocketResolvePeerEndpoint(Peer, &Irql);
- if (!NT_SUCCESS(Status))
- goto cleanupCtx;
+ KIRQL Irql = ExAcquireSpinLockShared(&Peer->EndpointLock);
SOCKET *Socket = NULL;
RcuReadLockAtDpcLevel();
if (Peer->Endpoint.Addr.si_family == AF_INET)
@@ -340,13 +229,24 @@ SocketSendNblsToPeer(WG_PEER *Peer,
NET_BUFFER_LIST *First, BOOLEAN *AllKeepaliv
if (NoWskSendMessages)
WskSendMessages = PolyfilledWskSendMessages;
#endif
+ ULONG CmsgLen = 0;
+ WSACMSGHDR *Cmsg = NULL;
+ if ((Peer->Endpoint.Addr.si_family == AF_INET &&
+ Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV4) &&
+ Peer->Endpoint.Src4.ipi_ifindex) ||
+ (Peer->Endpoint.Addr.si_family == AF_INET6 &&
+ Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV6) &&
+ Peer->Endpoint.Src6.ipi6_ifindex)) {
+ CmsgLen = (ULONG)WSA_CMSGDATA_ALIGN(Peer->Endpoint.Cmsg.cmsg_len) +
WSA_CMSG_SPACE(0);
+ Cmsg = &Peer->Endpoint.Cmsg;
+ }
Status = WskSendMessages(
Socket->Sock,
FirstWskBuf,
0,
(PSOCKADDR)&Peer->Endpoint.Addr,
- (ULONG)WSA_CMSGDATA_ALIGN(Peer->Endpoint.Cmsg.cmsg_len) + WSA_CMSG_SPACE(0),
- &Peer->Endpoint.Cmsg,
+ CmsgLen,
+ Cmsg,
&Ctx->Irp);
RcuReadUnlockFromDpcLevel();
ExReleaseSpinLockShared(&Peer->EndpointLock, Irql);
@@ -364,7 +264,6 @@ SocketSendNblsToPeer(WG_PEER *Peer,
NET_BUFFER_LIST *First, BOOLEAN *AllKeepaliv
cleanupRcuLock:
RcuReadUnlockFromDpcLevel();
ExReleaseSpinLockShared(&Peer->EndpointLock, Irql);
-cleanupCtx:
ExFreeToLookasideListEx(&SocketSendCtxCache, Ctx);
cleanupNbls:
FreeSendNetBufferList(Peer->Device, First, 0);
@@ -390,10 +289,7 @@ SocketSendBufferToPeer(WG_PEER *Peer, CONST VOID
*Buffer, ULONG Len)
Ctx->Wg = Peer->Device;
IoInitializeIrp(&Ctx->Irp, sizeof(Ctx->IrpBuffer), 1);
IoSetCompletionRoutine(&Ctx->Irp, BufferSendComplete, Ctx, TRUE, TRUE, TRUE);
- KIRQL Irql;
- Status = SocketResolvePeerEndpoint(Peer, &Irql);
- if (!NT_SUCCESS(Status))
- goto cleanupMdl;
+ KIRQL Irql = ExAcquireSpinLockShared(&Peer->EndpointLock);
SOCKET *Socket = NULL;
RcuReadLockAtDpcLevel();
if (Peer->Endpoint.Addr.si_family == AF_INET)
@@ -405,14 +301,25 @@ SocketSendBufferToPeer(WG_PEER *Peer, CONST VOID
*Buffer, ULONG Len)
Status = STATUS_NETWORK_UNREACHABLE;
goto cleanupRcuLock;
}
+ ULONG CmsgLen = 0;
+ WSACMSGHDR *Cmsg = NULL;
+ if ((Peer->Endpoint.Addr.si_family == AF_INET &&
+ Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV4) &&
+ Peer->Endpoint.Src4.ipi_ifindex) ||
+ (Peer->Endpoint.Addr.si_family == AF_INET6 &&
+ Peer->Endpoint.RoutingGeneration ==
(UINT32)ReadNoFence(&RoutingGenerationV6) &&
+ Peer->Endpoint.Src6.ipi6_ifindex)) {
+ CmsgLen = (ULONG)WSA_CMSGDATA_ALIGN(Peer->Endpoint.Cmsg.cmsg_len) +
WSA_CMSG_SPACE(0);
+ Cmsg = &Peer->Endpoint.Cmsg;
+ }
Status = ((WSK_PROVIDER_DATAGRAM_DISPATCH *)Socket->Sock->Dispatch)
->WskSendTo(
Socket->Sock,
&Ctx->Buffer,
0,
(PSOCKADDR)&Peer->Endpoint.Addr,
- (ULONG)WSA_CMSGDATA_ALIGN(Peer->Endpoint.Cmsg.cmsg_len) + WSA_CMSG_SPACE(0),
- &Peer->Endpoint.Cmsg,
+ CmsgLen,
+ Cmsg,
&Ctx->Irp);
RcuReadUnlockFromDpcLevel();
ExReleaseSpinLockShared(&Peer->EndpointLock, Irql);
@@ -423,7 +330,6 @@ SocketSendBufferToPeer(WG_PEER *Peer, CONST VOID
*Buffer, ULONG Len)
cleanupRcuLock:
RcuReadUnlockFromDpcLevel();
ExReleaseSpinLockShared(&Peer->EndpointLock, Irql);
-cleanupMdl:
MemFreeDataAndMdlChain(Ctx->Buffer.Mdl);
cleanupCtx:
ExFreeToLookasideListEx(&SocketSendCtxCache, Ctx);
@@ -452,9 +358,6 @@ SocketSendBufferAsReplyToNbl(WG_DEVICE *Wg, CONST
NET_BUFFER_LIST *InNbl, CONST
if (!NT_SUCCESS(Status))
goto cleanupMdl;
Status = STATUS_BAD_NETWORK_PATH;
- if ((Endpoint.Addr.si_family == AF_INET && Endpoint.Src4.ipi_ifindex
== Wg->InterfaceIndex) ||
- (Endpoint.Addr.si_family == AF_INET6 && Endpoint.Src6.ipi6_ifindex
== Wg->InterfaceIndex))
- goto cleanupMdl;
KIRQL Irql = RcuReadLock();
SOCKET *Socket = NULL;
if (Endpoint.Addr.si_family == AF_INET)
@@ -466,14 +369,25 @@ SocketSendBufferAsReplyToNbl(WG_DEVICE *Wg,
CONST NET_BUFFER_LIST *InNbl, CONST
Status = STATUS_NETWORK_UNREACHABLE;
goto cleanupRcuLock;
}
+ ULONG CmsgLen = 0;
+ WSACMSGHDR *Cmsg = NULL;
+ if ((Endpoint.Addr.si_family == AF_INET &&
+ Endpoint.RoutingGeneration == (UINT32)ReadNoFence(&RoutingGenerationV4) &&
+ Endpoint.Src4.ipi_ifindex) ||
+ (Endpoint.Addr.si_family == AF_INET6 &&
+ Endpoint.RoutingGeneration == (UINT32)ReadNoFence(&RoutingGenerationV6) &&
+ Endpoint.Src6.ipi6_ifindex)) {
+ CmsgLen = (ULONG)WSA_CMSGDATA_ALIGN(Endpoint.Cmsg.cmsg_len) +
WSA_CMSG_SPACE(0);
+ Cmsg = &Endpoint.Cmsg;
+ }
Status = ((WSK_PROVIDER_DATAGRAM_DISPATCH *)Socket->Sock->Dispatch)
->WskSendTo(
Socket->Sock,
&Ctx->Buffer,
0,
(PSOCKADDR)&Endpoint.Addr,
- (ULONG)WSA_CMSGDATA_ALIGN(Endpoint.Cmsg.cmsg_len) + WSA_CMSG_SPACE(0),
- &Endpoint.Cmsg,
+ CmsgLen,
+ Cmsg,
&Ctx->Irp);
RcuReadUnlock(Irql);
return Status;
@@ -600,7 +514,6 @@ SocketSetPeerEndpoint(WG_PEER *Peer, CONST
ENDPOINT *Endpoint)
if (Endpoint->Addr.si_family == AF_INET)
{
Peer->Endpoint.Addr.Ipv4 = Endpoint->Addr.Ipv4;
- if (Endpoint->Src4.ipi_ifindex != Peer->Device->InterfaceIndex)
{
Peer->Endpoint.Cmsg = Endpoint->Cmsg;
Peer->Endpoint.Src4 = Endpoint->Src4;
@@ -610,7 +523,6 @@ SocketSetPeerEndpoint(WG_PEER *Peer, CONST
ENDPOINT *Endpoint)
else if (Endpoint->Addr.si_family == AF_INET6)
{
Peer->Endpoint.Addr.Ipv6 = Endpoint->Addr.Ipv6;
- if (Endpoint->Src6.ipi6_ifindex != Peer->Device->InterfaceIndex)
{
Peer->Endpoint.Cmsg = Endpoint->Cmsg;
Peer->Endpoint.Src6 = Endpoint->Src6;
@@ -620,7 +532,6 @@ SocketSetPeerEndpoint(WG_PEER *Peer, CONST
ENDPOINT *Endpoint)
else
goto out;
Peer->Endpoint.RoutingGeneration = Endpoint->RoutingGeneration;
- ++Peer->Endpoint.UpdateGeneration;
out:
ExReleaseSpinLockExclusive(&Peer->EndpointLock, Irql);
}
@@ -643,7 +554,6 @@ SocketClearPeerEndpointSrc(WG_PEER *Peer)
Irql = ExAcquireSpinLockExclusive(&Peer->EndpointLock);
Peer->Endpoint.RoutingGeneration = 0;
- ++Peer->Endpoint.UpdateGeneration;
RtlZeroMemory(&Peer->Endpoint.Src6, sizeof(Peer->Endpoint.Src6));
ExReleaseSpinLockExclusive(&Peer->EndpointLock, Irql);
}
-- 
2.31.1

From Jason at zx2c4.com  Sat Sep 18 00:27:15 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 17 Sep 2021 18:27:15 -0600
Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard
 implementation for the Windows kernel
In-Reply-To: <CAH8yC8=m72gvv3U-mbs5ib3eT79m+VNAX9s3muj63mHgoaD7Ew@mail.gmail.com>
References: <YQgrCfqIL2SWfF6G@zx2c4.com>
 <CAHmME9ruyCFABTB1S1RYC5CSCBWPr2eqCZDCszDX4NZNR-vi9g@mail.gmail.com>
 <CAH8yC8=m72gvv3U-mbs5ib3eT79m+VNAX9s3muj63mHgoaD7Ew@mail.gmail.com>
Message-ID: <CAHmME9pvZ=Sj25cMJKQi+JH-PPN5AiiVSWe0eLnxVRSDtpDa+Q@mail.gmail.com>

Hello Jeff,

On Sun, Sep 12, 2021 at 3:55 PM Jeffrey Walton <noloader at gmail.com> wrote:
> One month to move into the next phase may be a bit tight for some
> folks. 30 days is probably fine for a developer or standalone
> installation, but some organizations cannot move that fast.
>
> I've worked in US Financial and US Federal, and some changes take
> longer to approve. Some organizations have processes in place that
> require approvals from management. It may take months to get a Change
> Control Request approved.
>
> When I worked at Treasury a trivial change could take two or three
> months and it required management signoffs and complete testing before
> being released to the production network. Nearly everyone dreaded a
> Change Control Request.

I'm not sure I really follow this line of reasoning here. You've
divided the into two categories:
A) "a developer or standalone installation" that is presumably
frequently upgrading in order to have the latest in greatest.
B) "US Financial and US Federal" and similar organizations for whom
changes require extensive paperwork and reliability testing.

For group (A), the gradual three phase rollout outlined in the initial
email works very well, as it means each component gets an appropriate
amount of testing depending on the phase, with related rollback
controls. It's group (B) that you've raised a concern about. But, if
each change for (B) requires paperwork and reliability testing,
wouldn't _that_ procedure also catch issues? Obviously a downside of
not updating like (A) does is that you miss timely security updates,
but I assume that (B) argues that their slow processes of sign-offs
and testing and paperwork increases reliability and accountability,
which may well be more important for (B). And it would seem that those
processes basically accomplish the same thing as the three phase plan
that's available to group (A) does. So it doesn't seem like anybody is
left out. Unless, of course, all those sign-offs and testing aren't
_actually_ testing anything meaningful, and they're just a Brazilesque
paperwork nightmare, in which case, with regard for neither security
nor reliability, what does it matter either way?

Anyway, there's no exact timeline of precisely 30 days. It will be a
good time after nobody has reported a bug. While products have "go to
market" deadlines, projects have the luxury of being on the "when it's
ready" schedule, which means we don't need to rush. At the same time,
I very much look forward to the reduced maintenance burden of no
longer maintaining duplicate code paths in the wireguard-windows repo.
The jd/remove-wintun branch has a commit that removes about a thousand
lines, which isn't _that_ much, but those are lines that are a bit
stressful in the sense that abstraction layers and duplicated code
paths are common sources of bugs, so they require extra vigilance from
me (and auditors).

> It may be noteworthy... on Windows OSes, the trend is to move stuff
> out of the kernel and into userspace to reduce risk. For example,
> Microsoft moved parts of the GDI out of the kernel and into userspace.
> So some folks may actually want the userland architecture to reduce
> risk.

I don't think it actually makes a practical difference in this case:
the userspace tunnel service retained SeLoadDriverPrivilege so that it
could *unload* Wintun when quitting. Besides, WireGuard was made to be
implemented in operating system kernels; figuring out how to do that
in a minimally scary way was an original thrust of the project. Linux,
OpenBSD, FreeBSD, and now NT.

Jason

From strangebrew114 at outlook.com  Sun Sep 19 00:42:41 2021
From: strangebrew114 at outlook.com (Jeff L)
Date: Sun, 19 Sep 2021 00:42:41 +0000
Subject: Android 12 kernel module
Message-ID: <BN7PR13MB22265FBFBE4E7132F8EA6D5992DF9@BN7PR13MB2226.namprd13.prod.outlook.com>

?I recall reading last year that the kernel module had made it into Android 12.  I'm currently using beta 5, with the Wireguard app, but it still reports that it's using the Go userspace backend in the app. 

Does this mean that the kernel module isn't active?  What's the status of the kernel module support in Android 12?  Does support need to be added to the app, or are there other barriers to getting it working?

From s.devanath at gmail.com  Mon Sep 20 17:48:25 2021
From: s.devanath at gmail.com (Devanath S)
Date: Mon, 20 Sep 2021 10:48:25 -0700
Subject: wireguard-go on container-optimized os on GCP
Message-ID: <CADjMg7XK3t21phcS-FfcGXGE_Nc+Sw5b4Ln0-OsN5Lp0GPf8CQ@mail.gmail.com>

Hi All,

I am trying to run wireguard-go (using
"golang.zx2c4.com/wireguard/wgctrl" for configure) on
container-optimized os on GCP and I am facing the below issue. The
same works on ubuntu/centos etc

1) Wireguard device creation and tunnel gets created as required. It
works as expected
2) When the admin wants to delete the wg tunnel interface and recreate
the wg interface.  It gives error "err device or resource busy"

=> To create the tunnel device
tun.CreateTUN(deviceName, mtu).
device.NewDevice(tun, deviceLogger)
=>To delete the tunnel device
func (device *Device) Close()  which is probably calling
tun.tunFile.Close(), to close the FD

----Snippet of the logs, while closing the device and creating again

^[[0m^[[1;33m[22:04:47 2021/09/09 +0000] [WARN] LIsten_WG_API:
userspace wireguard device API interface closed, error while accepting
connection, err:fd closed

^[[0m[22:04:47 2021/09/09 +0000] [INFO] .Close: closed userspace
wireguard API interface and device

^[[0m[22:04:47 2021/09/09 +0000] [INFO] CreateWg: create userspace
wireguard device wg1

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR] CreateUSWG: userspace
tunnel interface creation failed, device name wg1, err device or
resource busy

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR] CreateWgfailed to
create wg1: device or resource busy

^[[0m^[[0;31m[22:04:47 2021/09/09 +0000] [EROR]new Config:device or
resource busy


Plz let me know if I am missing something.

Regards,
Dev

From hsaber at gmail.com  Tue Sep 21 04:26:59 2021
From: hsaber at gmail.com (=?UTF-8?B?2K3Yp9mF2K8g2LXYp9io2LE=?=)
Date: Tue, 21 Sep 2021 08:56:59 +0430
Subject: =?UTF-8?Q?Re=3A_Unexpected_experience_of_site=2Dto=2Dsite_wireguard_?=
 =?UTF-8?Q?tunneling=E2=80=8F=E2=80=8F?=
In-Reply-To: <CAECraRpgfySdLsk_HtW8NSph3B==oX_2fdbJrOnS9vn3MWokwg@mail.gmail.com>
References: <CAECraRrhiAZQfZjSc0Auhby0Z+G0jSfNeapgDnfQ6=NT8p7q5Q@mail.gmail.com>
 <CAECraRro-ZQrZbxBkQg=o1bnWmf1V4C65D0jkdkt2rMCCe+6bg@mail.gmail.com>
 <CADGd2Dp0S5_=bPQDnRsamvraJZ5BeVV1eWh98js3wATXodfQcQ@mail.gmail.com>
 <CAECraRpLYEkAm+g1dg6X9RJLEDx=nOs=gPQvT_CjxwjXSbhDOw@mail.gmail.com>
 <CAECraRra33vTSb3KW_siHrQx3tLSb-boJUQ1=hVDt5Lo6xXcUw@mail.gmail.com>
 <CAECraRpgfySdLsk_HtW8NSph3B==oX_2fdbJrOnS9vn3MWokwg@mail.gmail.com>
Message-ID: <CAECraRqw7tZ12cPgADE=APs0a1LyG7zwPpJYZ+E3DhMhkcohDg@mail.gmail.com>

Dear all,
I have been struggling with this issue for many days but can't even
guess the cause.
John did me a favor and connected to my server to check what's going
on, but he couldn't find it either.
May someone please suggest an idea. I doubt there is a Wireguard bug.
Rgds
Hamed

????? ???? <?hsaber at gmail.com??> ?? ????? ???? ? ??????? ???? ???? ??:?? ????:?
>
> UPDATE:
> During the outage, I ran a simple test to check if both sides have
> access to each other's specified UDP ports, then I found something
> interesting:
> Some 148 bytes length packets are transferred between parties which I
> can't recognize what are them.
> By the way here I copy my test results.
> Anybody can spot what's going on here?
> The middle-node host name which runs wg1 is ir-pp and the exit-note
> (to free internet) which runs wg2 is sf-do:
> (these two parts happened at the same time and are copied from 2
> different servers):
>
> ========================
> root at ir-pp:~# nc -u sf-do 50840
> 123456
> 1234
> 12
> ^C
> root at ir-pp:~# tcpdump 'port 50841'
> dropped privs to tcpdump
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 20:56:57.607342 IP ir-pp.50841 > sf-do.50840: UDP, length 148
> 20:57:01.042471 IP sf-do.43161 > ir-pp.50841: UDP, length 3
> 20:57:02.361827 IP ir-pp.50841 > sf-do.50840: UDP, length 148
> 20:57:03.635754 IP sf-do.43161 > ir-pp.50841: UDP, length 5
> 20:57:06.740922 IP sf-do.43161 > ir-pp.50841: UDP, length 7
> 20:57:07.552305 IP ir-pp.50841 > sf-do.50840: UDP, length 148
> ^C
> 6 packets captured
> 15 packets received by filter
> 0 packets dropped by kernel
> root at ir-pp:~#
>
>
> ========================
> root at sf-do:~# tcpdump 'port 50840'
> dropped privs to tcpdump
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 20:56:09.126958 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> 20:56:14.758974 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> 20:56:18.222814 IP ir-pp.38136 > sf-do.50840: UDP, length 7
> 20:56:20.391041 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> 20:56:22.307488 IP ir-pp.38136 > sf-do.50840: UDP, length 5
> 20:56:24.702590 IP ir-pp.38136 > sf-do.50840: UDP, length 3
> 20:56:25.510985 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> 20:56:30.630917 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> 20:56:35.750965 IP sf-do.50840 > ir-pp.50841: UDP, length 148
> ^C
> 9 packets captured
> 9 packets received by filter
> 0 packets dropped by kernel
> root at sf-do:~# nc -u ir-pp 50841
> 12
> 1234
> 123456
> ^C
> root at sf-do:~#
>
> ????? ???? <?hsaber at gmail.com??> ?? ????? ???? ? ??????? ???? ???? ?:?? ????:?
> >
> > Hi again,
> > Something new happened which makes me more confused.
> > I wrote a small shell-script to check the connection between wg1 and
> > wg2, so whenever it drops, the script restarts the wg1 and everything
> > comes back.
> > Yes yes I don't like this way of addressing issues, but what could I
> > do if no meaningful debug information exists, and I predict that it
> > might be a bug of Wireguard itself?
> > BTW this system worked fine and the anti-censorship VPN chain was up
> > and running till this morning.
> > The connection went down at 7:49 and didn't come back with
> > auto-restart. The process of restarting continued for about 6 minutes,
> > and at last at 7:55 it came back.
> > During the outage I checked both sides and everything seemed fine.
> > Sides could ping the public ip of each other, their wg udp ports were
> > accessible to each other, and even handshake seemed to be finished
> > correctly (using wg-show command) but peers couldn't ping each other.
> > And the most confusing part is everything came back to life without
> > any action from my side. Just after 6 minutes of continuously
> > restarting the wg1 interface!
> > Isn't there a bug? Somebody please help me to debug this problem and
> > find the cause.
> >
> > Here I bring you my shell-script code, and then its related log:
> >
> > -------------------------
> > #!/bin/bash
> >
> > exec >>/var/log/wg-ping 2>&1
> > while true
> > do
> >         connection=$(ping -c 1 10.10.10.1)
> >         time=$(date +%H:%M)
> >         seconds=$(date +%S)
> >         seconds=${seconds#0}
> >         if [[ "$connection" != *"icmp"* ]]; then
> >           echo " "
> >           date
> >           wg-quick down wg1
> >           echo " "
> >           wg-quick up wg1
> >           connection=$(ping -c 1 10.10.10.1)
> >           time=$(date +%T)
> >           if [[ "$connection" != *"icmp"* ]]; then
> >             echo "$time ERROR"
> >           else
> >             echo "$time OK"
> >             echo " "
> >           fi
> >         elif [[ $seconds -lt 5  ]]; then
> >           echo "$time OK"
> >         fi
> >         sleep 5
> > done
> > ===============
> > Sample log of simply restarting the wg1 which makes everything fine
> > (and happens every few hours):
> > -----------------------
> > 01:17 OK
> > 01:18 OK
> > 01:19 OK
> > 01:20 OK
> > 01:21 OK
> > 01:22 OK
> > 01:23 OK
> > 01:24 OK
> > 01:25 OK
> > 01:26 OK
> >
> > Fri Sep  3 01:26:41 +0430 2021
> > [#] ip route del default dev wg1 table middle
> > [#] ip rule del iif wg0 lookup middle
> > [#] ip link delete dev wg1
> >
> > [#] ip link add wg1 type wireguard
> > [#] wg setconf wg1 /dev/fd/63
> > [#] ip -4 address add 10.10.10.2/32 dev wg1
> > [#] ip link set mtu 1420 up dev wg1
> > [#] ip -4 route add 10.10.10.1/32 dev wg1
> > [#] ip route add default dev wg1 table middle
> > [#] ip rule add iif wg0 lookup middle
> > [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> > 01:26:42 OK
> >
> > 01:27 OK
> > 01:28 OK
> > 01:30 OK
> > 01:31 OK
> > 01:32 OK
> > 01:33 OK
> > 01:34 OK
> > =====================================================
> > And the log for the confusing situation I explained:
> > -----------------------
> > 07:45 OK
> > 07:46 OK
> > 07:47 OK
> > 07:48 OK
> > 07:49 OK
> >
> > Fri Sep  3 07:49:42 +0430 2021
> > [#] ip route del default dev wg1 table middle
> > [#] ip rule del iif wg0 lookup middle
> > [#] ip link delete dev wg1
> >
> > [#] ip link add wg1 type wireguard
> > [#] wg setconf wg1 /dev/fd/63
> > [#] ip -4 address add 10.10.10.2/32 dev wg1
> > [#] ip link set mtu 1420 up dev wg1
> > [#] ip -4 route add 10.10.10.1/32 dev wg1
> > [#] ip route add default dev wg1 table middle
> > [#] ip rule add iif wg0 lookup middle
> > [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> > 07:49:53 ERROR
> >
> > Fri Sep  3 07:50:08 +0430 2021
> > [#] ip route del default dev wg1 table middle
> > [#] ip rule del iif wg0 lookup middle
> > [#] ip link delete dev wg1
> >
> > [#] ip link add wg1 type wireguard
> > [#] wg setconf wg1 /dev/fd/63
> > [#] ip -4 address add 10.10.10.2/32 dev wg1
> > [#] ip link set mtu 1420 up dev wg1
> > [#] ip -4 route add 10.10.10.1/32 dev wg1
> > [#] ip route add default dev wg1 table middle
> > [#] ip rule add iif wg0 lookup middle
> > [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> > 07:50:18 ERROR
> >
> > ======
> > LOTS OF RETRY LOGS CROPPED
> > ======
> >
> > Fri Sep  3 07:55:13 +0430 2021
> > [#] ip route del default dev wg1 table middle
> > [#] ip rule del iif wg0 lookup middle
> > [#] ip link delete dev wg1
> >
> > [#] ip link add wg1 type wireguard
> > [#] wg setconf wg1 /dev/fd/63
> > [#] ip -4 address add 10.10.10.2/32 dev wg1
> > [#] ip link set mtu 1420 up dev wg1
> > [#] ip -4 route add 10.10.10.1/32 dev wg1
> > [#] ip route add default dev wg1 table middle
> > [#] ip rule add iif wg0 lookup middle
> > [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> > 07:55:23 ERROR
> >
> > Fri Sep  3 07:55:38 +0430 2021
> > [#] ip route del default dev wg1 table middle
> > [#] ip rule del iif wg0 lookup middle
> > [#] ip link delete dev wg1
> >
> > [#] ip link add wg1 type wireguard
> > [#] wg setconf wg1 /dev/fd/63
> > [#] ip -4 address add 10.10.10.2/32 dev wg1
> > [#] ip link set mtu 1420 up dev wg1
> > [#] ip -4 route add 10.10.10.1/32 dev wg1
> > [#] ip route add default dev wg1 table middle
> > [#] ip rule add iif wg0 lookup middle
> > [#] wg set wg1 peer <public key> allowed-ips 0.0.0.0/0
> > 07:55:39 OK
> >
> > 07:56 OK
> > 07:57 OK
> > 07:58 OK
> > 07:59 OK
> > 08:00 OK
> > ---------------------------------------
> >
> >
> >
> > ????? ???? <?hsaber at gmail.com??> ?? ????? ??????? ? ??????? ???? ????
> > ?:?? ????:?
> > >
> > > -Thanks for reply.
> > > For test reasons, I turned the firewall off on my middle-node server.
> > > But I can't understand how this issue may be related to firewall,
> > > because most of the time it works (and to me it means firewall is Ok),
> > > but sometime for some unknown reason it stops working, which when I
> > > restart the wg1 interface with this command everything comes back to
> > > life:
> > > wg-quick down wg1 && wg-quick up wg1
> > >
> > > BTW here it is the firewall status of middle-node:
> > > ==================
> > > ? firewalld.service - firewalld - dynamic firewall daemon
> > >    Loaded: loaded (/usr/lib/systemd/system/firewalld.service;
> > > disabled; vendor preset: enabled)
> > >    Active: inactive (dead)
> > >      Docs: man:firewalld(1)
> > > -----------------------------------
> > > Chain INPUT (policy ACCEPT)
> > > target     prot opt source               destination
> > >
> > > Chain FORWARD (policy ACCEPT)
> > > target     prot opt source               destination
> > >
> > > Chain OUTPUT (policy ACCEPT)
> > > target     prot opt source               destination
> > > -----------------------------------
> > >
> > > And the firewall status of exit-node:
> > > ====================
> > > Unit firewalld.service could not be found.
> > > ---------------------------
> > > Chain INPUT (policy ACCEPT)
> > > target     prot opt source               destination
> > > ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:50842
> > > ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
> > >
> > > Chain FORWARD (policy ACCEPT)
> > > target     prot opt source               destination
> > > ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> > > ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
> > >
> > > Chain OUTPUT (policy ACCEPT)
> > > target     prot opt source               destination
> > > ---------------------
> > > Regards
> > >
> > > ??John Lauro?? <?johnalauro at gmail.com??> ?? ????? ???????? ? ???????
> > > ???? ???? ??:?? ????:?
> > > >
> > > > Just a guess, but I would be suspicious about connection tracking causing the issue.  What are your firewall rules?
> > > >
> > > > ?On Wed, Sep 1, 2021 at 9:51 AM ????? ?????? <hsaber at gmail.com> wrote:?
> > > >>
> > > >> Dear friends,
> > > >> I have configured 3 wireguard interfaces on 2 servers to act as a
> > > >> chained VPN for me (to bypass the internet censorship in my country),
> > > >> with this schema:
> > > >>
> > > >> client -- wg0 on middle-node -- wg1 on middle node -- wg2 on exit node
> > > >> (to free internet)
> > > >>
> > > >> Everything works fine, but after a while, the connection between wg1
> > > >> and wg2 drops and I can't find the reason. The connection comes back
> > > >> to action by simply switching the wg1 down and up again using
> > > >> wg-quick. And the amazing behaviour is that sometimes the connection
> > > >> comes back to work automatically  after some random time passes,
> > > >> without any actions from my side (sometimes after a few tens of
> > > >> minutes, sometimes after a few hours).
> > > >> When the wg1-wg2 connection is not working, anything else between 2
> > > >> servers (middle-node and exit-node) works fine. I mean I can ping the
> > > >> public IP of each server from another part, but the local wireguard ip
> > > >> of none of them are accessible.
> > > >>
> > > >> I tried to monitor the situation and read the logs but couldn't find
> > > >> what is happening here, so please help!
> > > >>
> > > >> The configuration:
> > > >> ======================
> > > >>
> > > >> client (my mobile phone):
> > > >> -------------------------------------------
> > > >> [Interface]
> > > >> Address = 10.10.20.2/32
> > > >> PrivateKey =  <private key of client>
> > > >> DNS = 10.10.10.1
> > > >>
> > > >> ### Middle Node
> > > >> [Peer]
> > > >> PublicKey =  <public key of wg0>
> > > >> PresharedKey =  <preshared key>
> > > >> AllowedIPs = 0.0.0.0/0
> > > >> Endpoint = middle-node:50842
> > > >> ======================
> > > >>
> > > >> wg0 (in middle-node server):
> > > >> -------------------------------------------
> > > >> [Interface]
> > > >> Address = 10.10.20.1/24
> > > >> ListenPort = 50842
> > > >> PrivateKey =  <private key of wg0>
> > > >>
> > > >> ### Client
> > > >> [Peer]
> > > >> PublicKey =  <public key of client>
> > > >> PresharedKey =  <preshared key>
> > > >> AllowedIPs = 10.10.20.2/32
> > > >> ======================
> > > >>
> > > >> wg1 (again in middle-node server):
> > > >> -------------------------------------------
> > > >> [Interface]
> > > >> Address = 10.10.10.2/32
> > > >> PrivateKey =  <private key of wg1>
> > > >>
> > > >> PostUp = ip route add default dev wg1 table middle
> > > >> PostUp = ip rule add iif wg0 lookup middle
> > > >> PostUp = wg set wg1 peer <publickey of wg2 (in exit-node)> allowed-ips 0.0.0.0/0
> > > >>
> > > >> PreDown = ip route del default dev wg1 table middle
> > > >> PreDown = ip rule del iif wg0 lookup middle
> > > >>
> > > >> ### Exit Node
> > > >> [Peer]
> > > >> PublicKey =  <publickey of wg2 (in exit-node)>
> > > >> PresharedKey =  <preshared key>
> > > >> AllowedIPs = 10.10.10.1/32
> > > >> Endpoint = exit-node:50842
> > > >> PersistentKeepalive = 25
> > > >> ======================
> > > >>
> > > >> wg2 (in exit-node server):
> > > >> -------------------------------------------
> > > >> [Interface]
> > > >> Address = 10.10.10.1/24
> > > >> ListenPort = 50842
> > > >> PrivateKey =  <private key of wg2>
> > > >>
> > > >> PostUp   = iptables -A FORWARD -i eth0 -o wg2 -j ACCEPT
> > > >> PostUp   = iptables -A FORWARD -i wg2 -j ACCEPT
> > > >> PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
> > > >>
> > > >> PostDown = iptables -D FORWARD -i eth0 -o wg2 -j ACCEPT
> > > >> PostDown = iptables -D FORWARD -i wg2 -j ACCEPT
> > > >> PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
> > > >>
> > > >> ### Middle Node
> > > >> [Peer]
> > > >> PublicKey =  <publickey of wg1 (in middle-node)>
> > > >> PresharedKey =  <preshared key>
> > > >> AllowedIPs = 10.0.0.0/8
> > > >> ======================
> > > >> ======================
> > > >> ======================
> > > >>
> > > >> Sample log of dmesg when the wg1-wg2 connection is not working:
> > > >> -------------------------------------------
> > > >> [Wed Sep  1 11:19:32 2021] wireguard: wg1: Sending keepalive packet to
> > > >> peer 12 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:19:44 2021] wireguard: wg0: Sending keepalive packet to
> > > >> peer 8 (~client-ip~:65323)
> > > >> [Wed Sep  1 11:19:44 2021] wireguard: wg1: Receiving keepalive packet
> > > >> from peer 12 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving handshake
> > > >> initiation from peer 8 (~client-ip~:65323)
> > > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Sending handshake response
> > > >> to peer 8 (~client-ip~:65323)
> > > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2867 destroyed for peer 8
> > > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Keypair 2871 created for peer 8
> > > >> [Wed Sep  1 11:20:09 2021] wireguard: wg0: Receiving keepalive packet
> > > >> from peer 8 (~client-ip~:65323)
> > > >> [Wed Sep  1 11:21:19 2021] wireguard: wg0: Sending keepalive packet to
> > > >> peer 8 (~client-ip~:65323)
> > > >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Retrying handshake with
> > > >> peer 12 (~exit-node-ip~:50842) because we stopped hearing back after
> > > >> 15 seconds
> > > >> [Wed Sep  1 11:21:24 2021] wireguard: wg1: Sending handshake
> > > >> initiation to peer 12 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:21:30 2021] wireguard: wg1: Handshake for peer 12
> > > >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> > > >> 2)
> > > >> ======================
> > > >>
> > > >> Sample log of dmesg when the wg1-wg2 connection is coming back using
> > > >> manual restart:
> > > >> -------------------------------------------
> > > >> [Wed Sep  1 11:45:52 2021] wireguard: wg1: Sending handshake
> > > >> initiation to peer 12 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:45:52 2021] wireguard: wg0: Sending keepalive packet to
> > > >> peer 8 (~client-ip~:2335)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Handshake for peer 12
> > > >> (~exit-node-ip~:50842) did not complete after 5 seconds, retrying (try
> > > >> 3)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> > > >> initiation to peer 12 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2878 destroyed for peer 12
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 12
> > > >> (~exit-node-ip~:50842) destroyed
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface destroyed
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Interface created
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Peer 13 created
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending keepalive packet to
> > > >> peer 13 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Sending handshake
> > > >> initiation to peer 13 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Receiving handshake
> > > >> response from peer 13 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:45:58 2021] wireguard: wg1: Keypair 2881 created for peer 13
> > > >> [Wed Sep  1 11:46:12 2021] wireguard: wg0: Receiving keepalive packet
> > > >> from peer 8 (~client-ip~:2335)
> > > >> [Wed Sep  1 11:46:14 2021] wireguard: wg1: Receiving keepalive packet
> > > >> from peer 13 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:46:27 2021] wireguard: wg0: Sending keepalive packet to
> > > >> peer 8 (~client-ip~:2335)
> > > >> [Wed Sep  1 11:46:28 2021] wireguard: wg1: Receiving keepalive packet
> > > >> from peer 13 (~exit-node-ip~:50842)
> > > >> [Wed Sep  1 11:46:52 2021] wireguard: wg1: Receiving keepalive packet
> > > >> from peer 13 (~exit-node-ip~:50842)
> > > >>
> > > >>
> > > >> Thanks in advance for your kind help

From stunnel at attglobal.net  Wed Sep 22 00:23:06 2021
From: stunnel at attglobal.net (Eddie)
Date: Tue, 21 Sep 2021 17:23:06 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
Message-ID: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>

Title says it all.? On both iPhone and iPad.

The configuration names still show, with the slider, but trying to 
activate gives:? Activation failure.? Unable to retrieve tunnel 
information from the saved configuration.

Selecting a tunnel name doesn't show any configuration.

Cheers.

From stunnel at attglobal.net  Wed Sep 22 00:28:41 2021
From: stunnel at attglobal.net (Eddie)
Date: Tue, 21 Sep 2021 17:28:41 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
Message-ID: <4634569d-1f93-3544-90be-c989dd32752b@attglobal.net>

On 9/21/2021 5:23 PM, Eddie wrote:
> Title says it all.? On both iPhone and iPad.
>
> The configuration names still show, with the slider, but trying to 
> activate gives:? Activation failure.? Unable to retrieve tunnel 
> information from the saved configuration.
>
> Selecting a tunnel name doesn't show any configuration.
>
> Cheers.

Quick update.

The log shows:? [APP] Unable to open config from keychain:- 25300

Cheers.

From miguel.arroz at gmail.com  Wed Sep 22 00:45:20 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Tue, 21 Sep 2021 17:45:20 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <4634569d-1f93-3544-90be-c989dd32752b@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <4634569d-1f93-3544-90be-c989dd32752b@attglobal.net>
Message-ID: <257B7EB1-D01F-418E-AE16-F01822BF25B3@gmail.com>

Hi,

  I?m seeing the same problem in the app, but the tunnel does work. Its on-demand flag is set, so maybe the network extension is able to find the item in the keychain, but the app is not.

  Regards,

Miguel Arroz

  

> On Sep 21, 2021, at 5:28 PM, Eddie <stunnel at attglobal.net> wrote:
> 
> On 9/21/2021 5:23 PM, Eddie wrote:
>> Title says it all.  On both iPhone and iPad.
>> 
>> The configuration names still show, with the slider, but trying to activate gives:  Activation failure.  Unable to retrieve tunnel information from the saved configuration.
>> 
>> Selecting a tunnel name doesn't show any configuration.
>> 
>> Cheers.
> 
> Quick update.
> 
> The log shows:  [APP] Unable to open config from keychain:- 25300
> 
> Cheers.


From Jason at zx2c4.com  Wed Sep 22 03:14:00 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 21 Sep 2021 21:14:00 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
Message-ID: <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>

Hi Eddie,

On Tue, Sep 21, 2021 at 6:26 PM Eddie <stunnel at attglobal.net> wrote:
>
> Title says it all.  On both iPhone and iPad.
>
> The configuration names still show, with the slider, but trying to
> activate gives:  Activation failure.  Unable to retrieve tunnel
> information from the saved configuration.
>
> Selecting a tunnel name doesn't show any configuration.

Thanks for the report. I had seen murmurs of this on IRC and Reddit
too. This post [1] mentions that they just get deleted... I'm
decrustifying my Apple setup, updating phones and macOS and Xcode and
will hopefully have a patch out soon enough, and then hopefully not
too rough of a time with the dreaded app store review process. I'm
also CCing Roopesh who might be able to whip something up faster than
me.

Jason

[1] https://www.reddit.com/r/WireGuard/comments/prhb3k/ios_15_released_on_monday/

From me at anatoli.ws  Wed Sep 22 04:04:16 2021
From: me at anatoli.ws (Anatoli)
Date: Wed, 22 Sep 2021 01:04:16 -0300
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
Message-ID: <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>

Hi All,

Same here.

After recreating the tunnel from scratch and activating it, the tunnel is
established, the server sees the handshake, but the iPhone doesn't have any
connectivity, can't connect to anywhere while the tunnel is activated.

After turning it off, internet starts working again.

I guess the problems is not just the configs not being re-imported.

Regards,
Anatoli

On 22/9/21 00:14, Jason A. Donenfeld wrote:
> Hi Eddie,
> 
> On Tue, Sep 21, 2021 at 6:26 PM Eddie <stunnel at attglobal.net> wrote:
>>
>> Title says it all.  On both iPhone and iPad.
>>
>> The configuration names still show, with the slider, but trying to
>> activate gives:  Activation failure.  Unable to retrieve tunnel
>> information from the saved configuration.
>>
>> Selecting a tunnel name doesn't show any configuration.
> 
> Thanks for the report. I had seen murmurs of this on IRC and Reddit
> too. This post [1] mentions that they just get deleted... I'm
> decrustifying my Apple setup, updating phones and macOS and Xcode and
> will hopefully have a patch out soon enough, and then hopefully not
> too rough of a time with the dreaded app store review process. I'm
> also CCing Roopesh who might be able to whip something up faster than
> me.
> 
> Jason
> 
> [1] https://www.reddit.com/r/WireGuard/comments/prhb3k/ios_15_released_on_monday/
> 

From juraj.hilje at gmail.com  Tue Sep 21 10:55:09 2021
From: juraj.hilje at gmail.com (Juraj Hilje)
Date: Tue, 21 Sep 2021 12:55:09 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
Message-ID: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>

If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.

Here are some logs from the moment of this event:
2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
2021-09-20 12:07:26.736732: [NET] Device closing
2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
2021-09-20 12:07:26.753433: [NET] Device closed
2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped

Tested on devices: iOS 14.8, iPadOS 15
WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4

More info on includeAllNetworks option:
https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks

Can someone confirm this issue or point to a possible workaround?
Thanks!

Juraj H.

From hklbj at icloud.com  Tue Sep 21 11:16:39 2021
From: hklbj at icloud.com (Chi Wing Wong)
Date: Tue, 21 Sep 2021 12:16:39 +0100
Subject: Error to compile Wireguard for SUSE LES 15 SP3
In-Reply-To: <204FE162-0DEE-47E2-B345-0DFB5FE20325@icloud.com>
References: <204FE162-0DEE-47E2-B345-0DFB5FE20325@icloud.com>
Message-ID: <A98A7E01-FC85-45C0-9ACD-A02A60866F65@icloud.com>


> Hi,
> 
> I am new to wireguard and tried to install via compiling the latest version (from git) of Wireguard-Linux-compat for my SUSE Linux Enterprise server 15 SP3. However, there are 2 errors prompted during compiling. I have checked the mail archive mentioned about similar issue. However, I could not find the mentioned patch to resolve the error. Could you share any reference for me to tackle it? Many Thanks.
> 
> 
> In file included from <command-line>:0:0:
> /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:1036:20: error: redefinition of ?skb_reset_redirect?
>  static inline void skb_reset_redirect(struct sk_buff *skb)
>                     ^~~~~~~~~~~~~~~~~~
> In file included from /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:870:0,
>                  from <command-line>:0:
> /usr/src/linux-5.3.18-59.19/include/linux/skbuff.h:4543:20: note: previous definition of ?skb_reset_redirect? was h
> ere
>  static inline void skb_reset_redirect(struct sk_buff *skb)
>                     ^~~~~~~~~~~~~~~~~~
> In file included from /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:870:0,
>                  from <command-line>:0:
> /usr/src/linux-5.3.18-59.19/include/linux/skbuff.h:4543:20: note: previous definition of ?skb_reset_redirect? was h
> ere
>  static inline void skb_reset_redirect(struct sk_buff *skb)
> 
> 
> 
> /home/optionmaker/wireguard-linux-compat/src/compat/compat.h: At top level:
> /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:1065:22: error: static declaration of ?ip_tunnel_parse
> _protocol? follows non-static declaration
>  static inline __be16 ip_tunnel_parse_protocol(const struct sk_buff *skb)
>                       ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /usr/src/linux-5.3.18-59.19/include/net/gre.h:6:0,
>                  from /usr/src/linux-5.3.18-59.19/include/linux/netfilter/nf_conntrack_proto_gre.h:5,
>                  from /usr/src/linux-5.3.18-59.19/include/net/netfilter/nf_conntrack.h:23,
>                  from /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:947,
>                  from <command-line>:0:
> /usr/src/linux-5.3.18-59.19/include/net/ip_tunnels.h:294:8: note: previous declaration of ?ip_tunnel_parse_protocol
> ? was here
>  __be16 ip_tunnel_parse_protocol(const struct sk_buff *skb);
>         ^~~~~~~~~~~~~~~~~~~~~~~~
> In file included from /usr/src/linux-5.3.18-59.19/include/net/gre.h:6:0,
>                  from /usr/src/linux-5.3.18-59.19/include/linux/netfilter/nf_conntrack_proto_gre.h:5,
>                  from /usr/src/linux-5.3.18-59.19/include/net/netfilter/nf_conntrack.h:23,
>                  from /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:947,
>                  from <command-line>:0:
> /usr/src/linux-5.3.18-59.19/include/net/ip_tunnels.h:294:8: note: previous declaration of ?ip_tunnel_parse_protocol
> ? was here
>  __be16 ip_tunnel_parse_protocol(const struct sk_buff *skb);
> 
> 
> 
> In file included from <command-line>:0:0:
> /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:1078:32: error: static declaration of ?ip_tunnel_heade
> r_ops? follows non-static declaration
>  static const struct header_ops ip_tunnel_header_ops = { .parse_protocol = ip_tunnel_parse_protocol };
>                                 ^~~~~~~~~~~~~~~~~~~~
> In file included from /usr/src/linux-5.3.18-59.19/include/net/gre.h:6:0,
>                  from /usr/src/linux-5.3.18-59.19/include/linux/netfilter/nf_conntrack_proto_gre.h:5,
>                  from /usr/src/linux-5.3.18-59.19/include/net/netfilter/nf_conntrack.h:23,
>                  from /home/optionmaker/wireguard-linux-compat/src/compat/compat.h:947,
>                  from <command-line>:0:
> /usr/src/linux-5.3.18-59.19/include/net/ip_tunnels.h:293:32: note: previous declaration of ?ip_tunnel_header_ops? w
> as here
>  extern const struct header_ops ip_tunnel_header_ops;
> 
> 
> Regards,
> Wing


From Jason at zx2c4.com  Wed Sep 22 04:50:36 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 21 Sep 2021 22:50:36 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
Message-ID: <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>

Hi,

I'm not able to reproduce the bug quite yet, but I'd like to get a
better idea of what the bug is. Can you confirm that after reimporting
configs into iOS 15, they work just fine? And the issue is just in the
14->15 flow? If this is correct, I see two issues:

1. Something goes wrong with the keychain from 14->15 and the app
loses authorization.

2. When the app can't open a keychain item, it deletes the VPN
profile? Or does it just gray it out? If it's deleting it, that's
wrong; it ought to just remain disabled until it's readable again.

Jason

From Jason at zx2c4.com  Wed Sep 22 05:17:16 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 21 Sep 2021 23:17:16 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
Message-ID: <CAHmME9p1GcTVfFNH67o1xKxTw6VF=ioqBOAnWjES4Hn15GE2JA@mail.gmail.com>

On Tue, Sep 21, 2021 at 10:50 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 2. When the app can't open a keychain item, it deletes the VPN
> profile? Or does it just gray it out? If it's deleting it, that's
> wrong; it ought to just remain disabled until it's readable again.

This is now fixed with https://w-g.pw/l/dteZ

> 1. Something goes wrong with the keychain from 14->15 and the app
> loses authorization.

This I still have no idea about, as I can't reproduce the issue. It
would be useful to know if it's transient, and so the fix to (2) above
basically handles the issue by not blowing away the VPN profile. If
somebody's got a reliable reproduction rig and can build this in
xcode, I'd be interested in feedback here on what's in the master
branch.

Jason

From juraj.hilje at gmail.com  Wed Sep 22 08:55:07 2021
From: juraj.hilje at gmail.com (Juraj Hilje)
Date: Wed, 22 Sep 2021 10:55:07 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
 <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
Message-ID: <CB84BD03-DB8A-4855-94CC-898100C0B97E@gmail.com>

Hey Andrej, thanks for the response!

I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same issue on my end.

I will test the new iOS 15.1 Beta later today and let you know how it goes.

Juraj H.

> On 22.09.2021., at 10:08, Andrej Mihajlov <and at mullvad.net> wrote:
> 
> Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:
> 
> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
> 
> Waiting for the final release of iOS 15.
> 
>> On 21 Sep 2021, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>> 
>> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
>> 
>> Here are some logs from the moment of this event:
>> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>> 2021-09-20 12:07:26.736732: [NET] Device closing
>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
>> 2021-09-20 12:07:26.753433: [NET] Device closed
>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>> 
>> Tested on devices: iOS 14.8, iPadOS 15
>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>> 
>> More info on includeAllNetworks option:
>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>> 
>> Can someone confirm this issue or point to a possible workaround?
>> Thanks!
>> 
>> Juraj H.
> 


From juraj.hilje at gmail.com  Wed Sep 22 13:26:47 2021
From: juraj.hilje at gmail.com (Juraj Hilje)
Date: Wed, 22 Sep 2021 15:26:47 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <9D47F45A-59C7-4FB0-A9F8-2F13A1D4AB1A@mullvad.net>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
 <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
 <CB84BD03-DB8A-4855-94CC-898100C0B97E@gmail.com>
 <9D47F45A-59C7-4FB0-A9F8-2F13A1D4AB1A@mullvad.net>
Message-ID: <E65FFE7D-9BCC-4EEF-9CF0-FA46CE6B9096@gmail.com>

Hi Andrej,

I've tested on iOS/iPadOS 15.1 Beta, and it looks like the issue is fixed there.
Let me know if you can confirm the same on your end.

Cheers,
Juraj H.

> On 22.09.2021., at 10:59, Andrej Mihajlov <and at mullvad.net> wrote:
> 
> Hi Juraj,
> 
> Installing iOS 15 right now. I am gonna test it today too. 
> 
> What stands out to me that, while you have multiple interfaces available, the network monitor still says that the network is unsatisfied. Very odd.
> 
> Cheers,
> Andrej
> 
>> On 22 Sep 2021, at 10:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>> 
>> Hey Andrej, thanks for the response!
>> 
>> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same issue on my end.
>> 
>> I will test the new iOS 15.1 Beta later today and let you know how it goes.
>> 
>> Juraj H.
>> 
>>> On 22.09.2021., at 10:08, Andrej Mihajlov <and at mullvad.net> wrote:
>>> 
>>> Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:
>>> 
>>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>>> 
>>> Waiting for the final release of iOS 15.
>>> 
>>>> On 21 Sep 2021, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>>>> 
>>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
>>>> 
>>>> Here are some logs from the moment of this event:
>>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
>>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
>>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
>>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
>>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>>> 
>>>> Tested on devices: iOS 14.8, iPadOS 15
>>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>>> 
>>>> More info on includeAllNetworks option:
>>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>>> 
>>>> Can someone confirm this issue or point to a possible workaround?
>>>> Thanks!
>>>> 
>>>> Juraj H.
>>> 
>> 
> 


From and at mullvad.net  Wed Sep 22 08:08:46 2021
From: and at mullvad.net (Andrej Mihajlov)
Date: Wed, 22 Sep 2021 10:08:46 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
Message-ID: <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>

Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:

https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616

Waiting for the final release of iOS 15.

> On 21 Sep 2021, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
> 
> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
> 
> Here are some logs from the moment of this event:
> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
> 2021-09-20 12:07:26.736732: [NET] Device closing
> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
> 2021-09-20 12:07:26.753433: [NET] Device closed
> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
> 
> Tested on devices: iOS 14.8, iPadOS 15
> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
> 
> More info on includeAllNetworks option:
> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
> 
> Can someone confirm this issue or point to a possible workaround?
> Thanks!
> 
> Juraj H.


From jeroen at massar.ch  Wed Sep 22 08:19:46 2021
From: jeroen at massar.ch (Jeroen Massar)
Date: Wed, 22 Sep 2021 10:19:46 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
Message-ID: <20076636-54BD-46DF-A4F2-ADD0E559C5F3@massar.ch>

That flag, is a MAJOR privacy improvement.

If "All" really includes "all" networks.

Before, "some" undefined traffic to Apple systems might be routed outside the VPN.

I guess this is so that Apple Private Relay is private, and other VPNs, eg wireguard, can't say "but you still route traffic elsewhere" like before, which would be an unfair advantage.


Thanks Apple Employee X who arranged getting this in! Very very much appreciated!

Greets,
 Jeroen


> On 20210921, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
> 
> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
> 
> Here are some logs from the moment of this event:
> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
> 2021-09-20 12:07:26.736732: [NET] Device closing
> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
> 2021-09-20 12:07:26.753433: [NET] Device closed
> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
> 
> Tested on devices: iOS 14.8, iPadOS 15
> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
> 
> More info on includeAllNetworks option:
> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
> 
> Can someone confirm this issue or point to a possible workaround?
> Thanks!
> 
> Juraj H.


From and at mullvad.net  Wed Sep 22 08:59:20 2021
From: and at mullvad.net (Andrej Mihajlov)
Date: Wed, 22 Sep 2021 10:59:20 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <CB84BD03-DB8A-4855-94CC-898100C0B97E@gmail.com>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
 <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
 <CB84BD03-DB8A-4855-94CC-898100C0B97E@gmail.com>
Message-ID: <9D47F45A-59C7-4FB0-A9F8-2F13A1D4AB1A@mullvad.net>

Hi Juraj,

Installing iOS 15 right now. I am gonna test it today too. 

What stands out to me that, while you have multiple interfaces available, the network monitor still says that the network is unsatisfied. Very odd.

Cheers,
Andrej

> On 22 Sep 2021, at 10:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
> 
> Hey Andrej, thanks for the response!
> 
> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same issue on my end.
> 
> I will test the new iOS 15.1 Beta later today and let you know how it goes.
> 
> Juraj H.
> 
>> On 22.09.2021., at 10:08, Andrej Mihajlov <and at mullvad.net> wrote:
>> 
>> Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:
>> 
>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>> 
>> Waiting for the final release of iOS 15.
>> 
>>> On 21 Sep 2021, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>>> 
>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
>>> 
>>> Here are some logs from the moment of this event:
>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>> 
>>> Tested on devices: iOS 14.8, iPadOS 15
>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>> 
>>> More info on includeAllNetworks option:
>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>> 
>>> Can someone confirm this issue or point to a possible workaround?
>>> Thanks!
>>> 
>>> Juraj H.
>> 
> 


From freyermuth at physik.uni-bonn.de  Wed Sep 22 10:09:06 2021
From: freyermuth at physik.uni-bonn.de (Oliver Freyermuth)
Date: Wed, 22 Sep 2021 12:09:06 +0200
Subject: Windows stuck in boot after WireGuard update (switch to WireGuardNT?)
Message-ID: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>

Dear Jason,

we have observed two cases (laptops, one running Windows 10 Enterprise, the other Windows 10 Pro 2009)
in which Windows got stuck during boot (during the "rotating dots", which keep rotating forever).

This has been observed end of last week for one laptop, and just today for the other affected laptop.
Both systems have installed WireGuard updates "as they were released", i.e. both were running 0.4.9 when the error occured.
Both laptops use BitLocker disk encryption (but I suppose this is not part of the issue).
While both machines are shut down and started up daily, both may not have seen a full reboot until the error occured (thanks to Windows fast startup).

I could revive the systems and pinpoint the issue down to WireGuard as follows:
- Start in "safe mode".
   Note that "safe mode with network drivers" will also get stuck.
- Login with an admin account, and in Device manager, disable or uninstall the following two network adapters:
     WireGuard Tunnel
     Microsoft Kernel Debug Network Adapter (is this also pulled in via WireGuard?)

After that, the laptops reboot fine again, and strangely enough, WireGuard is usable right away (using the WireGuard NT driver).
I tried to provoke the issue when the laptops were in my hand, by enabling / disabling WireGuard, rebooting, shutting down and starting up,
installing all Windows updates which were available, but to no avail.

However, once I returned the first laptop back to the user, it has shown the same issue again ~24 hours later (still running WireGuard 0.4.9).
Of course, since these are laptops, they see many connection state changes, in case this may be a trigger of the issue.

To further pinpoint the issue, I have used:
  reg add HKLM\Software\WireGuard /v UseUserspaceImplementation /t REG_DWORD /d 1 /f
on one of the two laptops, to check if this prevents reappearance of the issue (I ran that only now, so no feedback by the user yet).

Since both are in heavy use by the respective users, I can sadly not keep them for long to do more detailed debugging,
and I have not yet managed to reproduce such an issue with any of our test machines (which are however not laptops).
I've also net yet managed to trigger this on my own Windows 10 laptop, so this may be some kind of very evasive / rare issue.


Does this kind of issue ring any bells?


Cheers,
	Oliver

PS: I am not (yet) subscribed to the list, so pleace CC me in replies. Thanks!


-- 
Oliver Freyermuth
Universit?t Bonn
Physikalisches Institut, Raum 1.047
Nu?allee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--

From Jason at zx2c4.com  Wed Sep 22 13:59:22 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 07:59:22 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAMaqUZ2dTaOJ3oPex0pQxBM9njHA7rW5Hb69MvG645n+ya_jhQ@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <CAHmME9p1GcTVfFNH67o1xKxTw6VF=ioqBOAnWjES4Hn15GE2JA@mail.gmail.com>
 <CAMaqUZ2dTaOJ3oPex0pQxBM9njHA7rW5Hb69MvG645n+ya_jhQ@mail.gmail.com>
Message-ID: <CAHmME9pVUPkbaGDFjxJdUhFqatv7hxkyyOQ7W26LkLnyJqUebA@mail.gmail.com>

Hi Reid,

Thanks for the confirmation. Do you think you (and whoever else is
experiencing this) could send me the logs from the app? You can send
them off list if you're worried about private data in there.

Thanks,
Jason

From freyermuth at physik.uni-bonn.de  Wed Sep 22 14:02:37 2021
From: freyermuth at physik.uni-bonn.de (Oliver Freyermuth)
Date: Wed, 22 Sep 2021 16:02:37 +0200
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
Message-ID: <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>

Hi Jason,

Am 22.09.21 um 15:56 schrieb WireGuard Team:
> Thanks for the report. Could you send a log of the hung machines and
> mention the time at which the hang happened in the log?

which log exactly do you mean, the Windows event log, parts of it, or the logs by Wireguard itself?
The problem is that the hang happens on bootup, before user login (but indeed I was not clever enough to check the WireGuard logs from before the failure).

I tried to boot one of the machines with boot/startup logging (I'm not sure this is the correct English translation, it is one of the options next to safe mode in the WinRE),
and ntbootlog.txt ended during network driver loading.

I don't have the file at hand, but could access this and the WireGuard log hopefully later this week when the affected user is back from travelling.

Cheers,
	Oliver


-- 
Oliver Freyermuth
Universit?t Bonn
Physikalisches Institut, Raum 1.047
Nu?allee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5432 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210922/2943d7af/attachment.p7s>

From noloader at gmail.com  Wed Sep 22 14:41:36 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 22 Sep 2021 10:41:36 -0400
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
 <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
Message-ID: <CAH8yC8mK2-UEzFJ0eqN8XHoXsyESKie7642PcbnN=w7Q6QM6EQ@mail.gmail.com>

On Wed, Sep 22, 2021 at 9:31 AM Andrej Mihajlov <and at mullvad.net> wrote:
>
> Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:
>
> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>
> Waiting for the final release of iOS 15.

I believe Apple released iOS 15 and iPadOS 15 on September 20. Or I
received the security announcements for the release. iOS 15 and iPadOS
15 is APPLE-SA-2021-09-20-1 at
https://lists.apple.com/archives/security-announce/2021/Sep/index.html.

Jeff

From afried at spamteq.com  Wed Sep 22 14:47:07 2021
From: afried at spamteq.com (Andrew Fried)
Date: Wed, 22 Sep 2021 14:47:07 +0000
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9p1GcTVfFNH67o1xKxTw6VF=ioqBOAnWjES4Hn15GE2JA@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <CAHmME9p1GcTVfFNH67o1xKxTw6VF=ioqBOAnWjES4Hn15GE2JA@mail.gmail.com>
Message-ID: <K3323-53.1632322027@spamhaus.org>

I ran into the same problem on my iPhone  and 4 separate iPads.

The solution: delete the wireguard app, then re-download it from the app 
store.  Problem solved.

Andrew


On 9/22/21 1:17 AM, Jason A. Donenfeld wrote:
> On Tue, Sep 21, 2021 at 10:50 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> 2. When the app can't open a keychain item, it deletes the VPN
>> profile? Or does it just gray it out? If it's deleting it, that's
>> wrong; it ought to just remain disabled until it's readable again.
> 
> This is now fixed with https://w-g.pw/l/dteZ
> 
>> 1. Something goes wrong with the keychain from 14->15 and the app
>> loses authorization.
> 
> This I still have no idea about, as I can't reproduce the issue. It
> would be useful to know if it's transient, and so the fix to (2) above
> basically handles the issue by not blowing away the VPN profile. If
> somebody's got a reliable reproduction rig and can build this in
> xcode, I'd be interested in feedback here on what's in the master
> branch.
> 
> Jason
> 

-- 
Andrew Fried
afried at spamteq.com
+1.703.667.4050 Office
+1.703.362.0067 Mobile

From stunnel at attglobal.net  Wed Sep 22 15:23:13 2021
From: stunnel at attglobal.net (Eddie)
Date: Wed, 22 Sep 2021 08:23:13 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
Message-ID: <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>

On 9/21/2021 9:50 PM, Jason A. Donenfeld wrote:
> Hi,
>
> I'm not able to reproduce the bug quite yet, but I'd like to get a
> better idea of what the bug is. Can you confirm that after reimporting
> configs into iOS 15, they work just fine? And the issue is just in the
> 14->15 flow? If this is correct, I see two issues:
I haven't tried re-importing anything yet, in case you needed more 
information before trying that.
> 1. Something goes wrong with the keychain from 14->15 and the app
> loses authorization.
>
> 2. When the app can't open a keychain item, it deletes the VPN
> profile? Or does it just gray it out? If it's deleting it, that's
> wrong; it ought to just remain disabled until it's readable again.
If I select one of the tunnels, all I see on the "Edit" page is the 
status slider and the on demand status.? The section under INTERFACE is 
completely missing.? Selecting Edit brings up the screen you would see 
when creating a new tunnel, with all parameters showing (in grey) 
Required, Automatic, Optional, etc.? There are no values from the 
original configuration shown.
> Jason
>

From miguel.arroz at gmail.com  Wed Sep 22 16:50:29 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 09:50:29 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
Message-ID: <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>

Hi,

  I have two devices upgraded to iOS 15, an iPhone and iPad. Both had a tunnel configured with on-demand set. The behaviour was the same on both: the tunnel worked, but the app couldn?t show information, the exact way Eddie described. When I click the Edit button, I see all the fields blank, and the peer is gone, just like if I was creating a new configuration from scratch.

  I tried the following on the iPhone:

  - Turned the tunnel off using the switch in the app. As soon as it tried to turn itself on again (due to the on-demand flag), it showed an error and the tunnel could not be brought back up (I don?t remember the exact wording of the error alert).
  - I deleted the tunnel configuration, and created one from scratch. Everything is working now. The tunnel works, and the app can read the configuration. I rebooted the iPhone to make sure it could reload everything afterwards, and it did.

  I still have the iPad in the original state.

  The log is essentially a repetition of the following line: "Unable to open config from keychain: -25300?.

  I?m not sure if a local build made by me would help debugging this, as if I recall correctly from the Keychain API, the app group key (kSecAttrAccessGroup) is dependent on the team and bundle IDs (enforced by the code signing and runtime verification process), so I doubt I can build something that will be able to access the keychain that is already there. The only valid test would be building and installing it on iOS 14 and then upgrading to iOS 15, or distributing a beta version using TestFlight using the official team ID.

  Regards,

Miguel Arroz


> On Sep 22, 2021, at 8:23 AM, Eddie <stunnel at attglobal.net> wrote:
> 
> On 9/21/2021 9:50 PM, Jason A. Donenfeld wrote:
>> Hi,
>> 
>> I'm not able to reproduce the bug quite yet, but I'd like to get a
>> better idea of what the bug is. Can you confirm that after reimporting
>> configs into iOS 15, they work just fine? And the issue is just in the
>> 14->15 flow? If this is correct, I see two issues:
> I haven't tried re-importing anything yet, in case you needed more information before trying that.
>> 1. Something goes wrong with the keychain from 14->15 and the app
>> loses authorization.
>> 
>> 2. When the app can't open a keychain item, it deletes the VPN
>> profile? Or does it just gray it out? If it's deleting it, that's
>> wrong; it ought to just remain disabled until it's readable again.
> If I select one of the tunnels, all I see on the "Edit" page is the status slider and the on demand status.  The section under INTERFACE is completely missing.  Selecting Edit brings up the screen you would see when creating a new tunnel, with all parameters showing (in grey) Required, Automatic, Optional, etc.  There are no values from the original configuration shown.
>> Jason
>> 


From Jason at zx2c4.com  Wed Sep 22 18:57:57 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 12:57:57 -0600
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
 <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
Message-ID: <CAHmME9rP1a5XPtHp10_M5=w_ozGysOPYAk-PJ5hhZUCRXCJmQg@mail.gmail.com>

Hi Oliver,

Could you send the wireguard application log, as well as any other
logs you find? Also \windows\inf\setupapi.*.log would help.

Jason

From Jason at zx2c4.com  Wed Sep 22 19:28:36 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 13:28:36 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
Message-ID: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>

Hi all,

I've got a new build submitted to the App Store, and so now we wait
for Apple's review.

I do not understand the root cause or how it might resolve itself yet,
because I haven't been able to reproduce. But I've removed the
ridiculous code that deletes network profiles when the keychain can't
be opened. My hope is that the open failure is transient, and so this
fix will be sufficient to unwedge it. I guess we'll see...

Jason

From joshua.sjoding at scjalliance.com  Wed Sep 22 19:36:52 2021
From: joshua.sjoding at scjalliance.com (Joshua Sjoding)
Date: Wed, 22 Sep 2021 12:36:52 -0700
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9rP1a5XPtHp10_M5=w_ozGysOPYAk-PJ5hhZUCRXCJmQg@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
 <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
 <CAHmME9rP1a5XPtHp10_M5=w_ozGysOPYAk-PJ5hhZUCRXCJmQg@mail.gmail.com>
Message-ID: <CALaUSutA42xfnnpLcNsYvE2-XH0qGA7zUPbYKJJFQE2yq1snYA@mail.gmail.com>

We've seen these symptoms (infinitely spinning dots during bootup) at
least twice in the past week, but hadn't thought to link the behavior
to WireGuard. We had a third case this morning, and I can confirm that
the steps outlined by Oliver got the machine back to a bootable
condition. Thank you Oliver!

Before disabling the devices in Device Manager, we tried disabling the
WireGuard Tunnel service instead, but it still failed to boot.

The laptop that failed today is a Lenovo ThinkBook 15 G2 ITL
(20VE006UUS) laptop running Windows 10 Pro 20H2.
The laptops that failed previously are Lenovo ThinkBook 14s Yoga
2-in-1 (20WE001DUS) laptops.

We collected the WireGuard logs today while still in Safe Mode via
wireguard.exe /dumplog. I'll send those directly to the WireGuard team
off-list. We'll grab the setupapi logs as well when we get a chance
later today.

While this might be an issue with WireGuard for Windows, it's also
possible that the fault lies elsewhere, like a recent Windows update
or some other driver update. Like Oliver, we have BitLocker enabled on
these devices.

Joshua Sjoding
SCJ Alliance
IT Specialist

On Wed, Sep 22, 2021 at 12:00 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Oliver,
>
> Could you send the wireguard application log, as well as any other
> logs you find? Also \windows\inf\setupapi.*.log would help.
>
> Jason

From noloader at gmail.com  Wed Sep 22 19:58:01 2021
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 22 Sep 2021 15:58:01 -0400
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
Message-ID: <CAH8yC8mG6TR76jJOh5fiz7hgCPEkxAZDqGM3L5DTEkwRMU8xpw@mail.gmail.com>

On Wed, Sep 22, 2021 at 3:31 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi all,
>
> I've got a new build submitted to the App Store, and so now we wait
> for Apple's review.
>
> I do not understand the root cause or how it might resolve itself yet,
> because I haven't been able to reproduce. But I've removed the
> ridiculous code that deletes network profiles when the keychain can't
> be opened. My hope is that the open failure is transient, and so this
> fix will be sufficient to unwedge it. I guess we'll see...

I recall reading a report last night... An app lost access to its
keychain items after an iOS 15 upgrade. The workaround was to "Enable
iCloud Keychain".

I don't think that's a good idea, however. You don't want your secrets
leaving your security boundary and moving to Apple's cloud. In fact, I
stopped using Apple devices back around iOS 6 when Apple integrated
the keychain into their cloud services.

Jeff

From Jason at zx2c4.com  Wed Sep 22 22:15:28 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 16:15:28 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
Message-ID: <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>

Hi again,

A new app has been released for both iOS and macOS. Please test it out
and let me know how it goes.

Jason

From me at anatoli.ws  Wed Sep 22 22:24:05 2021
From: me at anatoli.ws (Anatoli)
Date: Wed, 22 Sep 2021 19:24:05 -0300
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
References: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
Message-ID: <B096024B-E199-462E-978C-73B2C1D4C8D2@anatoli.ws>

I can confirm that recreating the tunnel from scratch does work. So the problem is that the tunnel settings become corrupted when iOS is upgraded from 13.x / 14.x to 15.0.

Here are some printscreens of how it looks like (in Spanish):

Tunnel details look this way:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image0.jpeg
Type: image/jpeg
Size: 20223 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210922/9b7f0870/attachment.jpeg>
-------------- next part --------------


When on the previous screen you click Edit, the edit page opens this way:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.jpeg
Type: image/jpeg
Size: 35644 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210922/9b7f0870/attachment-0001.jpeg>
-------------- next part --------------


When you try to activate such a tunnel, you get the error saying: ?Activation failure: it wasn?t possible to recover the tunnel information from the saved configuration?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image2.jpeg
Type: image/jpeg
Size: 25063 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210922/9b7f0870/attachment-0002.jpeg>
-------------- next part --------------



> On 22 Sep 2021, at 16:28, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> ?Hi all,
> 
> I've got a new build submitted to the App Store, and so now we wait
> for Apple's review.
> 
> I do not understand the root cause or how it might resolve itself yet,
> because I haven't been able to reproduce. But I've removed the
> ridiculous code that deletes network profiles when the keychain can't
> be opened. My hope is that the open failure is transient, and so this
> fix will be sufficient to unwedge it. I guess we'll see...
> 
> Jason

From Jason at zx2c4.com  Wed Sep 22 22:26:00 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 16:26:00 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <B096024B-E199-462E-978C-73B2C1D4C8D2@anatoli.ws>
References: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <B096024B-E199-462E-978C-73B2C1D4C8D2@anatoli.ws>
Message-ID: <CAHmME9pjuin565o4Ckmj2rHEhO9bAd4uaGarMA9SAMmP=85_wQ@mail.gmail.com>

On Wed, Sep 22, 2021 at 4:24 PM Anatoli <me at anatoli.ws> wrote:
>
> I can confirm that recreating the tunnel from scratch does work. So the problem is that the tunnel settings become corrupted when iOS is upgraded from 13.x / 14.x to 15.0.

What are you testing? The new version of the app or the old one? Does
the new one corrupt settings or only the old one? Precision is
important here.

From miguel.arroz at gmail.com  Wed Sep 22 22:31:35 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 15:31:35 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
Message-ID: <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>

Hi Jason,

  After the update, when I launch the app on the iPad, the row in the tunnel list has a red background, and the first time I launched it, the switch started switching very quickly between connected and disconnected. Also, nothing at all shows on the right side when I click it (not even the empty sections that were appearing before, it?s just a blank view). The tunnel also got disconnected when I launched the app, and is not connecting any more.

  On the iPhone (where I had already recreated the tunnel), also after the update, everything seems fine.

  Regards,

Miguel Arroz


> On Sep 22, 2021, at 3:15 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Hi again,
> 
> A new app has been released for both iOS and macOS. Please test it out
> and let me know how it goes.
> 
> Jason


From Jason at zx2c4.com  Wed Sep 22 22:35:48 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 16:35:48 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
Message-ID: <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>

Hi Miguel,

On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz <miguel.arroz at gmail.com> wrote:
>   After the update, when I launch the app on the iPad, the row in the tunnel list has a red background, and the first time I launched it, the switch started switching very quickly between connected and disconnected. Also, nothing at all shows on the right side when I click it (not even the empty sections that were appearing before, it?s just a blank view). The tunnel also got disconnected when I launched the app, and is not connecting any more.

Is this on a fresh 14->15 transition? Or had you already loaded the
old version on 15?

The row turns red when it can't open the keychain reference. I'm
curious whether that's because it was already deleted stupidly by the
old version of the app during the 14->15 transition, or whether it's
still there, but the new version of the app on 15 is unable to load
it.

Also, what happens if you twiddle the iCloud keychain setting?

Jason

From miguel.arroz at gmail.com  Wed Sep 22 22:42:14 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 15:42:14 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
Message-ID: <98EE8BF1-3F88-49F1-BEB4-436143FAF294@gmail.com>

Hey Jason,

> On Sep 22, 2021, at 3:35 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Is this on a fresh 14->15 transition? Or had you already loaded the
> old version on 15?
> 
> The row turns red when it can't open the keychain reference. I'm
> curious whether that's because it was already deleted stupidly by the
> old version of the app during the 14->15 transition, or whether it's
> still there, but the new version of the app on 15 is unable to load
> it.

  I already had loaded the old version after installing iOS 15, so it probably was deleted, which is consistent with the red row. Unfortunately I don?t have any other iOS device, only those two that were upgraded to iOS 15 and ran the old Wireguard version already.

> Also, what happens if you twiddle the iCloud keychain setting?

  The behaviour didn?t change, although it probably doesn?t mean anything given the above.

  Regards,

Miguel Arroz

From Jason at zx2c4.com  Wed Sep 22 22:43:26 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 16:43:26 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <98EE8BF1-3F88-49F1-BEB4-436143FAF294@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
 <98EE8BF1-3F88-49F1-BEB4-436143FAF294@gmail.com>
Message-ID: <CAHmME9oe1+xNzvxPQX6ay_abKkGZU-Wzn+z5YQPCm1WgoApAEw@mail.gmail.com>

Hi Miguel,

Gotcha. It is interesting that those red rows weren't wiped out,
though... I would think that with the old code, after two launches,
they'd be removed...

Jason

From stunnel at attglobal.net  Wed Sep 22 22:45:10 2021
From: stunnel at attglobal.net (Eddie)
Date: Wed, 22 Sep 2021 15:45:10 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
Message-ID: <b566bf2d-33c0-2e89-1754-a3b4015ff624@attglobal.net>

On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
> Hi Miguel,
>
> On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz <miguel.arroz at gmail.com> wrote:
>>    After the update, when I launch the app on the iPad, the row in the tunnel list has a red background, and the first time I launched it, the switch started switching very quickly between connected and disconnected. Also, nothing at all shows on the right side when I click it (not even the empty sections that were appearing before, it?s just a blank view). The tunnel also got disconnected when I launched the app, and is not connecting any more.
I see the same red backgrounds and empty details pane.
> Is this on a fresh 14->15 transition? Or had you already loaded the
> old version on 15?
I had already upgraded all my devices, so can't verify the 14->15 upgrade.
> The row turns red when it can't open the keychain reference. I'm
> curious whether that's because it was already deleted stupidly by the
> old version of the app during the 14->15 transition, or whether it's
> still there, but the new version of the app on 15 is unable to load
> it.
>
> Also, what happens if you twiddle the iCloud keychain setting?
Sorry, as much as I like Apple, that's one part I'm not trusting to 
their cloud.
> Jason
>
>


From stunnel at attglobal.net  Wed Sep 22 22:55:11 2021
From: stunnel at attglobal.net (Eddie)
Date: Wed, 22 Sep 2021 15:55:11 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <b566bf2d-33c0-2e89-1754-a3b4015ff624@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
 <b566bf2d-33c0-2e89-1754-a3b4015ff624@attglobal.net>
Message-ID: <061d9137-a5af-a651-9435-db92dc9f53f9@attglobal.net>

On 9/22/2021 3:45 PM, Eddie wrote:
> On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
>> Hi Miguel,
>>
>> On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz <miguel.arroz at gmail.com> 
>> wrote:
>>> ?? After the update, when I launch the app on the iPad, the row in 
>>> the tunnel list has a red background, and the first time I launched 
>>> it, the switch started switching very quickly between connected and 
>>> disconnected. Also, nothing at all shows on the right side when I 
>>> click it (not even the empty sections that were appearing before, 
>>> it?s just a blank view). The tunnel also got disconnected when I 
>>> launched the app, and is not connecting any more.
> I see the same red backgrounds and empty details pane.

Which now means I can't delete the broken tunnels.

>> Is this on a fresh 14->15 transition? Or had you already loaded the
>> old version on 15?
> I had already upgraded all my devices, so can't verify the 14->15 upgrade.
>> The row turns red when it can't open the keychain reference. I'm
>> curious whether that's because it was already deleted stupidly by the
>> old version of the app during the 14->15 transition, or whether it's
>> still there, but the new version of the app on 15 is unable to load
>> it.
>>
>> Also, what happens if you twiddle the iCloud keychain setting?
> Sorry, as much as I like Apple, that's one part I'm not trusting to 
> their cloud.
>> Jason
>>
>>
>
>
> ----------------------------------------------------------------------
> This e-mail was checked for spam by the freeware edition of CleanMail.
> The freeware edition is restricted to personal and non-commercial use.
> You can remove this notice by purchasing a commercial license:
> http://antispam.byteplant.com/products/cleanmail/index.html



From Jason at zx2c4.com  Wed Sep 22 22:55:57 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 16:55:57 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <061d9137-a5af-a651-9435-db92dc9f53f9@attglobal.net>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
 <b566bf2d-33c0-2e89-1754-a3b4015ff624@attglobal.net>
 <061d9137-a5af-a651-9435-db92dc9f53f9@attglobal.net>
Message-ID: <CAHmME9pcj3MJtjxm2nVQUANyND5G3YPh_crT2yoPRjy7jGiubg@mail.gmail.com>

On Wed, Sep 22, 2021 at 4:55 PM Eddie <stunnel at attglobal.net> wrote:
> On 9/22/2021 3:45 PM, Eddie wrote:
> > I see the same red backgrounds and empty details pane.
> Which now means I can't delete the broken tunnels.

What happens when you slide the item over to reveal the delete button
and then press it?

From stunnel at attglobal.net  Wed Sep 22 22:56:57 2021
From: stunnel at attglobal.net (Eddie)
Date: Wed, 22 Sep 2021 15:56:57 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9p5C3bGT=gXV6WQ5HNOBTtitXdGwKm7EaOv_bnVVvX5vA@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <381D3BFE-1437-40F1-B79B-DAF82DE4F7D8@gmail.com>
 <CAHmME9r0xXq8XYJshVEnx0q8Sim7wuJ8gjy=_EszYf4Z020_Fw@mail.gmail.com>
 <b566bf2d-33c0-2e89-1754-a3b4015ff624@attglobal.net>
 <814501e8-c2c8-1e0a-2f30-fd83fb7769ec@attglobal.net>
 <CAHmME9p5C3bGT=gXV6WQ5HNOBTtitXdGwKm7EaOv_bnVVvX5vA@mail.gmail.com>
Message-ID: <dc479512-e2e6-f6f9-3780-9a9b9b5bbc13@attglobal.net>


On 9/22/2021 3:54 PM, Jason A. Donenfeld wrote:
> On Wed, Sep 22, 2021 at 4:53 PM Eddie <stunnel at attglobal.net> wrote:
>> On 9/22/2021 3:45 PM, Eddie wrote:
>>> On 9/22/2021 3:35 PM, Jason A. Donenfeld wrote:
>>>> Hi Miguel,
>>>>
>>>> On Wed, Sep 22, 2021 at 4:31 PM Miguel Arroz <miguel.arroz at gmail.com>
>>>> wrote:
>>>>>     After the update, when I launch the app on the iPad, the row in
>>>>> the tunnel list has a red background, and the first time I launched
>>>>> it, the switch started switching very quickly between connected and
>>>>> disconnected. Also, nothing at all shows on the right side when I
>>>>> click it (not even the empty sections that were appearing before,
>>>>> it?s just a blank view). The tunnel also got disconnected when I
>>>>> launched the app, and is not connecting any more.
>>> I see the same red backgrounds and empty details pane.
>> Which now means I can't delete the broken tunnels.
> What happens when you slide the item over to reveal the delete button
> and then press it?
>
Sorry 'bout not sending that to the list, corrected.

Didn't know about that option? :-(? Which does work, thanks.


From me at anatoli.ws  Wed Sep 22 23:12:45 2021
From: me at anatoli.ws (Anatoli)
Date: Wed, 22 Sep 2021 20:12:45 -0300
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9pjuin565o4Ckmj2rHEhO9bAd4uaGarMA9SAMmP=85_wQ@mail.gmail.com>
References: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <B096024B-E199-462E-978C-73B2C1D4C8D2@anatoli.ws>
 <CAHmME9pjuin565o4Ckmj2rHEhO9bAd4uaGarMA9SAMmP=85_wQ@mail.gmail.com>
Message-ID: <23be4054-af4f-b9a2-c01f-6e6dc33096a4@anatoli.ws>

Sorry, I replied before I've got your mail about the new version.

This is how the old version was behaving. Haven't tested yet the new version.
I'll test it and report today or tomorrow.


On 22/9/21 19:26, Jason A. Donenfeld wrote:
> On Wed, Sep 22, 2021 at 4:24 PM Anatoli <me at anatoli.ws> wrote:
>>
>> I can confirm that recreating the tunnel from scratch does work. So the problem is that the tunnel settings become corrupted when iOS is upgraded from 13.x / 14.x to 15.0.
> 
> What are you testing? The new version of the app or the old one? Does
> the new one corrupt settings or only the old one? Precision is
> important here.
> 

From alan at meshify.app  Wed Sep 22 23:53:59 2021
From: alan at meshify.app (Alan Graham)
Date: Wed, 22 Sep 2021 16:53:59 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <23be4054-af4f-b9a2-c01f-6e6dc33096a4@anatoli.ws>
References: <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <B096024B-E199-462E-978C-73B2C1D4C8D2@anatoli.ws>
 <CAHmME9pjuin565o4Ckmj2rHEhO9bAd4uaGarMA9SAMmP=85_wQ@mail.gmail.com>
 <23be4054-af4f-b9a2-c01f-6e6dc33096a4@anatoli.ws>
Message-ID: <CAMeHLtyiG_nKz2BAi+_bD4HBZu-CCVb8N7nqBn6H42rZ5QKv0w@mail.gmail.com>

Hi,

I have an iOS 15 iPhone 12 Pro Max with three tunnels configured.  The
upgrade from 14 to 15 busted the configs as described.  I deleted and
recreated one of the tunnels and it worked fine.  I updated to today's
bits (which appear to have been released in record time).  The tunnel
that I deleted and recreated is still working fine.  The other two
tunnels now have red backgrounds and I can no longer click them to see
the (empty) details like I could in the older build.  Trying to
activate it does not work (it does not, however, rapidly switch
between on and off).  It looks like I can delete them by swiping left
to reveal a delete button, but I can leave them in their current state
for more testing.  I did not have on-demand turned on for any of the
tunnels so I cannot speak to that partially working state.  I have
iCloud keychain on, so that doesn't appear to be a fix/workaround.  I
also have an iPad that I haven't upgraded yet, so I should be able to
test the upgrade path, but I'm not sure these bits resolve the
problem.

Best regards,
Alan

On Wed, Sep 22, 2021 at 4:26 PM Anatoli <me at anatoli.ws> wrote:
>
> Sorry, I replied before I've got your mail about the new version.
>
> This is how the old version was behaving. Haven't tested yet the new version.
> I'll test it and report today or tomorrow.
>
>
> On 22/9/21 19:26, Jason A. Donenfeld wrote:
> > On Wed, Sep 22, 2021 at 4:24 PM Anatoli <me at anatoli.ws> wrote:
> >>
> >> I can confirm that recreating the tunnel from scratch does work. So the problem is that the tunnel settings become corrupted when iOS is upgraded from 13.x / 14.x to 15.0.
> >
> > What are you testing? The new version of the app or the old one? Does
> > the new one corrupt settings or only the old one? Precision is
> > important here.
> >

From Jason at zx2c4.com  Thu Sep 23 01:34:22 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 19:34:22 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
Message-ID: <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>

Hey folks,

Small update: I've managed to update a fresh 14 device to 15 using the
latest build, and things are broken still.

On the plus side:
- The new build no longer deletes VPN profiles when the corresponding
keychain references are unresolvable, so if there's any chance of
recovery in a next build, it won't ruin those chances.
- Now that I can reproduce it, I can hammer away at trying to fix this directly.

On the minus side:
- The fact that a keychain reference goes stale during an update from
14 to 15 sounds solidly like an Apple bug, rather than any sort of API
misuse.
- I'm skeptical that there'll be a workaround, and if there is, it
will probably be pretty ugly.

If anyone knows the SecItem APIs well, the file in question is:
https://git.zx2c4.com/wireguard-apple/tree/Sources/Shared/Keychain.swift

So, I guess I'll jump into this in full force now. Here we go...

Jason

From tlhackque at yahoo.com  Wed Sep 22 22:33:54 2021
From: tlhackque at yahoo.com (tlhackque)
Date: Wed, 22 Sep 2021 18:33:54 -0400
Subject: DNS setup issues
References: <c866ae33-489b-1075-99ef-953e38566b73.ref@yahoo.com>
Message-ID: <c866ae33-489b-1075-99ef-953e38566b73@yahoo.com>

Working my way through setting up a WireGuard (linux) server, starting
with a simple configuration.

I find that I'm unable to configure the clients (Android, Windows) to
resolve the server endpoint.

This seems to be a bug/oversight in wireguard.? Here's why:

When on the VPN, the client needs to use a DNS server that has an
internal IP address.?

This is because the DNS for the server site has split views.

  * From an internal IP address, both internal and external names are
    resolved - recursively if necessary
  * From a public IP address, only not only are internal hosts
    un-resolvable, some (including the vpn server) have different
    internal and public addresses.

Also, the endpoint has multiple addresses (e.g. v4 and v6), so a name is
especially desirable.

Thus:

  * when the tunnel is up, the client must use an internal DNS server,
    which only has an internal IP address
  * when the tunnel is down (or restarting), the client must use some
    DNS server with a public IP address to resolve the tunnel endpoint.
  * when the tunnel changes state, any DNS cache has to be flushed (or
    tagged with VPN state) so that the correct addresses are used.
  * when a WiFi client initially connects to WiFi, it may have to use
    the DHCP-provided DNS server in order to get through the WiFi portal
    process.

The clients seem to use the DNS server specified in the configuration to
resolve the endpoint address at all times.? Obviously, this fails.

I don't see a way to configure the client to accommodate this use case,
which is pretty common.?

Am I missing something?? If not, a fix would be very helpful.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210922/d0c9241a/attachment.sig>

From Jason at zx2c4.com  Thu Sep 23 02:49:24 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 20:49:24 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
Message-ID: <CAHmME9r8cCPM39mM=oAFgA0nDGAbiEghnkD8m_Y_g76FV_PBOg@mail.gmail.com>

Hi again,

I'm afraid the situation is somewhat bad...

It appears that iOS 15 has completely deleted the iOS 14's WireGUard
keychain items, at least as far as the WireGuard app can see. I've yet
to jailbreak or look at an image dump to see if it's still hiding
somewhere, but it also doesn't matter, because from the app's
perspective, the keychain appears totally empty.

Digging in just on the surface, it looks like the keychain references
from iOS 14 are something like "67656e7000000000000000f7", with that
f7 incrementing, while the ones from iOS 15 are
"67656e700167269751a94355a004bfa75f951cec" -- same prefix, but the
suffix is longer and seemingly random. Did the migration from one
format to the other go bad on upgrade? Did something else happen? I
don't really know much yet about the guts of this bug, but it does
seem like something is going on. We've never had any issues with the
keychain being emptied between iOS versions before.

So now we need to figure out what to do. I'm still holding out a tiny
sliver of hope that there's a mistake somewhere and this can all be
fixed by the app, but so far I've come up dry when looking around for
that. What if this really is an iOS 15 bug? I'll report it to Apple,
of course, but that doesn't help the immediate issue that people's
configs are being deleted. The behavior is at least detectable, so I
could detect the migration, delete all of the orphaned network
profiles (as before), and pop up a message box (resembling a
ransomware screen!) saying "Where Have All Your Configurations Gone?",
followed by an apologetic explanation. That's kind of unsatisfactory,
though. I'm all ears on other ideas if you've got any.

And if any Apple developers are hanging out on this list and want to
try their hand at a solution, that'd be much appreciated. (Plus, my
entreaty from March [1] remains.)

Jason

[1] https://lists.zx2c4.com/pipermail/wireguard/2021-March/006455.html

From miguel.arroz at gmail.com  Thu Sep 23 02:54:00 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 19:54:00 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
Message-ID: <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>

Hi,

  (Now without HTML?)

  I never wrote code touching the Keychain on iOS, but did on macOS using the iOS behaviour (kSecUseDataProtectionKeychain set to true).

  There are two things in that class that I would look into:

  - Line 40: items[kSecAttrAccessGroup] = FileManager.appGroupId

  If I understand correctly, this ends up being "group.$(APP_ID_IOS)?. I?m a bit surprised this doesn?t need the Team ID before ?group?, as it definitely needs that in macOS.

  - The openReference() function, because it?s not setting the same kSecAttrAccessGroup parameter when reading. The documentation mentions what happens when it?s not set (https://developer.apple.com/documentation/security/ksecattraccessgroup), I wonder if that changed (intentionally or due to a bug in iOS 15):

> If you don?t explicitly set a group, keychain services defaults to the app?s first access group, which is either the first keychain access group, or the app ID when the app has no keychain groups.

  None of these explain why the tunnel keeps working after upgrading to iOS 15 (if the on-demand flag is set), as I would expect the Network Extension to hit the same problem, as it goes through the same Keychain code. But maybe the behaviour is slightly different than when it?s running through the app for some reason. It could explain why re-building the tunnels would work from then on (although then I would expect the extension to *not* be able to read them). So all this may be just a red herring.

  Hope it helps somehow.

  Regards,

Miguel Arroz



> On Sep 22, 2021, at 6:34 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Hey folks,
> 
> Small update: I've managed to update a fresh 14 device to 15 using the
> latest build, and things are broken still.
> 
> On the plus side:
> - The new build no longer deletes VPN profiles when the corresponding
> keychain references are unresolvable, so if there's any chance of
> recovery in a next build, it won't ruin those chances.
> - Now that I can reproduce it, I can hammer away at trying to fix this directly.
> 
> On the minus side:
> - The fact that a keychain reference goes stale during an update from
> 14 to 15 sounds solidly like an Apple bug, rather than any sort of API
> misuse.
> - I'm skeptical that there'll be a workaround, and if there is, it
> will probably be pretty ugly.
> 
> If anyone knows the SecItem APIs well, the file in question is:
> https://git.zx2c4.com/wireguard-apple/tree/Sources/Shared/Keychain.swift
> 
> So, I guess I'll jump into this in full force now. Here we go...
> 
> Jason


From miguel.arroz at gmail.com  Thu Sep 23 03:06:04 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 20:06:04 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
Message-ID: <C177E30A-50DA-4022-9F4A-0E171FB56D66@gmail.com>

Oops never mind the second one, I misread the documentation. Reading from the keychain without specifying the group should scan all groups?



> On Sep 22, 2021, at 7:54 PM, Miguel Arroz <miguel.arroz at gmail.com> wrote:
> 
> Hi,
> 
>  (Now without HTML?)
> 
>  I never wrote code touching the Keychain on iOS, but did on macOS using the iOS behaviour (kSecUseDataProtectionKeychain set to true).
> 
>  There are two things in that class that I would look into:
> 
>  - Line 40: items[kSecAttrAccessGroup] = FileManager.appGroupId
> 
>  If I understand correctly, this ends up being "group.$(APP_ID_IOS)?. I?m a bit surprised this doesn?t need the Team ID before ?group?, as it definitely needs that in macOS.
> 
>  - The openReference() function, because it?s not setting the same kSecAttrAccessGroup parameter when reading. The documentation mentions what happens when it?s not set (https://developer.apple.com/documentation/security/ksecattraccessgroup), I wonder if that changed (intentionally or due to a bug in iOS 15):
> 
>> If you don?t explicitly set a group, keychain services defaults to the app?s first access group, which is either the first keychain access group, or the app ID when the app has no keychain groups.
> 
>  None of these explain why the tunnel keeps working after upgrading to iOS 15 (if the on-demand flag is set), as I would expect the Network Extension to hit the same problem, as it goes through the same Keychain code. But maybe the behaviour is slightly different than when it?s running through the app for some reason. It could explain why re-building the tunnels would work from then on (although then I would expect the extension to *not* be able to read them). So all this may be just a red herring.
> 
>  Hope it helps somehow.
> 
>  Regards,
> 
> Miguel Arroz
> 
> 
> 
>> On Sep 22, 2021, at 6:34 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> 
>> Hey folks,
>> 
>> Small update: I've managed to update a fresh 14 device to 15 using the
>> latest build, and things are broken still.
>> 
>> On the plus side:
>> - The new build no longer deletes VPN profiles when the corresponding
>> keychain references are unresolvable, so if there's any chance of
>> recovery in a next build, it won't ruin those chances.
>> - Now that I can reproduce it, I can hammer away at trying to fix this directly.
>> 
>> On the minus side:
>> - The fact that a keychain reference goes stale during an update from
>> 14 to 15 sounds solidly like an Apple bug, rather than any sort of API
>> misuse.
>> - I'm skeptical that there'll be a workaround, and if there is, it
>> will probably be pretty ugly.
>> 
>> If anyone knows the SecItem APIs well, the file in question is:
>> https://git.zx2c4.com/wireguard-apple/tree/Sources/Shared/Keychain.swift
>> 
>> So, I guess I'll jump into this in full force now. Here we go...
>> 
>> Jason
> 


From Jason at zx2c4.com  Thu Sep 23 03:09:08 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 21:09:08 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
Message-ID: <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>

Hi Miguel,

On Wed, Sep 22, 2021 at 8:54 PM Miguel Arroz <miguel.arroz at gmail.com> wrote:
>   If I understand correctly, this ends up being "group.$(APP_ID_IOS)?. I?m a bit surprised this doesn?t need the Team ID before ?group?, as it definitely needs that in macOS.

Indeed it's prefixed with the team on macOS, but IIRC that never worked on iOS.

>   - The openReference() function, because it?s not setting the same kSecAttrAccessGroup parameter when reading. The documentation mentions what happens when it?s not set (https://developer.apple.com/documentation/security/ksecattraccessgroup), I wonder if that changed (intentionally or due to a bug in iOS 15):
>
> > If you don?t explicitly set a group, keychain services defaults to the app?s first access group, which is either the first keychain access group, or the app ID when the app has no keychain groups.

For setting, but for reading/updating, that page says:

> By default, the SecItemUpdate, SecItemDelete, and SecItemCopyMatching
> methods search all the app?s access groups. Add the kSecAttrAccessGroup
> attribute to the query to limit the search to a particular group.

So in theory, it should be fine to omit that in openReference().
Adding it in there also doesn't cause any changes, unfortunately.

>   None of these explain why the tunnel keeps working after upgrading to iOS 15 (if the on-demand flag is set

Oh, I didn't realize that was happening. Are you *sure* about that? Is
the tunnel actually working? Or is it on, but crashing? When I go to
enable the tunnel from the system preferences view of it, it starts
and then stops, indicating the network extension couldn't open the
keychain ref either. And in the log, I see the [NET] process indeed
failing in the same spot as the [APP] process.

Jason

From miguel.arroz at gmail.com  Thu Sep 23 03:19:30 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 20:19:30 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
 <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
Message-ID: <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>

Hi,

> On Sep 22, 2021, at 8:09 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Oh, I didn't realize that was happening. Are you *sure* about that? Is
> the tunnel actually working? Or is it on, but crashing? When I go to
> enable the tunnel from the system preferences view of it, it starts
> and then stops, indicating the network extension couldn't open the
> keychain ref either. And in the log, I see the [NET] process indeed
> failing in the same spot as the [APP] process.
> 
> Jason

  Yeah, I?m 100% sure they were working fine after the update but before I launched the app and touched the on/off switch there. I only noticed the problem due to the emails here, as the tunnel itself was working smoothly (I only have one per device and it?s on-demand, so I rarely interact with the app itself).

  My initial assumption was, after iOS upgrade, the network extension was able to read the data to create the tunnel, but the app corrupted it as soon as I tried to turn the tunnel off through the app.

  Regards,

Miguel Arroz 


From Jason at zx2c4.com  Thu Sep 23 03:22:16 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 21:22:16 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
 <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
 <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>
Message-ID: <CAHmME9r5HX6qYNQRarK0Mbv+Vf5dyyWwH-RjLmsjWHSy-YBEUQ@mail.gmail.com>

Hi Miguel,

On Wed, Sep 22, 2021 at 9:19 PM Miguel Arroz <miguel.arroz at gmail.com> wrote:
>   Yeah, I?m 100% sure they were working fine after the update but before I launched the app and touched the on/off switch there.

Interesting... Alright then, new theory: the keychain references are
accessible in the old 12-byte format, but are presented when iterating
in the new 20-byte format. The deleteReferences(except: refs) function
iterates through all, removes everything in the except list, and then
deletes what remains. If the iteration reference doesn't match with
the except reference, despite pointing to the same object, then it'll
delete them incorrectly. ...restoring to iOS 14 now to test that
theory.

Jason

From Jason at zx2c4.com  Thu Sep 23 03:57:48 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 21:57:48 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9r5HX6qYNQRarK0Mbv+Vf5dyyWwH-RjLmsjWHSy-YBEUQ@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
 <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
 <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>
 <CAHmME9r5HX6qYNQRarK0Mbv+Vf5dyyWwH-RjLmsjWHSy-YBEUQ@mail.gmail.com>
Message-ID: <CAHmME9ruxL6LKmPNEhkmUCGG_tNQBhxkPx8v_dujPwAOnXowzw@mail.gmail.com>

Hi Miguel,

On Wed, Sep 22, 2021 at 9:22 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Interesting... Alright then, new theory: the keychain references are
> accessible in the old 12-byte format, but are presented when iterating
> in the new 20-byte format. The deleteReferences(except: refs) function
> iterates through all, removes everything in the except list, and then
> deletes what remains. If the iteration reference doesn't match with
> the except reference, despite pointing to the same object, then it'll
> delete them incorrectly. ...restoring to iOS 14 now to test that
> theory.

Good news! The theory holds. Thanks for bringing that behavior to my
attention. I think this should be fixable.

iOS changing persistent keychain refs to be non-bijective I guess is a
bit of a shocker, but I'm glad we've gotten to the bottom of it.

Jason

From Jason at zx2c4.com  Thu Sep 23 04:13:46 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Wed, 22 Sep 2021 22:13:46 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9ruxL6LKmPNEhkmUCGG_tNQBhxkPx8v_dujPwAOnXowzw@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
 <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
 <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>
 <CAHmME9r5HX6qYNQRarK0Mbv+Vf5dyyWwH-RjLmsjWHSy-YBEUQ@mail.gmail.com>
 <CAHmME9ruxL6LKmPNEhkmUCGG_tNQBhxkPx8v_dujPwAOnXowzw@mail.gmail.com>
Message-ID: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>

Hi,

Fixed! https://git.zx2c4.com/wireguard-apple/commit/?id=03a59ff38e96fb3bb5dde2f15fe42198d1dfb995

Thank you to everyone in this thread who helped get to the bottom of this.

Jason

From miguel.arroz at gmail.com  Thu Sep 23 04:21:28 2021
From: miguel.arroz at gmail.com (Miguel Arroz)
Date: Wed, 22 Sep 2021 21:21:28 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
References: <95105bdf-8442-4c7c-dcc8-719b0784bced@attglobal.net>
 <CAHmME9qQZMb4ajHKHY8w-b8_9BNv8YM9YKyNO9U9RH0_thrCPw@mail.gmail.com>
 <49d1235b-1ed8-68f6-33bf-574ac0ad40e0@anatoli.ws>
 <CAHmME9q58QCUEY7vqhX767wPtqCPr23gmXgSS_bvbfvNZva=SQ@mail.gmail.com>
 <96bcc87f-7de1-05a4-641a-27ffac7b052d@attglobal.net>
 <DA133F84-7C21-4234-97DB-FFEDF79D1607@gmail.com>
 <CAHmME9p69qDGUJnbHVsqH_vx8mf=dNY3-sQ-7APhOG85xxLYWA@mail.gmail.com>
 <CAHmME9rQY8OU3jbXnB=OroBvudO1KCXL3vL6ESuEgZoMSRqVLw@mail.gmail.com>
 <CAHmME9reWG3UiHQm1fBvyQUoUF5_oJv6YiBGaOE2AUgLt-nK3w@mail.gmail.com>
 <BD9150AA-4F49-416A-A897-A9C4000C354E@gmail.com>
 <CAHmME9rREdEAWEDYyHaRWHwkUUWy1MPdrBokSygO8rhyxTJgXg@mail.gmail.com>
 <1B181919-09C0-4908-82F2-DD5661C53FD0@gmail.com>
 <CAHmME9r5HX6qYNQRarK0Mbv+Vf5dyyWwH-RjLmsjWHSy-YBEUQ@mail.gmail.com>
 <CAHmME9ruxL6LKmPNEhkmUCGG_tNQBhxkPx8v_dujPwAOnXowzw@mail.gmail.com>
 <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
Message-ID: <D12BB3A3-28D0-4E53-AB85-86E67CED17B5@gmail.com>

Hi,

  Awesome! Thank you for the quick fix.

  Regards,

Miguel Arroz

  

> On Sep 22, 2021, at 9:13 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> Hi,
> 
> Fixed! https://git.zx2c4.com/wireguard-apple/commit/?id=03a59ff38e96fb3bb5dde2f15fe42198d1dfb995
> 
> Thank you to everyone in this thread who helped get to the bottom of this.
> 
> Jason


From tklauser at distanz.ch  Thu Sep 23 10:05:13 2021
From: tklauser at distanz.ch (Tobias Klauser)
Date: Thu, 23 Sep 2021 12:05:13 +0200
Subject: [PATCH wireguard-go] tun: avoid leaking sock fd in CreateTUN error
 cases
Message-ID: <20210923100513.1452-1-tklauser@distanz.ch>

At these points, the socket file descriptor is not yet wrapped in an
*os.File, so it needs to be closed explicitly on error.

Signed-off-by: Tobias Klauser <tklauser at distanz.ch>
---
 tun/tun_darwin.go |  6 ++++--
 tun/tun_linux.go  | 11 +++++++----
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/tun/tun_darwin.go b/tun/tun_darwin.go
index a703c8c34eac..35d3085747cc 100644
--- a/tun/tun_darwin.go
+++ b/tun/tun_darwin.go
@@ -108,7 +108,6 @@ func CreateTUN(name string, mtu int) (Device, error) {
 	}
 
 	fd, err := unix.Socket(unix.AF_SYSTEM, unix.SOCK_DGRAM, 2)
-
 	if err != nil {
 		return nil, err
 	}
@@ -117,6 +116,7 @@ func CreateTUN(name string, mtu int) (Device, error) {
 	copy(ctlInfo.Name[:], []byte(utunControlName))
 	err = unix.IoctlCtlInfo(fd, ctlInfo)
 	if err != nil {
+		unix.Close(fd)
 		return nil, fmt.Errorf("IoctlGetCtlInfo: %w", err)
 	}
 
@@ -127,11 +127,13 @@ func CreateTUN(name string, mtu int) (Device, error) {
 
 	err = unix.Connect(fd, sc)
 	if err != nil {
+		unix.Close(fd)
 		return nil, err
 	}
 
-	err = syscall.SetNonblock(fd, true)
+	err = unix.SetNonblock(fd, true)
 	if err != nil {
+		unix.Close(fd)
 		return nil, err
 	}
 	tun, err := CreateTUNFromFile(os.NewFile(uintptr(fd), ""), mtu)
diff --git a/tun/tun_linux.go b/tun/tun_linux.go
index 466a805671c1..1cc84cba0ee5 100644
--- a/tun/tun_linux.go
+++ b/tun/tun_linux.go
@@ -419,6 +419,7 @@ func CreateTUN(name string, mtu int) (Device, error) {
 	var flags uint16 = unix.IFF_TUN // | unix.IFF_NO_PI (disabled for TUN status hack)
 	nameBytes := []byte(name)
 	if len(nameBytes) >= unix.IFNAMSIZ {
+		unix.Close(nfd)
 		return nil, fmt.Errorf("interface name too long: %w", unix.ENAMETOOLONG)
 	}
 	copy(ifr[:], nameBytes)
@@ -431,17 +432,19 @@ func CreateTUN(name string, mtu int) (Device, error) {
 		uintptr(unsafe.Pointer(&ifr[0])),
 	)
 	if errno != 0 {
+		unix.Close(nfd)
 		return nil, errno
 	}
-	err = unix.SetNonblock(nfd, true)
-
-	// Note that the above -- open,ioctl,nonblock -- must happen prior to handing it to netpoll as below this line.
 
-	fd := os.NewFile(uintptr(nfd), cloneDevicePath)
+	err = unix.SetNonblock(nfd, true)
 	if err != nil {
+		unix.Close(nfd)
 		return nil, err
 	}
 
+	// Note that the above -- open,ioctl,nonblock -- must happen prior to handing it to netpoll as below this line.
+
+	fd := os.NewFile(uintptr(nfd), cloneDevicePath)
 	return CreateTUNFromFile(fd, mtu)
 }
 
-- 
2.33.0


From tklauser at distanz.ch  Thu Sep 23 10:07:19 2021
From: tklauser at distanz.ch (Tobias Klauser)
Date: Thu, 23 Sep 2021 12:07:19 +0200
Subject: [PATCH wireguard-go] tun: make operateonfd.go build tags more specific
Message-ID: <20210923100719.2083-1-tklauser@distanz.ch>

(*NativeTun).operateOnFd is only used on darwin and freebsd. Adjust the
build tags accordingly.

Signed-off-by: Tobias Klauser <tklauser at distanz.ch>
---
 tun/operateonfd.go | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tun/operateonfd.go b/tun/operateonfd.go
index aab71161f27c..bc804539169f 100644
--- a/tun/operateonfd.go
+++ b/tun/operateonfd.go
@@ -1,5 +1,5 @@
-//go:build !windows
-// +build !windows
+//go:build darwin || freebsd
+// +build darwin freebsd
 
 /* SPDX-License-Identifier: MIT
  *
-- 
2.33.0


From me at anatoli.ws  Thu Sep 23 14:41:58 2021
From: me at anatoli.ws (Anatoli)
Date: Thu, 23 Sep 2021 11:41:58 -0300
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
References: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
Message-ID: <F238DB7D-1876-4821-ABC2-4FCF029FBB2B@anatoli.ws>

Great! Thanks for a quick solution!

Please let us know in this thread when the update is in the AppStore.

> On 23 Sep 2021, at 01:14, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> ?Hi,
> 
> Fixed! https://git.zx2c4.com/wireguard-apple/commit/?id=03a59ff38e96fb3bb5dde2f15fe42198d1dfb995
> 
> Thank you to everyone in this thread who helped get to the bottom of this.
> 
> Jason

From Jason at zx2c4.com  Thu Sep 23 15:54:20 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 09:54:20 -0600
Subject: [PATCH wireguard-go] tun: avoid leaking sock fd in CreateTUN
 error cases
In-Reply-To: <20210923100513.1452-1-tklauser@distanz.ch>
References: <20210923100513.1452-1-tklauser@distanz.ch>
Message-ID: <CAHmME9rzGKO51oh5UBvPV+qn7J8yAXbQHsWXh-k+r1BkCHfVTw@mail.gmail.com>

Applied, thanks! I'm curious: is this a bug you ran into somewhere?

From Jason at zx2c4.com  Thu Sep 23 15:54:59 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 09:54:59 -0600
Subject: [PATCH wireguard-go] tun: make operateonfd.go build tags more
 specific
In-Reply-To: <20210923100719.2083-1-tklauser@distanz.ch>
References: <20210923100719.2083-1-tklauser@distanz.ch>
Message-ID: <CAHmME9rgdnbs7JWtDkmjRwDQwX33_fF2s8-AqPxx3nwsPOQRUg@mail.gmail.com>

I've applied this. Thanks for the patch. Though I do wonder: it's
functionally the same as before, right? What instances lead to this
being an issue? Or did this way just seem more correct?

From daniel at dumke.me  Thu Sep 23 10:47:38 2021
From: daniel at dumke.me (Daniel Dumke)
Date: Thu, 23 Sep 2021 12:47:38 +0200
Subject: Wireguard massive amount data
Message-ID: <EBVVZQ.U9BF94AEV1NE@dumke.me>

Hi,

I am trying to connect to a Mullvad Wireguard Host with my Fedora Linux 
using nmcli, as soon as I up the connection (nmcli con up Mullvad) 
massive amounts of data are sent through the tunnel (according to wg 
1.4 GiB in the first 20 secs).

Any hints on why this huge amount of data is transfered?

Daniel

'''
root at lenovo# wg
interface: wg1
  public key: zr0q0pxcOfSoiKWjXEfuHqM58GMjE4HBLr8FzQIHYxM=
  private key: (hidden)
  listening port: 40360
  fwmark: 0xcbdf

peer: C2TUHPoZlT08iceLM2coBDTbcfg9tTKrUt7tRBWP0nk=
  endpoint: 45.8.223.195:51820
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 20 seconds ago
  transfer: 4.23 KiB received, 1.39 GiB sent
  persistent keepalive: every 33 seconds


root at lenovo# route
Kernel IP Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use 
Iface
default         _gateway        0.0.0.0         UG    50     0        0 
wg1
default         _gateway        0.0.0.0         UG    600    0        0 
wlp0s12f0
_gateway        0.0.0.0         255.255.255.255 UH    20050  0        0 
wg1
10.0.2.0        0.0.0.0         255.255.255.0   U     600    0        0 
wlp0s12f0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 
virbr0


'''



From Jason at zx2c4.com  Thu Sep 23 16:00:19 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 10:00:19 -0600
Subject: Wireguard massive amount data
In-Reply-To: <EBVVZQ.U9BF94AEV1NE@dumke.me>
References: <EBVVZQ.U9BF94AEV1NE@dumke.me>
Message-ID: <CAHmME9puBnmEYfsGqf4ReshhoSHTE5tv7sEVW7MSpuWpS-fr=Q@mail.gmail.com>

Sounds likely to be a routing loop? I'm not sure whether NM sets up
policy routing to avoid this like wg-quick(8) does. I would hope they
do, but it might also be rather lazy and not. Worth looking into, I
suppose. In the interim, wg-quick will probably do the right thing.

From Jason at zx2c4.com  Thu Sep 23 17:26:43 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 11:26:43 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <F238DB7D-1876-4821-ABC2-4FCF029FBB2B@anatoli.ws>
References: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
 <F238DB7D-1876-4821-ABC2-4FCF029FBB2B@anatoli.ws>
Message-ID: <CAHmME9orYEOFa-33XvYs==XHjsUrxTn2BtOaVySwFuxS+oj+MQ@mail.gmail.com>

On Thu, Sep 23, 2021 at 8:42 AM Anatoli <me at anatoli.ws> wrote:
> Please let us know in this thread when the update is in the AppStore.

Indeed I will. It's been in the "waiting for review" state for about
13 hours. So hopefully that'll change somewhat soonish.

Jason

From leshniack at gmail.com  Thu Sep 23 22:23:41 2021
From: leshniack at gmail.com (=?UTF-8?Q?Maciej_Le=C5=9Bniewski?=)
Date: Fri, 24 Sep 2021 00:23:41 +0200
Subject: wireguard-apple: overriding on-demand status
Message-ID: <CAKF6ahaqcCYg5zrnM=uRzdmgLhui5CD-JhaiXvsMrOGkSbdF0g@mail.gmail.com>

Hello,

firstly, thank you for the amazing job and the on-demand feature.

Question: What if I'd like to override the exclusions and enable my
tunnel in on-demand mode just for a while (wireguard-apple
v1.0.14-25)? Do I have to edit the tunnel profile?

Explanation: I'd like to have an auto-(de)activation when network
changes, according to the rules, but still be able to override this
behavior. So the on-demand rules should be reapplied every time when
network changes, but after that I still should be able to turn on/off
the tunnel manually.

For me, the controls looks a bit over engineered right now. I think
that two switches would be better ? the main switch should stay as it
was before, but should also allow to turn on/off the tunnel regardless
of the on-demand settings. And, additionally, a second switch (in the
details view) that allows to enable/disable the on-demand function.

Maybe it may cause some issues that I don't see, especially in a
multi-tunnel scenario. Anyway, please consider it.

Regards,
Maciej Le?niewski

From Jason at zx2c4.com  Fri Sep 24 00:21:44 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 18:21:44 -0600
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
 <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
Message-ID: <CAHmME9ojB6wt13NyoZhuGm0KHq1eJ2oyvurUGA8vwUkHtxTsuQ@mail.gmail.com>

Hi Oliver,

On Wed, Sep 22, 2021 at 8:02 AM Oliver Freyermuth
<freyermuth at physik.uni-bonn.de> wrote:
> I tried to boot one of the machines with boot/startup logging (I'm not sure this is the correct English translation, it is one of the options next to safe mode in the WinRE),
> and ntbootlog.txt ended during network driver loading.

If you're able to supply the ntbootlog.txt and any other logs on the
system (setupapi log, wireguard log, event logs, and so on), that
would be much appreciated. I'm still a bit puzzled about this report
and I'd like to get to the bottom of it.

Jason

-- 
Jason A. Donenfeld
Deep Space Explorer
fr: +33 6 51 90 82 66
us: +1 513 476 1200

From Jason at zx2c4.com  Fri Sep 24 00:23:43 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 18:23:43 -0600
Subject: wireguard-apple: overriding on-demand status
In-Reply-To: <CAKF6ahaqcCYg5zrnM=uRzdmgLhui5CD-JhaiXvsMrOGkSbdF0g@mail.gmail.com>
References: <CAKF6ahaqcCYg5zrnM=uRzdmgLhui5CD-JhaiXvsMrOGkSbdF0g@mail.gmail.com>
Message-ID: <CAHmME9rWeCxtCjPZ4c2+xzC_JipJzCAggKD-vDXiAswt_zjVCA@mail.gmail.com>

On Thu, Sep 23, 2021 at 6:22 PM Maciej Le?niewski <leshniack at gmail.com> wrote:
> Question: What if I'd like to override the exclusions and enable my
> tunnel in on-demand mode just for a while (wireguard-apple
> v1.0.14-25)? Do I have to edit the tunnel profile?

Yes. That's how these APIs work.

From Jason at zx2c4.com  Fri Sep 24 02:17:04 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 20:17:04 -0600
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9orYEOFa-33XvYs==XHjsUrxTn2BtOaVySwFuxS+oj+MQ@mail.gmail.com>
References: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
 <F238DB7D-1876-4821-ABC2-4FCF029FBB2B@anatoli.ws>
 <CAHmME9orYEOFa-33XvYs==XHjsUrxTn2BtOaVySwFuxS+oj+MQ@mail.gmail.com>
Message-ID: <CAHmME9oH6s=x0W+aBvGumTtJ9=bj+a9SBy0TQxXv8ZtU-pnDBA@mail.gmail.com>

On Thu, Sep 23, 2021 at 11:26 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Thu, Sep 23, 2021 at 8:42 AM Anatoli <me at anatoli.ws> wrote:
> > Please let us know in this thread when the update is in the AppStore.
>
> Indeed I will. It's been in the "waiting for review" state for about
> 13 hours. So hopefully that'll change somewhat soonish.

This has been released now. I'll send out an email in a new thread
announcing this.

From Jason at zx2c4.com  Fri Sep 24 02:23:51 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 23 Sep 2021 20:23:51 -0600
Subject: [WARNING - iOS 15] Update WireGuard to >=1.0.15-26 *before* updating
 to iOS 15
Message-ID: <CAHmME9p9XxAhh4WgZgRiMRFxahp2wabPr-KuW=AdVQyRsHaD+A@mail.gmail.com>

Hello list,

Due to buggy changes Apple has made to the Keychain on iOS 15, older
versions of WireGuard on iOS will *eat your VPN configurations* when
upgrading to iOS 15. This has been fixed by [1], which is now
available as of version ?1.0.15-26. If you are still on iOS 14, before
updating to iOS 15, please remember to update the WireGuard app to
this latest version in the App Store.

Sorry for the hassle.

Jason

[1] https://git.zx2c4.com/wireguard-apple/commit/?id=03a59ff38e96fb3bb5dde2f15fe42198d1dfb995

From Jason at zx2c4.com  Fri Sep 24 06:14:25 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Sep 2021 00:14:25 -0600
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
Message-ID: <CAHmME9o_490d9W85=A6xUFktvKuvCAsmqb2T80BNsVY8BRfd0w@mail.gmail.com>

Hi Oliver,

These came out on Tuesday, which might correspond with your timeline:
https://support.microsoft.com/en-us/topic/september-21-2021-kb5005624-os-build-18363-1830-preview-b2a3af81-696b-4d59-8d7b-a05389407bb8
https://support.microsoft.com/en-us/topic/september-21-2021-kb5005625-os-build-17763-2210-preview-5ae2f63d-a9ce-49dd-a5e6-e05b90dc1cd8

Is it possible that you installed either of these immediately before
the problem began? Post hoc ergo propter hoc, of course, but if you,
Joshua, and a third private reporter of this bug all have the same
correlation, that's interesting...

Thanks,
Jason

From alan at meshify.app  Fri Sep 24 08:05:41 2021
From: alan at meshify.app (Alan Graham)
Date: Fri, 24 Sep 2021 01:05:41 -0700
Subject: WireGuard Configurations Gone After iOS 15 Upgrade
In-Reply-To: <CAHmME9oH6s=x0W+aBvGumTtJ9=bj+a9SBy0TQxXv8ZtU-pnDBA@mail.gmail.com>
References: <CAHmME9oKfJJfnrKeXcaHeb-oa+JZ+OgnxLVny==uSgwa5c5sKA@mail.gmail.com>
 <F238DB7D-1876-4821-ABC2-4FCF029FBB2B@anatoli.ws>
 <CAHmME9orYEOFa-33XvYs==XHjsUrxTn2BtOaVySwFuxS+oj+MQ@mail.gmail.com>
 <CAHmME9oH6s=x0W+aBvGumTtJ9=bj+a9SBy0TQxXv8ZtU-pnDBA@mail.gmail.com>
Message-ID: <CAMeHLtwod6gk5Y5Dg4W2nX1AN=EWa-crixmR=ZpBd0e=vw5AqA@mail.gmail.com>

I can confirm that upgrading wireguard, and then upgrading to iOS 15
works flawlessly with the released bits.

Best wishes,
Alan

On Thu, Sep 23, 2021 at 7:27 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Thu, Sep 23, 2021 at 11:26 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> >
> > On Thu, Sep 23, 2021 at 8:42 AM Anatoli <me at anatoli.ws> wrote:
> > > Please let us know in this thread when the update is in the AppStore.
> >
> > Indeed I will. It's been in the "waiting for review" state for about
> > 13 hours. So hopefully that'll change somewhat soonish.
>
> This has been released now. I'll send out an email in a new thread
> announcing this.

From tklauser at distanz.ch  Fri Sep 24 08:40:59 2021
From: tklauser at distanz.ch (Tobias Klauser)
Date: Fri, 24 Sep 2021 10:40:59 +0200
Subject: [PATCH wireguard-go] tun: make operateonfd.go build tags more
 specific
In-Reply-To: <CAHmME9rgdnbs7JWtDkmjRwDQwX33_fF2s8-AqPxx3nwsPOQRUg@mail.gmail.com>
References: <20210923100719.2083-1-tklauser@distanz.ch>
 <CAHmME9rgdnbs7JWtDkmjRwDQwX33_fF2s8-AqPxx3nwsPOQRUg@mail.gmail.com>
Message-ID: <20210924084058.b7ouwpie2c6bjcac@distanz.ch>

On 2021-09-23 at 17:54:59 +0200, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> I've applied this. Thanks for the patch. Though I do wonder: it's
> functionally the same as before, right? What instances lead to this
> being an issue? Or did this way just seem more correct?

Thanks. Functionally it's the same, yes. I noticed this when running
staticcheck against wireguard-go on Linux and it reported
(*NativeTun).operateOnFd as being defined but not used. So it just
seemed more correct to only define it for platforms that actually use
it.

From tklauser at distanz.ch  Fri Sep 24 08:45:24 2021
From: tklauser at distanz.ch (Tobias Klauser)
Date: Fri, 24 Sep 2021 10:45:24 +0200
Subject: [PATCH wireguard-go] tun: avoid leaking sock fd in CreateTUN
 error cases
In-Reply-To: <CAHmME9rzGKO51oh5UBvPV+qn7J8yAXbQHsWXh-k+r1BkCHfVTw@mail.gmail.com>
References: <20210923100513.1452-1-tklauser@distanz.ch>
 <CAHmME9rzGKO51oh5UBvPV+qn7J8yAXbQHsWXh-k+r1BkCHfVTw@mail.gmail.com>
Message-ID: <20210924084524.iwgnjuxhfxidwhnc@distanz.ch>

On 2021-09-23 at 17:54:20 +0200, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Applied, thanks! I'm curious: is this a bug you ran into somewhere?

I've not seen this causing problems with wireguard-go specifically, but
have seen issues with leaked fds elsewhere. So by now I'm attentive of
the pattern and send fixes where I notice it :)

From tlhackque at yahoo.com  Fri Sep 24 15:31:40 2021
From: tlhackque at yahoo.com (tlhackque)
Date: Fri, 24 Sep 2021 11:31:40 -0400
Subject: Wireguard Neighborhood (IPv6)
References: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec.ref@yahoo.com>
Message-ID: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec@yahoo.com>

TLDR; It seems that WireGuard isn't supporting IPv6 NDP, and it should.?
Use case & a work-around.

Full story:

Configuration:

WireGuard server (Linux, details below) behind a site router that
handles IPv4 NAT & an IPv6 tunnel.

Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.

The WireGuard server is able to access the WireGuard peers (clients)
over IPv6.? The other hosts (and the router) are not.

The clients can't even ping the other hosts - the echo replies are
generated, but they end up with an icmp6 unreachable.

It turns out that the other hosts (and router) send an icmp6 Neighbor
Solicitation for the clients, which is never answered.

My interim solution was to implement
https://github.com/setaou/ndp-proxy, which will respond with Neighbor
Advertisements for the entire WireGuard subnet.

This is a rather crude solution - since ndp-proxy doesn't know what
clients are connected, and since it requires one proxy process/wg interface.

It seems to me that WireGuard (in this case on the server) should at
least be responding to Neighbor Solicitations for AllowedIPs of its
active peers... Of course in the case of a WireGuard tunnel between two
such sites, this is symmetric.

I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
address - and in any case I couldn't get it to work.? Neither did
advertising the server as a "router" with radvd.

Unless I'm missing something, it seems to me that supporting NDP is the
simplest "it just works" approach in any case...

wireguard-tools v1.0.20210424 - https://git.zx2c4.com/wireguard-tools/

Linux hagrid 5.13.16-200.fc34.x86_64 #1 SMP Mon Sep 13 12:39:36 UTC 2021
x86_64 x86_64 x86_64 GNU/Linux


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210924/b36509e3/attachment.sig>

From jeroen at massar.ch  Fri Sep 24 15:45:58 2021
From: jeroen at massar.ch (Jeroen Massar)
Date: Fri, 24 Sep 2021 17:45:58 +0200
Subject: Wireguard Neighborhood (IPv6)
In-Reply-To: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec@yahoo.com>
References: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec.ref@yahoo.com>
 <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec@yahoo.com>
Message-ID: <9B390ADB-BDD6-4BF5-8205-65B215F63746@massar.ch>

If you have something like the very common setup:

{internet} -> [wgserver] -> [wgclient] -> [local LAN]

Then if you have address space routed to wgserver, just route a /64 to wgclient and then normally radvd(&dhcpv6) it, done.

If you only have a single /64 on the server, then indeed you need to hack around with ndproxy.

But given that ISPs have near infinite IPv6 space... they should be able to route you a simple /64 and technically, from a RIR perspective should even be doing minimal /56 or even a /48...

Greets,
 Jeroen

--

> On 20210924, at 17:31, tlhackque <tlhackque at yahoo.com> wrote:
> 
> TLDR; It seems that WireGuard isn't supporting IPv6 NDP, and it should. 
> Use case & a work-around.
> 
> Full story:
> 
> Configuration:
> 
> WireGuard server (Linux, details below) behind a site router that
> handles IPv4 NAT & an IPv6 tunnel.
> 
> Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.
> 
> The WireGuard server is able to access the WireGuard peers (clients)
> over IPv6.  The other hosts (and the router) are not.
> 
> The clients can't even ping the other hosts - the echo replies are
> generated, but they end up with an icmp6 unreachable.
> 
> It turns out that the other hosts (and router) send an icmp6 Neighbor
> Solicitation for the clients, which is never answered.
> 
> My interim solution was to implement
> https://github.com/setaou/ndp-proxy, which will respond with Neighbor
> Advertisements for the entire WireGuard subnet.
> 
> This is a rather crude solution - since ndp-proxy doesn't know what
> clients are connected, and since it requires one proxy process/wg interface.
> 
> It seems to me that WireGuard (in this case on the server) should at
> least be responding to Neighbor Solicitations for AllowedIPs of its
> active peers... Of course in the case of a WireGuard tunnel between two
> such sites, this is symmetric.
> 
> I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
> address - and in any case I couldn't get it to work.  Neither did
> advertising the server as a "router" with radvd.
> 
> Unless I'm missing something, it seems to me that supporting NDP is the
> simplest "it just works" approach in any case...
> 
> wireguard-tools v1.0.20210424 - https://git.zx2c4.com/wireguard-tools/
> 
> Linux hagrid 5.13.16-200.fc34.x86_64 #1 SMP Mon Sep 13 12:39:36 UTC 2021
> x86_64 x86_64 x86_64 GNU/Linux
> 
> 


From rm at romanrm.net  Fri Sep 24 15:58:58 2021
From: rm at romanrm.net (Roman Mamedov)
Date: Fri, 24 Sep 2021 20:58:58 +0500
Subject: Wireguard Neighborhood (IPv6)
In-Reply-To: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec@yahoo.com>
References: <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec.ref@yahoo.com>
 <0fa09c57-e2de-b1fc-8ca1-2f03fe543bec@yahoo.com>
Message-ID: <20210924205858.3805c65a@natsu>

On Fri, 24 Sep 2021 11:31:40 -0400
tlhackque <tlhackque at yahoo.com> wrote:

> WireGuard server (Linux, details below) behind a site router that
> handles IPv4 NAT & an IPv6 tunnel.
> 
> Server LAN has other hosts (and multiple subnets/vlans) - mostly dual stack.
> 
> The WireGuard server is able to access the WireGuard peers (clients)
> over IPv6.? The other hosts (and the router) are not.
> 
> The clients can't even ping the other hosts - the echo replies are
> generated, but they end up with an icmp6 unreachable.
> 
> It turns out that the other hosts (and router) send an icmp6 Neighbor
> Solicitation for the clients, which is never answered.
> 
> My interim solution was to implement
> https://github.com/setaou/ndp-proxy, which will respond with Neighbor
> Advertisements for the entire WireGuard subnet.
> 
> This is a rather crude solution - since ndp-proxy doesn't know what
> clients are connected, and since it requires one proxy process/wg interface.
> 
> It seems to me that WireGuard (in this case on the server) should at
> least be responding to Neighbor Solicitations for AllowedIPs of its
> active peers... Of course in the case of a WireGuard tunnel between two
> such sites, this is symmetric.
> 
> I did look at net.ipv6.conf.*.proxy_ndp, but that requires adding each
> address - and in any case I couldn't get it to work.? Neither did
> advertising the server as a "router" with radvd.
> 
> Unless I'm missing something, it seems to me that supporting NDP is the
> simplest "it just works" approach in any case...

You are not configuring your network correctly routing-wise, and the issue is
not "WireGuard not supporting NDP" -- yes it doesn't, but that's not the point
to blame for the behavior that you observe -- which is completely normal.

Server LAN is one L2 network, the WG network is *another* and L3 network.
There is nothing nowhere that dictates that there would be NDP replies
*across* separate networks, let alone L2 vs L3.

The WG network needs its own separate IPv6 range, and other hosts need to have
a route to that range "via" the VPN server (if its not their default gateway).
Then, the WG clients need to know the route back to those other hosts, i.e.
the network they use needs to be in AllowedIPs for the VPN server.

-- 
With respect,
Roman

From Jason at zx2c4.com  Fri Sep 24 17:48:57 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Sep 2021 11:48:57 -0600
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
Message-ID: <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>

Hey guys,

I think we might be onto something with https://w-g.pw/l/ZO5Z ...

I'm going to cut a new release in the next few hours here. When that's
released, would you try updating to 0.4.10, going back to using the
kernel implementation, and letting me know whether the problem
resurfaces? In the absence of being able to locally produce this on a
debuggable machine, I think this kind of trial and error is all we've
got. Hopefully the theory behind https://w-g.pw/l/ZO5Z is correct.

Jason

From joshua.sjoding at scjalliance.com  Fri Sep 24 17:53:07 2021
From: joshua.sjoding at scjalliance.com (Joshua Sjoding)
Date: Fri, 24 Sep 2021 10:53:07 -0700
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
Message-ID: <CALaUSusvu8iJTXNc_07=tQ=yNKJ+HXOe1J5A=HRyAAJbzDjjYg@mail.gmail.com>

Awesome! Can do. Thanks Jason!

Joshua Sjoding
SCJ Alliance
IT Specialist

On Fri, Sep 24, 2021 at 10:49 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hey guys,
>
> I think we might be onto something with https://w-g.pw/l/ZO5Z ...
>
> I'm going to cut a new release in the next few hours here. When that's
> released, would you try updating to 0.4.10, going back to using the
> kernel implementation, and letting me know whether the problem
> resurfaces? In the absence of being able to locally produce this on a
> debuggable machine, I think this kind of trial and error is all we've
> got. Hopefully the theory behind https://w-g.pw/l/ZO5Z is correct.
>
> Jason

From Jason at zx2c4.com  Fri Sep 24 19:59:15 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Fri, 24 Sep 2021 13:59:15 -0600
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
Message-ID: <CAHmME9rknanKEdk8L5PJxbg1OZejN59z5xuh5y54O7y+zWb1nw@mail.gmail.com>

On Fri, Sep 24, 2021 at 11:48 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> I'm going to cut a new release in the next few hours here. When that's
> released

v0.4.10 is now released.

From freyermuth at physik.uni-bonn.de  Fri Sep 24 07:24:22 2021
From: freyermuth at physik.uni-bonn.de (Oliver Freyermuth)
Date: Fri, 24 Sep 2021 09:24:22 +0200
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9ojB6wt13NyoZhuGm0KHq1eJ2oyvurUGA8vwUkHtxTsuQ@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9pgz6PiXdFqcRw90EafHK-Jq9RfcgLUZaJ1ARrtdnjG0w@mail.gmail.com>
 <ddf37ac0-0d04-ad84-73c7-b334655c066c@physik.uni-bonn.de>
 <CAHmME9ojB6wt13NyoZhuGm0KHq1eJ2oyvurUGA8vwUkHtxTsuQ@mail.gmail.com>
Message-ID: <8878be62-55a0-0d29-b1d9-f161e79e54ce@physik.uni-bonn.de>

Hi Jason,

Am 24.09.21 um 02:21 schrieb Jason A. Donenfeld:
> Hi Oliver,
> 
> On Wed, Sep 22, 2021 at 8:02 AM Oliver Freyermuth
> <freyermuth at physik.uni-bonn.de> wrote:
>> I tried to boot one of the machines with boot/startup logging (I'm not sure this is the correct English translation, it is one of the options next to safe mode in the WinRE),
>> and ntbootlog.txt ended during network driver loading.
> 
> If you're able to supply the ntbootlog.txt and any other logs on the
> system (setupapi log, wireguard log, event logs, and so on), that
> would be much appreciated. I'm still a bit puzzled about this report
> and I'd like to get to the bottom of it.

I will try ? sadly, one laptop is back in the home office (and the user will stay at home for a while),
and the other user is currently unresponsive. I'll keep pushing them, though.

Attached is the single log I currently have, slightly sanitized (so I can also send it to the list):
- Machine name sed-replaced to "laptop"
- User name sed-replaced to "theuser"
- Server/Peer IP replaced to "serverip"

The issue occured at the following two timestamps:
- The next boot right after 2021-09-17 00:27:25.
- The next boot right after 2021-09-20 18:52:48.

So the next successful boot logged right after these timestamps is a boot in safe mode (without network drivers) to recover the system, which explains some of the error messages.

I think the timing of the first failure excludes the two Windows updates you found ? still, I will try to collect the Windows update history when I have access to the machines again.

Cheers,
	Oliver

-- 
Oliver Freyermuth
Universit?t Bonn
Physikalisches Institut, Raum 1.047
Nu?allee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--
-------------- next part --------------
2021-09-16 10:21:49.763758: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:23:49.815136: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:23:49.825408: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:23:49.825408: [TUN] [PI-Bonn] Keypair 4 destroyed for peer 1
2021-09-16 10:23:49.825408: [TUN] [PI-Bonn] Keypair 6 created for peer 1
2021-09-16 10:23:49.825408: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:25:50.331507: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:25:50.336643: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:25:50.336643: [TUN] [PI-Bonn] Keypair 5 destroyed for peer 1
2021-09-16 10:25:50.336643: [TUN] [PI-Bonn] Keypair 7 created for peer 1
2021-09-16 10:25:50.336643: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:27:54.765399: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:27:54.780571: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:27:54.780571: [TUN] [PI-Bonn] Keypair 6 destroyed for peer 1
2021-09-16 10:27:54.780571: [TUN] [PI-Bonn] Keypair 8 created for peer 1
2021-09-16 10:27:54.780571: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:29:55.879977: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:29:55.885186: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:29:55.885186: [TUN] [PI-Bonn] Keypair 7 destroyed for peer 1
2021-09-16 10:29:55.885186: [TUN] [PI-Bonn] Keypair 9 created for peer 1
2021-09-16 10:29:55.885186: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:31:58.187373: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:31:58.192647: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:31:58.192647: [TUN] [PI-Bonn] Keypair 8 destroyed for peer 1
2021-09-16 10:31:58.192647: [TUN] [PI-Bonn] Keypair 10 created for peer 1
2021-09-16 10:31:58.192647: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:33:58.561983: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:33:58.566612: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:33:58.566612: [TUN] [PI-Bonn] Keypair 9 destroyed for peer 1
2021-09-16 10:33:58.566612: [TUN] [PI-Bonn] Keypair 11 created for peer 1
2021-09-16 10:33:58.566612: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:35:58.811610: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:35:58.822218: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:35:58.822218: [TUN] [PI-Bonn] Keypair 10 destroyed for peer 1
2021-09-16 10:35:58.822218: [TUN] [PI-Bonn] Keypair 12 created for peer 1
2021-09-16 10:35:58.822218: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:37:59.098110: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:37:59.102310: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:37:59.102310: [TUN] [PI-Bonn] Keypair 11 destroyed for peer 1
2021-09-16 10:37:59.102310: [TUN] [PI-Bonn] Keypair 13 created for peer 1
2021-09-16 10:37:59.102310: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:39:59.319121: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:39:59.320697: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:39:59.320697: [TUN] [PI-Bonn] Keypair 12 destroyed for peer 1
2021-09-16 10:39:59.320697: [TUN] [PI-Bonn] Keypair 14 created for peer 1
2021-09-16 10:39:59.320697: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:41:59.627288: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:41:59.640710: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:41:59.640710: [TUN] [PI-Bonn] Keypair 13 destroyed for peer 1
2021-09-16 10:41:59.640710: [TUN] [PI-Bonn] Keypair 15 created for peer 1
2021-09-16 10:41:59.640710: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:43:59.674148: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:43:59.681844: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:43:59.681844: [TUN] [PI-Bonn] Keypair 14 destroyed for peer 1
2021-09-16 10:43:59.681844: [TUN] [PI-Bonn] Keypair 16 created for peer 1
2021-09-16 10:43:59.681844: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:45:59.684596: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:45:59.689094: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:45:59.689094: [TUN] [PI-Bonn] Keypair 15 destroyed for peer 1
2021-09-16 10:45:59.689094: [TUN] [PI-Bonn] Keypair 17 created for peer 1
2021-09-16 10:45:59.689094: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:48:00.445533: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:48:00.451983: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:48:00.451983: [TUN] [PI-Bonn] Keypair 16 destroyed for peer 1
2021-09-16 10:48:00.451983: [TUN] [PI-Bonn] Keypair 18 created for peer 1
2021-09-16 10:48:00.451983: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:50:00.690437: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:50:00.697835: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:50:00.697835: [TUN] [PI-Bonn] Keypair 17 destroyed for peer 1
2021-09-16 10:50:00.697835: [TUN] [PI-Bonn] Keypair 19 created for peer 1
2021-09-16 10:50:00.697835: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:52:00.967813: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:52:00.994591: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:52:00.994591: [TUN] [PI-Bonn] Keypair 18 destroyed for peer 1
2021-09-16 10:52:00.994591: [TUN] [PI-Bonn] Keypair 20 created for peer 1
2021-09-16 10:52:00.994591: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:54:01.266040: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:54:01.273862: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:54:01.273862: [TUN] [PI-Bonn] Keypair 19 destroyed for peer 1
2021-09-16 10:54:01.273862: [TUN] [PI-Bonn] Keypair 21 created for peer 1
2021-09-16 10:54:01.273862: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:56:01.550364: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:56:01.558697: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:56:01.558697: [TUN] [PI-Bonn] Keypair 20 destroyed for peer 1
2021-09-16 10:56:01.558697: [TUN] [PI-Bonn] Keypair 22 created for peer 1
2021-09-16 10:56:01.558697: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 10:58:01.818588: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 10:58:01.835344: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 10:58:01.835344: [TUN] [PI-Bonn] Keypair 21 destroyed for peer 1
2021-09-16 10:58:01.835344: [TUN] [PI-Bonn] Keypair 23 created for peer 1
2021-09-16 10:58:01.835344: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:00:02.122209: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:00:02.130447: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:00:02.130447: [TUN] [PI-Bonn] Keypair 22 destroyed for peer 1
2021-09-16 11:00:02.130447: [TUN] [PI-Bonn] Keypair 24 created for peer 1
2021-09-16 11:00:02.130447: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:02:02.408125: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:02:02.417587: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:02:02.417587: [TUN] [PI-Bonn] Keypair 23 destroyed for peer 1
2021-09-16 11:02:02.417587: [TUN] [PI-Bonn] Keypair 25 created for peer 1
2021-09-16 11:02:02.417587: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:04:02.705364: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:04:02.712527: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:04:02.712527: [TUN] [PI-Bonn] Keypair 24 destroyed for peer 1
2021-09-16 11:04:02.712527: [TUN] [PI-Bonn] Keypair 26 created for peer 1
2021-09-16 11:04:02.712527: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:06:02.986140: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:06:02.996496: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:06:02.996496: [TUN] [PI-Bonn] Keypair 25 destroyed for peer 1
2021-09-16 11:06:02.996496: [TUN] [PI-Bonn] Keypair 27 created for peer 1
2021-09-16 11:06:02.996496: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:08:03.288825: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:08:03.298513: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:08:03.298513: [TUN] [PI-Bonn] Keypair 26 destroyed for peer 1
2021-09-16 11:08:03.298513: [TUN] [PI-Bonn] Keypair 28 created for peer 1
2021-09-16 11:08:03.298513: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:10:03.600858: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:10:03.610711: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:10:03.610711: [TUN] [PI-Bonn] Keypair 27 destroyed for peer 1
2021-09-16 11:10:03.610711: [TUN] [PI-Bonn] Keypair 29 created for peer 1
2021-09-16 11:10:03.610711: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:12:03.886314: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:12:03.890281: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:12:03.890281: [TUN] [PI-Bonn] Keypair 28 destroyed for peer 1
2021-09-16 11:12:03.890281: [TUN] [PI-Bonn] Keypair 30 created for peer 1
2021-09-16 11:12:03.890281: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:14:04.683480: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:14:04.697574: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:14:04.697574: [TUN] [PI-Bonn] Keypair 29 destroyed for peer 1
2021-09-16 11:14:04.697574: [TUN] [PI-Bonn] Keypair 31 created for peer 1
2021-09-16 11:14:04.697574: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:16:09.452536: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:16:09.459963: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:16:09.459963: [TUN] [PI-Bonn] Keypair 30 destroyed for peer 1
2021-09-16 11:16:09.459963: [TUN] [PI-Bonn] Keypair 32 created for peer 1
2021-09-16 11:16:09.459963: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:18:09.735468: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:18:09.745321: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:18:09.745321: [TUN] [PI-Bonn] Keypair 31 destroyed for peer 1
2021-09-16 11:18:09.745321: [TUN] [PI-Bonn] Keypair 33 created for peer 1
2021-09-16 11:18:09.745321: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:20:10.074264: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:20:10.085785: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:20:10.085785: [TUN] [PI-Bonn] Keypair 32 destroyed for peer 1
2021-09-16 11:20:10.085785: [TUN] [PI-Bonn] Keypair 34 created for peer 1
2021-09-16 11:20:10.085785: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:22:10.334775: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:22:10.344580: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:22:10.344580: [TUN] [PI-Bonn] Keypair 33 destroyed for peer 1
2021-09-16 11:22:10.344580: [TUN] [PI-Bonn] Keypair 35 created for peer 1
2021-09-16 11:22:10.344580: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:24:10.640765: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:24:10.651268: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:24:10.651268: [TUN] [PI-Bonn] Keypair 34 destroyed for peer 1
2021-09-16 11:24:10.651268: [TUN] [PI-Bonn] Keypair 36 created for peer 1
2021-09-16 11:24:10.651268: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:26:10.948105: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:26:10.949058: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:26:10.949058: [TUN] [PI-Bonn] Keypair 35 destroyed for peer 1
2021-09-16 11:26:10.949058: [TUN] [PI-Bonn] Keypair 37 created for peer 1
2021-09-16 11:26:10.949058: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:28:11.230866: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:28:11.239780: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:28:11.239780: [TUN] [PI-Bonn] Keypair 36 destroyed for peer 1
2021-09-16 11:28:11.239780: [TUN] [PI-Bonn] Keypair 38 created for peer 1
2021-09-16 11:28:11.239780: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:30:11.547052: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:30:11.558152: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:30:11.558152: [TUN] [PI-Bonn] Keypair 37 destroyed for peer 1
2021-09-16 11:30:11.558152: [TUN] [PI-Bonn] Keypair 39 created for peer 1
2021-09-16 11:30:11.558152: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:32:11.864725: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:32:11.877355: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:32:11.877355: [TUN] [PI-Bonn] Keypair 38 destroyed for peer 1
2021-09-16 11:32:11.877355: [TUN] [PI-Bonn] Keypair 40 created for peer 1
2021-09-16 11:32:11.877355: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:34:12.188756: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:34:12.196192: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:34:12.196192: [TUN] [PI-Bonn] Keypair 39 destroyed for peer 1
2021-09-16 11:34:12.196192: [TUN] [PI-Bonn] Keypair 41 created for peer 1
2021-09-16 11:34:12.196192: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:36:12.511045: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:36:12.538917: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:36:12.538917: [TUN] [PI-Bonn] Keypair 40 destroyed for peer 1
2021-09-16 11:36:12.538917: [TUN] [PI-Bonn] Keypair 42 created for peer 1
2021-09-16 11:36:12.538917: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:38:12.812040: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:38:12.818657: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:38:12.818657: [TUN] [PI-Bonn] Keypair 41 destroyed for peer 1
2021-09-16 11:38:12.818657: [TUN] [PI-Bonn] Keypair 43 created for peer 1
2021-09-16 11:38:12.818657: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:40:13.073449: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:40:13.075970: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:40:13.075970: [TUN] [PI-Bonn] Keypair 42 destroyed for peer 1
2021-09-16 11:40:13.075970: [TUN] [PI-Bonn] Keypair 44 created for peer 1
2021-09-16 11:40:13.075970: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:42:13.371860: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:42:13.382600: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:42:13.382600: [TUN] [PI-Bonn] Keypair 43 destroyed for peer 1
2021-09-16 11:42:13.382600: [TUN] [PI-Bonn] Keypair 45 created for peer 1
2021-09-16 11:42:13.382600: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:44:13.625806: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:44:13.636884: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:44:13.636884: [TUN] [PI-Bonn] Keypair 44 destroyed for peer 1
2021-09-16 11:44:13.636884: [TUN] [PI-Bonn] Keypair 46 created for peer 1
2021-09-16 11:44:13.636884: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:46:13.889579: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:46:13.897796: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:46:13.897796: [TUN] [PI-Bonn] Keypair 45 destroyed for peer 1
2021-09-16 11:46:13.897796: [TUN] [PI-Bonn] Keypair 47 created for peer 1
2021-09-16 11:46:13.897796: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:48:14.163424: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:48:14.180859: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:48:14.180859: [TUN] [PI-Bonn] Keypair 46 destroyed for peer 1
2021-09-16 11:48:14.180859: [TUN] [PI-Bonn] Keypair 48 created for peer 1
2021-09-16 11:48:14.180859: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:50:14.675216: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:50:14.681664: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:50:14.681664: [TUN] [PI-Bonn] Keypair 47 destroyed for peer 1
2021-09-16 11:50:14.681664: [TUN] [PI-Bonn] Keypair 49 created for peer 1
2021-09-16 11:50:14.681664: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:52:14.711887: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:52:14.719699: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:52:14.719699: [TUN] [PI-Bonn] Keypair 48 destroyed for peer 1
2021-09-16 11:52:14.719699: [TUN] [PI-Bonn] Keypair 50 created for peer 1
2021-09-16 11:52:14.719699: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:54:14.951066: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:54:14.953077: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:54:14.953077: [TUN] [PI-Bonn] Keypair 49 destroyed for peer 1
2021-09-16 11:54:14.953077: [TUN] [PI-Bonn] Keypair 51 created for peer 1
2021-09-16 11:54:14.953077: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:56:14.973986: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:56:14.976006: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:56:14.976006: [TUN] [PI-Bonn] Keypair 50 destroyed for peer 1
2021-09-16 11:56:14.976006: [TUN] [PI-Bonn] Keypair 52 created for peer 1
2021-09-16 11:56:14.976006: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 11:58:15.391166: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 11:58:15.394164: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 11:58:15.394164: [TUN] [PI-Bonn] Keypair 51 destroyed for peer 1
2021-09-16 11:58:15.394164: [TUN] [PI-Bonn] Keypair 53 created for peer 1
2021-09-16 11:58:15.394164: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:00:15.690332: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:00:15.713126: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:00:15.713126: [TUN] [PI-Bonn] Keypair 52 destroyed for peer 1
2021-09-16 12:00:15.713126: [TUN] [PI-Bonn] Keypair 54 created for peer 1
2021-09-16 12:00:15.713126: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:02:15.853156: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:02:15.855956: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:02:15.855956: [TUN] [PI-Bonn] Keypair 53 destroyed for peer 1
2021-09-16 12:02:15.855956: [TUN] [PI-Bonn] Keypair 55 created for peer 1
2021-09-16 12:02:15.855956: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:04:16.246077: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:04:16.258494: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:04:16.258494: [TUN] [PI-Bonn] Keypair 54 destroyed for peer 1
2021-09-16 12:04:16.258494: [TUN] [PI-Bonn] Keypair 56 created for peer 1
2021-09-16 12:04:16.258494: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:06:16.551929: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:06:16.553489: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:06:16.553489: [TUN] [PI-Bonn] Keypair 55 destroyed for peer 1
2021-09-16 12:06:16.553489: [TUN] [PI-Bonn] Keypair 57 created for peer 1
2021-09-16 12:06:16.553489: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:08:16.824916: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:08:16.835468: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:08:16.835468: [TUN] [PI-Bonn] Keypair 56 destroyed for peer 1
2021-09-16 12:08:16.835468: [TUN] [PI-Bonn] Keypair 58 created for peer 1
2021-09-16 12:08:16.835468: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:10:17.100149: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:10:17.104537: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:10:17.104537: [TUN] [PI-Bonn] Keypair 57 destroyed for peer 1
2021-09-16 12:10:17.104537: [TUN] [PI-Bonn] Keypair 59 created for peer 1
2021-09-16 12:10:17.104537: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:12:17.325383: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:12:17.340192: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:12:17.340192: [TUN] [PI-Bonn] Keypair 58 destroyed for peer 1
2021-09-16 12:12:17.340192: [TUN] [PI-Bonn] Keypair 60 created for peer 1
2021-09-16 12:12:17.340192: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:14:17.610278: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:14:17.621513: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:14:17.621513: [TUN] [PI-Bonn] Keypair 59 destroyed for peer 1
2021-09-16 12:14:17.621513: [TUN] [PI-Bonn] Keypair 61 created for peer 1
2021-09-16 12:14:17.621513: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:16:17.717864: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:16:17.724230: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:16:17.724230: [TUN] [PI-Bonn] Keypair 60 destroyed for peer 1
2021-09-16 12:16:17.724230: [TUN] [PI-Bonn] Keypair 62 created for peer 1
2021-09-16 12:16:17.724230: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:18:18.172335: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:18:18.184628: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:18:18.184628: [TUN] [PI-Bonn] Keypair 61 destroyed for peer 1
2021-09-16 12:18:18.184628: [TUN] [PI-Bonn] Keypair 63 created for peer 1
2021-09-16 12:18:18.184628: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:20:18.486072: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:20:18.491092: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:20:18.491092: [TUN] [PI-Bonn] Keypair 62 destroyed for peer 1
2021-09-16 12:20:18.491092: [TUN] [PI-Bonn] Keypair 64 created for peer 1
2021-09-16 12:20:18.491092: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:22:18.763952: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:22:18.773332: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:22:18.773332: [TUN] [PI-Bonn] Keypair 63 destroyed for peer 1
2021-09-16 12:22:18.773332: [TUN] [PI-Bonn] Keypair 65 created for peer 1
2021-09-16 12:22:18.773332: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:24:19.093725: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:24:19.099418: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:24:19.099418: [TUN] [PI-Bonn] Keypair 64 destroyed for peer 1
2021-09-16 12:24:19.099418: [TUN] [PI-Bonn] Keypair 66 created for peer 1
2021-09-16 12:24:19.099418: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:26:19.375910: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:26:19.385246: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:26:19.385246: [TUN] [PI-Bonn] Keypair 65 destroyed for peer 1
2021-09-16 12:26:19.385246: [TUN] [PI-Bonn] Keypair 67 created for peer 1
2021-09-16 12:26:19.385246: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:28:19.678771: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:28:19.686422: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:28:19.686422: [TUN] [PI-Bonn] Keypair 66 destroyed for peer 1
2021-09-16 12:28:19.686422: [TUN] [PI-Bonn] Keypair 68 created for peer 1
2021-09-16 12:28:19.686422: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:30:19.974922: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:30:19.984750: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:30:19.984750: [TUN] [PI-Bonn] Keypair 67 destroyed for peer 1
2021-09-16 12:30:19.984750: [TUN] [PI-Bonn] Keypair 69 created for peer 1
2021-09-16 12:30:19.984750: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:32:20.291894: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:32:20.301921: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:32:20.301921: [TUN] [PI-Bonn] Keypair 68 destroyed for peer 1
2021-09-16 12:32:20.301921: [TUN] [PI-Bonn] Keypair 70 created for peer 1
2021-09-16 12:32:20.301921: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:34:20.623971: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:34:20.633922: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:34:20.633922: [TUN] [PI-Bonn] Keypair 69 destroyed for peer 1
2021-09-16 12:34:20.633922: [TUN] [PI-Bonn] Keypair 71 created for peer 1
2021-09-16 12:34:20.633922: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:36:20.874266: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:36:20.884693: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:36:20.884693: [TUN] [PI-Bonn] Keypair 70 destroyed for peer 1
2021-09-16 12:36:20.884693: [TUN] [PI-Bonn] Keypair 72 created for peer 1
2021-09-16 12:36:20.884693: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:38:21.176876: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:38:21.187728: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:38:21.187728: [TUN] [PI-Bonn] Keypair 71 destroyed for peer 1
2021-09-16 12:38:21.187728: [TUN] [PI-Bonn] Keypair 73 created for peer 1
2021-09-16 12:38:21.187728: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:40:21.502794: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:40:21.513776: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:40:21.513776: [TUN] [PI-Bonn] Keypair 72 destroyed for peer 1
2021-09-16 12:40:21.513776: [TUN] [PI-Bonn] Keypair 74 created for peer 1
2021-09-16 12:40:21.513776: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:42:21.837465: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:42:21.844553: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:42:21.844553: [TUN] [PI-Bonn] Keypair 73 destroyed for peer 1
2021-09-16 12:42:21.844553: [TUN] [PI-Bonn] Keypair 75 created for peer 1
2021-09-16 12:42:21.844553: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:44:22.142909: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:44:22.148085: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:44:22.148085: [TUN] [PI-Bonn] Keypair 74 destroyed for peer 1
2021-09-16 12:44:22.148085: [TUN] [PI-Bonn] Keypair 76 created for peer 1
2021-09-16 12:44:22.148085: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:46:22.437254: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:46:22.447063: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:46:22.447063: [TUN] [PI-Bonn] Keypair 75 destroyed for peer 1
2021-09-16 12:46:22.447063: [TUN] [PI-Bonn] Keypair 77 created for peer 1
2021-09-16 12:46:22.447063: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:48:22.706603: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:48:22.714029: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:48:22.714029: [TUN] [PI-Bonn] Keypair 76 destroyed for peer 1
2021-09-16 12:48:22.714029: [TUN] [PI-Bonn] Keypair 78 created for peer 1
2021-09-16 12:48:22.714029: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:50:22.736428: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:50:22.746452: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:50:22.746452: [TUN] [PI-Bonn] Keypair 77 destroyed for peer 1
2021-09-16 12:50:22.746452: [TUN] [PI-Bonn] Keypair 79 created for peer 1
2021-09-16 12:50:22.746452: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:52:22.752998: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:52:22.756487: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:52:22.756487: [TUN] [PI-Bonn] Keypair 78 destroyed for peer 1
2021-09-16 12:52:22.756487: [TUN] [PI-Bonn] Keypair 80 created for peer 1
2021-09-16 12:52:22.756487: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:54:23.381269: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:54:23.382942: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:54:23.382942: [TUN] [PI-Bonn] Keypair 79 destroyed for peer 1
2021-09-16 12:54:23.382942: [TUN] [PI-Bonn] Keypair 81 created for peer 1
2021-09-16 12:54:23.382942: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:56:23.546706: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:56:23.548323: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:56:23.548323: [TUN] [PI-Bonn] Keypair 80 destroyed for peer 1
2021-09-16 12:56:23.548323: [TUN] [PI-Bonn] Keypair 82 created for peer 1
2021-09-16 12:56:23.548323: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 12:58:23.554226: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 12:58:23.559613: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 12:58:23.559613: [TUN] [PI-Bonn] Keypair 81 destroyed for peer 1
2021-09-16 12:58:23.559613: [TUN] [PI-Bonn] Keypair 83 created for peer 1
2021-09-16 12:58:23.559613: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:00:23.564839: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:00:23.582385: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:00:23.582385: [TUN] [PI-Bonn] Keypair 82 destroyed for peer 1
2021-09-16 13:00:23.582385: [TUN] [PI-Bonn] Keypair 84 created for peer 1
2021-09-16 13:00:23.582385: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:02:23.602247: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:02:23.606632: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:02:23.606632: [TUN] [PI-Bonn] Keypair 83 destroyed for peer 1
2021-09-16 13:02:23.606632: [TUN] [PI-Bonn] Keypair 85 created for peer 1
2021-09-16 13:02:23.606632: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:04:23.624834: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:04:23.627800: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:04:23.627800: [TUN] [PI-Bonn] Keypair 84 destroyed for peer 1
2021-09-16 13:04:23.627800: [TUN] [PI-Bonn] Keypair 86 created for peer 1
2021-09-16 13:04:23.627800: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:06:23.675379: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:06:23.682353: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:06:23.682353: [TUN] [PI-Bonn] Keypair 85 destroyed for peer 1
2021-09-16 13:06:23.682353: [TUN] [PI-Bonn] Keypair 87 created for peer 1
2021-09-16 13:06:23.682353: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:08:23.705795: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:08:23.714770: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:08:23.714770: [TUN] [PI-Bonn] Keypair 86 destroyed for peer 1
2021-09-16 13:08:23.714770: [TUN] [PI-Bonn] Keypair 88 created for peer 1
2021-09-16 13:08:23.714770: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:10:23.737123: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:10:23.742005: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:10:23.742005: [TUN] [PI-Bonn] Keypair 87 destroyed for peer 1
2021-09-16 13:10:23.742005: [TUN] [PI-Bonn] Keypair 89 created for peer 1
2021-09-16 13:10:23.742005: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:12:23.782437: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:12:23.786748: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:12:23.786748: [TUN] [PI-Bonn] Keypair 88 destroyed for peer 1
2021-09-16 13:12:23.786748: [TUN] [PI-Bonn] Keypair 90 created for peer 1
2021-09-16 13:12:23.786748: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:14:23.804080: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:14:23.808564: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:14:23.808564: [TUN] [PI-Bonn] Keypair 89 destroyed for peer 1
2021-09-16 13:14:23.808564: [TUN] [PI-Bonn] Keypair 91 created for peer 1
2021-09-16 13:14:23.808564: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:16:23.814861: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:16:23.818019: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:16:23.818019: [TUN] [PI-Bonn] Keypair 90 destroyed for peer 1
2021-09-16 13:16:23.818019: [TUN] [PI-Bonn] Keypair 92 created for peer 1
2021-09-16 13:16:23.818019: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:18:23.881946: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:18:23.886624: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:18:23.887134: [TUN] [PI-Bonn] Keypair 91 destroyed for peer 1
2021-09-16 13:18:23.887134: [TUN] [PI-Bonn] Keypair 93 created for peer 1
2021-09-16 13:18:23.887134: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:20:23.961293: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:20:23.966522: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:20:23.966522: [TUN] [PI-Bonn] Keypair 92 destroyed for peer 1
2021-09-16 13:20:23.966522: [TUN] [PI-Bonn] Keypair 94 created for peer 1
2021-09-16 13:20:23.966522: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:22:23.968336: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:22:23.972441: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:22:23.972441: [TUN] [PI-Bonn] Keypair 93 destroyed for peer 1
2021-09-16 13:22:23.972441: [TUN] [PI-Bonn] Keypair 95 created for peer 1
2021-09-16 13:22:23.972441: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:24:23.976214: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:24:23.982714: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:24:23.982714: [TUN] [PI-Bonn] Keypair 94 destroyed for peer 1
2021-09-16 13:24:23.982714: [TUN] [PI-Bonn] Keypair 96 created for peer 1
2021-09-16 13:24:23.982714: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:26:24.018016: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:26:24.023240: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:26:24.023240: [TUN] [PI-Bonn] Keypair 95 destroyed for peer 1
2021-09-16 13:26:24.023240: [TUN] [PI-Bonn] Keypair 97 created for peer 1
2021-09-16 13:26:24.023240: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:28:24.073955: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:28:24.077285: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:28:24.077285: [TUN] [PI-Bonn] Keypair 96 destroyed for peer 1
2021-09-16 13:28:24.077285: [TUN] [PI-Bonn] Keypair 98 created for peer 1
2021-09-16 13:28:24.077285: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:30:24.084028: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:30:24.088222: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:30:24.088222: [TUN] [PI-Bonn] Keypair 97 destroyed for peer 1
2021-09-16 13:30:24.088222: [TUN] [PI-Bonn] Keypair 99 created for peer 1
2021-09-16 13:30:24.088222: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:32:24.093258: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:32:24.097678: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:32:24.097678: [TUN] [PI-Bonn] Keypair 98 destroyed for peer 1
2021-09-16 13:32:24.097678: [TUN] [PI-Bonn] Keypair 100 created for peer 1
2021-09-16 13:32:24.097678: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:34:24.150719: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:34:24.159193: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:34:24.159193: [TUN] [PI-Bonn] Keypair 99 destroyed for peer 1
2021-09-16 13:34:24.159193: [TUN] [PI-Bonn] Keypair 101 created for peer 1
2021-09-16 13:34:24.159193: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:36:24.192416: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:36:24.196461: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:36:24.196461: [TUN] [PI-Bonn] Keypair 100 destroyed for peer 1
2021-09-16 13:36:24.196461: [TUN] [PI-Bonn] Keypair 102 created for peer 1
2021-09-16 13:36:24.196461: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:38:24.216801: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:38:24.221417: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:38:24.221417: [TUN] [PI-Bonn] Keypair 101 destroyed for peer 1
2021-09-16 13:38:24.221417: [TUN] [PI-Bonn] Keypair 103 created for peer 1
2021-09-16 13:38:24.221417: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:40:24.223659: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:40:24.228613: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:40:24.228613: [TUN] [PI-Bonn] Keypair 102 destroyed for peer 1
2021-09-16 13:40:24.228613: [TUN] [PI-Bonn] Keypair 104 created for peer 1
2021-09-16 13:40:24.228613: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:42:24.236685: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:42:24.242163: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:42:24.242163: [TUN] [PI-Bonn] Keypair 103 destroyed for peer 1
2021-09-16 13:42:24.242163: [TUN] [PI-Bonn] Keypair 105 created for peer 1
2021-09-16 13:42:24.242163: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:44:24.294020: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:44:24.298837: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:44:24.298837: [TUN] [PI-Bonn] Keypair 104 destroyed for peer 1
2021-09-16 13:44:24.298837: [TUN] [PI-Bonn] Keypair 106 created for peer 1
2021-09-16 13:44:24.298837: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:46:24.333588: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:46:24.338270: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:46:24.338270: [TUN] [PI-Bonn] Keypair 105 destroyed for peer 1
2021-09-16 13:46:24.338270: [TUN] [PI-Bonn] Keypair 107 created for peer 1
2021-09-16 13:46:24.338270: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:48:24.406086: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:48:24.417631: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:48:24.417631: [TUN] [PI-Bonn] Keypair 106 destroyed for peer 1
2021-09-16 13:48:24.417631: [TUN] [PI-Bonn] Keypair 108 created for peer 1
2021-09-16 13:48:24.417631: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:50:24.468883: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:50:24.474237: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:50:24.474237: [TUN] [PI-Bonn] Keypair 107 destroyed for peer 1
2021-09-16 13:50:24.474237: [TUN] [PI-Bonn] Keypair 109 created for peer 1
2021-09-16 13:50:24.474237: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:52:24.475625: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:52:24.479615: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:52:24.479615: [TUN] [PI-Bonn] Keypair 108 destroyed for peer 1
2021-09-16 13:52:24.479615: [TUN] [PI-Bonn] Keypair 110 created for peer 1
2021-09-16 13:52:24.479615: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:54:24.519325: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:54:24.523710: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:54:24.523710: [TUN] [PI-Bonn] Keypair 109 destroyed for peer 1
2021-09-16 13:54:24.523710: [TUN] [PI-Bonn] Keypair 111 created for peer 1
2021-09-16 13:54:24.523710: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:56:24.524430: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:56:24.528414: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:56:24.528414: [TUN] [PI-Bonn] Keypair 110 destroyed for peer 1
2021-09-16 13:56:24.528414: [TUN] [PI-Bonn] Keypair 112 created for peer 1
2021-09-16 13:56:24.528414: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 13:58:24.532405: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 13:58:24.536931: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 13:58:24.536931: [TUN] [PI-Bonn] Keypair 111 destroyed for peer 1
2021-09-16 13:58:24.536931: [TUN] [PI-Bonn] Keypair 113 created for peer 1
2021-09-16 13:58:24.536931: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:00:24.569728: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:00:24.575124: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:00:24.575124: [TUN] [PI-Bonn] Keypair 112 destroyed for peer 1
2021-09-16 14:00:24.575124: [TUN] [PI-Bonn] Keypair 114 created for peer 1
2021-09-16 14:00:24.575124: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:02:24.615662: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:02:24.619962: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:02:24.619962: [TUN] [PI-Bonn] Keypair 113 destroyed for peer 1
2021-09-16 14:02:24.619962: [TUN] [PI-Bonn] Keypair 115 created for peer 1
2021-09-16 14:02:24.619962: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:04:24.631458: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:04:24.636757: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:04:24.636757: [TUN] [PI-Bonn] Keypair 114 destroyed for peer 1
2021-09-16 14:04:24.636757: [TUN] [PI-Bonn] Keypair 116 created for peer 1
2021-09-16 14:04:24.636757: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:06:24.675253: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:06:24.680118: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:06:24.680118: [TUN] [PI-Bonn] Keypair 115 destroyed for peer 1
2021-09-16 14:06:24.680118: [TUN] [PI-Bonn] Keypair 117 created for peer 1
2021-09-16 14:06:24.680118: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:08:25.333337: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:08:25.340292: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:08:25.340292: [TUN] [PI-Bonn] Keypair 116 destroyed for peer 1
2021-09-16 14:08:25.340292: [TUN] [PI-Bonn] Keypair 118 created for peer 1
2021-09-16 14:08:25.340292: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:10:25.424704: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:10:25.430989: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:10:25.430989: [TUN] [PI-Bonn] Keypair 117 destroyed for peer 1
2021-09-16 14:10:25.430989: [TUN] [PI-Bonn] Keypair 119 created for peer 1
2021-09-16 14:10:25.430989: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:12:25.862102: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:12:25.871944: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:12:25.871944: [TUN] [PI-Bonn] Keypair 118 destroyed for peer 1
2021-09-16 14:12:25.871944: [TUN] [PI-Bonn] Keypair 120 created for peer 1
2021-09-16 14:12:25.871944: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:14:29.147030: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:14:29.152059: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:14:29.152059: [TUN] [PI-Bonn] Keypair 119 destroyed for peer 1
2021-09-16 14:14:29.152059: [TUN] [PI-Bonn] Keypair 121 created for peer 1
2021-09-16 14:14:29.152059: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:16:29.840399: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:16:29.847316: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:16:29.847316: [TUN] [PI-Bonn] Keypair 120 destroyed for peer 1
2021-09-16 14:16:29.847316: [TUN] [PI-Bonn] Keypair 122 created for peer 1
2021-09-16 14:16:29.847316: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:18:32.984445: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:18:32.995742: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:18:32.995742: [TUN] [PI-Bonn] Keypair 121 destroyed for peer 1
2021-09-16 14:18:32.995742: [TUN] [PI-Bonn] Keypair 123 created for peer 1
2021-09-16 14:18:32.995742: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:20:33.244641: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:20:33.265075: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:20:33.265075: [TUN] [PI-Bonn] Keypair 122 destroyed for peer 1
2021-09-16 14:20:33.265075: [TUN] [PI-Bonn] Keypair 124 created for peer 1
2021-09-16 14:20:33.265075: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:22:33.539104: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:22:33.554709: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:22:33.554709: [TUN] [PI-Bonn] Keypair 123 destroyed for peer 1
2021-09-16 14:22:33.554709: [TUN] [PI-Bonn] Keypair 125 created for peer 1
2021-09-16 14:22:33.554709: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:24:33.845724: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:24:33.859099: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:24:33.859099: [TUN] [PI-Bonn] Keypair 124 destroyed for peer 1
2021-09-16 14:24:33.859099: [TUN] [PI-Bonn] Keypair 126 created for peer 1
2021-09-16 14:24:33.859099: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:26:38.244283: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:26:38.254935: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:26:38.254935: [TUN] [PI-Bonn] Keypair 125 destroyed for peer 1
2021-09-16 14:26:38.254935: [TUN] [PI-Bonn] Keypair 127 created for peer 1
2021-09-16 14:26:38.254935: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:28:39.472668: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:28:39.480906: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:28:39.480906: [TUN] [PI-Bonn] Keypair 126 destroyed for peer 1
2021-09-16 14:28:39.480906: [TUN] [PI-Bonn] Keypair 128 created for peer 1
2021-09-16 14:28:39.480906: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:30:39.905205: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:30:39.912530: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:30:39.912530: [TUN] [PI-Bonn] Keypair 127 destroyed for peer 1
2021-09-16 14:30:39.912530: [TUN] [PI-Bonn] Keypair 129 created for peer 1
2021-09-16 14:30:39.912530: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:32:40.046322: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:32:40.061001: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:32:40.061001: [TUN] [PI-Bonn] Keypair 128 destroyed for peer 1
2021-09-16 14:32:40.061001: [TUN] [PI-Bonn] Keypair 130 created for peer 1
2021-09-16 14:32:40.061001: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:34:40.350188: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:34:40.360964: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:34:40.360964: [TUN] [PI-Bonn] Keypair 129 destroyed for peer 1
2021-09-16 14:34:40.360964: [TUN] [PI-Bonn] Keypair 131 created for peer 1
2021-09-16 14:34:40.360964: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:36:40.639643: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:36:40.652015: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:36:40.652015: [TUN] [PI-Bonn] Keypair 130 destroyed for peer 1
2021-09-16 14:36:40.652015: [TUN] [PI-Bonn] Keypair 132 created for peer 1
2021-09-16 14:36:40.652015: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:38:40.910296: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:38:40.911793: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:38:40.911793: [TUN] [PI-Bonn] Keypair 131 destroyed for peer 1
2021-09-16 14:38:40.911793: [TUN] [PI-Bonn] Keypair 133 created for peer 1
2021-09-16 14:38:40.911793: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:40:41.294180: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:40:41.307882: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:40:41.307882: [TUN] [PI-Bonn] Keypair 132 destroyed for peer 1
2021-09-16 14:40:41.307882: [TUN] [PI-Bonn] Keypair 134 created for peer 1
2021-09-16 14:40:41.307882: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:42:41.610829: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:42:41.622083: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:42:41.622083: [TUN] [PI-Bonn] Keypair 133 destroyed for peer 1
2021-09-16 14:42:41.622083: [TUN] [PI-Bonn] Keypair 135 created for peer 1
2021-09-16 14:42:41.622083: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:44:41.937911: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:44:42.002891: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:44:42.002891: [TUN] [PI-Bonn] Keypair 134 destroyed for peer 1
2021-09-16 14:44:42.002891: [TUN] [PI-Bonn] Keypair 136 created for peer 1
2021-09-16 14:44:42.002891: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:46:42.260621: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:46:42.271487: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:46:42.271487: [TUN] [PI-Bonn] Keypair 135 destroyed for peer 1
2021-09-16 14:46:42.271487: [TUN] [PI-Bonn] Keypair 137 created for peer 1
2021-09-16 14:46:42.271487: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:48:42.547674: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:48:42.551461: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:48:42.551461: [TUN] [PI-Bonn] Keypair 136 destroyed for peer 1
2021-09-16 14:48:42.551461: [TUN] [PI-Bonn] Keypair 138 created for peer 1
2021-09-16 14:48:42.551461: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:50:42.828532: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:50:42.840050: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:50:42.840050: [TUN] [PI-Bonn] Keypair 137 destroyed for peer 1
2021-09-16 14:50:42.840050: [TUN] [PI-Bonn] Keypair 139 created for peer 1
2021-09-16 14:50:42.840050: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:52:43.171880: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:52:43.187960: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:52:43.187960: [TUN] [PI-Bonn] Keypair 138 destroyed for peer 1
2021-09-16 14:52:43.187960: [TUN] [PI-Bonn] Keypair 140 created for peer 1
2021-09-16 14:52:43.187960: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:54:43.511316: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:54:43.534044: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:54:43.534044: [TUN] [PI-Bonn] Keypair 139 destroyed for peer 1
2021-09-16 14:54:43.534044: [TUN] [PI-Bonn] Keypair 141 created for peer 1
2021-09-16 14:54:43.534044: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:56:43.825669: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:56:43.836820: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:56:43.836820: [TUN] [PI-Bonn] Keypair 140 destroyed for peer 1
2021-09-16 14:56:43.836820: [TUN] [PI-Bonn] Keypair 142 created for peer 1
2021-09-16 14:56:43.836820: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 14:58:44.137113: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 14:58:44.147308: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 14:58:44.147308: [TUN] [PI-Bonn] Keypair 141 destroyed for peer 1
2021-09-16 14:58:44.147308: [TUN] [PI-Bonn] Keypair 143 created for peer 1
2021-09-16 14:58:44.147308: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:00:44.398861: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:00:44.409588: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:00:44.409588: [TUN] [PI-Bonn] Keypair 142 destroyed for peer 1
2021-09-16 15:00:44.409588: [TUN] [PI-Bonn] Keypair 144 created for peer 1
2021-09-16 15:00:44.409588: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:02:44.667299: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:02:44.680000: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:02:44.680000: [TUN] [PI-Bonn] Keypair 143 destroyed for peer 1
2021-09-16 15:02:44.680000: [TUN] [PI-Bonn] Keypair 145 created for peer 1
2021-09-16 15:02:44.680000: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:04:44.944450: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:04:44.956368: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:04:44.956368: [TUN] [PI-Bonn] Keypair 144 destroyed for peer 1
2021-09-16 15:04:44.956368: [TUN] [PI-Bonn] Keypair 146 created for peer 1
2021-09-16 15:04:44.956368: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:06:45.002044: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:06:45.008918: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:06:45.008918: [TUN] [PI-Bonn] Keypair 145 destroyed for peer 1
2021-09-16 15:06:45.008952: [TUN] [PI-Bonn] Keypair 147 created for peer 1
2021-09-16 15:06:45.008952: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:08:45.136540: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:08:45.144692: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:08:45.144692: [TUN] [PI-Bonn] Keypair 146 destroyed for peer 1
2021-09-16 15:08:45.144692: [TUN] [PI-Bonn] Keypair 148 created for peer 1
2021-09-16 15:08:45.144692: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:10:45.388751: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:10:45.394188: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:10:45.394188: [TUN] [PI-Bonn] Keypair 147 destroyed for peer 1
2021-09-16 15:10:45.394188: [TUN] [PI-Bonn] Keypair 149 created for peer 1
2021-09-16 15:10:45.394188: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:12:46.102908: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:12:46.107035: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:12:46.107035: [TUN] [PI-Bonn] Keypair 148 destroyed for peer 1
2021-09-16 15:12:46.107035: [TUN] [PI-Bonn] Keypair 150 created for peer 1
2021-09-16 15:12:46.107035: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:14:46.407841: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:14:46.413552: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:14:46.413552: [TUN] [PI-Bonn] Keypair 149 destroyed for peer 1
2021-09-16 15:14:46.413552: [TUN] [PI-Bonn] Keypair 151 created for peer 1
2021-09-16 15:14:46.413552: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:16:46.706371: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:16:46.719391: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:16:46.719391: [TUN] [PI-Bonn] Keypair 150 destroyed for peer 1
2021-09-16 15:16:46.719391: [TUN] [PI-Bonn] Keypair 152 created for peer 1
2021-09-16 15:16:46.719391: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:18:47.018462: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:18:47.029307: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:18:47.029307: [TUN] [PI-Bonn] Keypair 151 destroyed for peer 1
2021-09-16 15:18:47.029307: [TUN] [PI-Bonn] Keypair 153 created for peer 1
2021-09-16 15:18:47.029307: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:20:47.348968: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:20:47.364633: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:20:47.364633: [TUN] [PI-Bonn] Keypair 152 destroyed for peer 1
2021-09-16 15:20:47.364633: [TUN] [PI-Bonn] Keypair 154 created for peer 1
2021-09-16 15:20:47.364633: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:22:47.666014: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:22:47.680137: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:22:47.680137: [TUN] [PI-Bonn] Keypair 153 destroyed for peer 1
2021-09-16 15:22:47.680137: [TUN] [PI-Bonn] Keypair 155 created for peer 1
2021-09-16 15:22:47.680137: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:24:47.964034: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:24:47.974525: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:24:47.974525: [TUN] [PI-Bonn] Keypair 154 destroyed for peer 1
2021-09-16 15:24:47.974525: [TUN] [PI-Bonn] Keypair 156 created for peer 1
2021-09-16 15:24:47.974525: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:26:48.235030: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:26:48.247786: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:26:48.247786: [TUN] [PI-Bonn] Keypair 155 destroyed for peer 1
2021-09-16 15:26:48.247786: [TUN] [PI-Bonn] Keypair 157 created for peer 1
2021-09-16 15:26:48.247786: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:28:48.283961: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:28:48.298205: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:28:48.298205: [TUN] [PI-Bonn] Keypair 156 destroyed for peer 1
2021-09-16 15:28:48.298205: [TUN] [PI-Bonn] Keypair 158 created for peer 1
2021-09-16 15:28:48.298205: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:30:48.509005: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:30:48.516660: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:30:48.516660: [TUN] [PI-Bonn] Keypair 157 destroyed for peer 1
2021-09-16 15:30:48.516660: [TUN] [PI-Bonn] Keypair 159 created for peer 1
2021-09-16 15:30:48.516660: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:32:49.132084: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:32:49.142404: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:32:49.142404: [TUN] [PI-Bonn] Keypair 158 destroyed for peer 1
2021-09-16 15:32:49.142404: [TUN] [PI-Bonn] Keypair 160 created for peer 1
2021-09-16 15:32:49.142404: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:34:49.438370: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:34:49.449902: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:34:49.449902: [TUN] [PI-Bonn] Keypair 159 destroyed for peer 1
2021-09-16 15:34:49.449902: [TUN] [PI-Bonn] Keypair 161 created for peer 1
2021-09-16 15:34:49.449902: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:36:51.779523: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:36:51.793241: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:36:51.793241: [TUN] [PI-Bonn] Keypair 160 destroyed for peer 1
2021-09-16 15:36:51.793241: [TUN] [PI-Bonn] Keypair 162 created for peer 1
2021-09-16 15:36:51.793241: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:38:53.366280: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:38:53.377868: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:38:53.377868: [TUN] [PI-Bonn] Keypair 161 destroyed for peer 1
2021-09-16 15:38:53.377868: [TUN] [PI-Bonn] Keypair 163 created for peer 1
2021-09-16 15:38:53.377868: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:40:55.319219: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:40:55.330206: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:40:55.330206: [TUN] [PI-Bonn] Keypair 162 destroyed for peer 1
2021-09-16 15:40:55.330206: [TUN] [PI-Bonn] Keypair 164 created for peer 1
2021-09-16 15:40:55.330206: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:42:55.646652: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:42:55.651445: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:42:55.651445: [TUN] [PI-Bonn] Keypair 163 destroyed for peer 1
2021-09-16 15:42:55.651445: [TUN] [PI-Bonn] Keypair 165 created for peer 1
2021-09-16 15:42:55.651445: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:44:55.895242: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:44:55.906402: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:44:55.906402: [TUN] [PI-Bonn] Keypair 164 destroyed for peer 1
2021-09-16 15:44:55.906402: [TUN] [PI-Bonn] Keypair 166 created for peer 1
2021-09-16 15:44:55.906402: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:46:56.167998: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:46:56.174401: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:46:56.174401: [TUN] [PI-Bonn] Keypair 165 destroyed for peer 1
2021-09-16 15:46:56.174401: [TUN] [PI-Bonn] Keypair 167 created for peer 1
2021-09-16 15:46:56.174401: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:48:56.500380: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:48:56.515780: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:48:56.515780: [TUN] [PI-Bonn] Keypair 166 destroyed for peer 1
2021-09-16 15:48:56.515780: [TUN] [PI-Bonn] Keypair 168 created for peer 1
2021-09-16 15:48:56.515780: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:50:56.826469: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:50:56.832131: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:50:56.832131: [TUN] [PI-Bonn] Keypair 167 destroyed for peer 1
2021-09-16 15:50:56.832131: [TUN] [PI-Bonn] Keypair 169 created for peer 1
2021-09-16 15:50:56.832131: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:52:57.105321: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:52:57.109728: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:52:57.109728: [TUN] [PI-Bonn] Keypair 168 destroyed for peer 1
2021-09-16 15:52:57.109728: [TUN] [PI-Bonn] Keypair 170 created for peer 1
2021-09-16 15:52:57.109728: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:54:57.425100: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:54:57.431072: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:54:57.431072: [TUN] [PI-Bonn] Keypair 169 destroyed for peer 1
2021-09-16 15:54:57.431072: [TUN] [PI-Bonn] Keypair 171 created for peer 1
2021-09-16 15:54:57.431072: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:56:57.750180: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:56:57.761349: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:56:57.761349: [TUN] [PI-Bonn] Keypair 170 destroyed for peer 1
2021-09-16 15:56:57.761349: [TUN] [PI-Bonn] Keypair 172 created for peer 1
2021-09-16 15:56:57.761349: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 15:58:58.114034: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 15:58:58.124143: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 15:58:58.124143: [TUN] [PI-Bonn] Keypair 171 destroyed for peer 1
2021-09-16 15:58:58.124143: [TUN] [PI-Bonn] Keypair 173 created for peer 1
2021-09-16 15:58:58.124143: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:00:58.271780: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:00:58.274788: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:00:58.274788: [TUN] [PI-Bonn] Keypair 172 destroyed for peer 1
2021-09-16 16:00:58.274788: [TUN] [PI-Bonn] Keypair 174 created for peer 1
2021-09-16 16:00:58.274788: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:02:58.733324: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:02:58.743751: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:02:58.743751: [TUN] [PI-Bonn] Keypair 173 destroyed for peer 1
2021-09-16 16:02:58.743751: [TUN] [PI-Bonn] Keypair 175 created for peer 1
2021-09-16 16:02:58.743751: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:04:59.042127: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:04:59.054730: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:04:59.054730: [TUN] [PI-Bonn] Keypair 174 destroyed for peer 1
2021-09-16 16:04:59.054730: [TUN] [PI-Bonn] Keypair 176 created for peer 1
2021-09-16 16:04:59.054730: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:06:59.323033: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:06:59.333686: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:06:59.333686: [TUN] [PI-Bonn] Keypair 175 destroyed for peer 1
2021-09-16 16:06:59.333686: [TUN] [PI-Bonn] Keypair 177 created for peer 1
2021-09-16 16:06:59.333686: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:08:59.878836: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:08:59.884883: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:08:59.884883: [TUN] [PI-Bonn] Keypair 176 destroyed for peer 1
2021-09-16 16:08:59.884883: [TUN] [PI-Bonn] Keypair 178 created for peer 1
2021-09-16 16:08:59.884883: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:10:59.952648: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:10:59.957810: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:10:59.957810: [TUN] [PI-Bonn] Keypair 177 destroyed for peer 1
2021-09-16 16:10:59.957810: [TUN] [PI-Bonn] Keypair 179 created for peer 1
2021-09-16 16:10:59.957810: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:13:00.267745: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:13:00.274423: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:13:00.274423: [TUN] [PI-Bonn] Keypair 178 destroyed for peer 1
2021-09-16 16:13:00.274423: [TUN] [PI-Bonn] Keypair 180 created for peer 1
2021-09-16 16:13:00.274423: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:13:16.117387: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:13:28.411984: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:13:38.645365: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:14:38.562697: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:14:50.844704: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:15:00.553228: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:15:00.571341: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:15:00.571341: [TUN] [PI-Bonn] Keypair 179 destroyed for peer 1
2021-09-16 16:15:00.571341: [TUN] [PI-Bonn] Keypair 181 created for peer 1
2021-09-16 16:15:00.571341: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:15:14.913556: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:15:26.683059: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:15:46.662236: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:16:06.615388: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:16:18.904730: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:16:30.687885: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:16:42.968217: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:16:54.748212: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:17:04.550820: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:17:04.553030: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:17:04.553030: [TUN] [PI-Bonn] Keypair 180 destroyed for peer 1
2021-09-16 16:17:04.553030: [TUN] [PI-Bonn] Keypair 182 created for peer 1
2021-09-16 16:17:04.553030: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:17:27.007698: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:17:38.767417: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:17:50.557975: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:18:02.839358: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:18:18.209359: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:18:43.224412: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:19:03.967152: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:19:28.978179: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:19:28.978378: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:19:28.983667: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:19:28.983667: [TUN] [PI-Bonn] Keypair 181 destroyed for peer 1
2021-09-16 16:19:28.983667: [TUN] [PI-Bonn] Keypair 183 created for peer 1
2021-09-16 16:19:28.983667: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:19:53.985404: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:20:05.203440: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:20:17.492697: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:20:43.978917: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:21:08.985467: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:21:33.996442: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:21:33.996623: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:21:34.001781: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:21:34.001781: [TUN] [PI-Bonn] Keypair 182 destroyed for peer 1
2021-09-16 16:21:34.001781: [TUN] [PI-Bonn] Keypair 184 created for peer 1
2021-09-16 16:21:34.001781: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:21:59.009408: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:22:23.991902: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:22:56.731699: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:23:16.181911: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:23:41.183438: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:23:41.183675: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:23:41.184762: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:23:41.184762: [TUN] [PI-Bonn] Keypair 183 destroyed for peer 1
2021-09-16 16:23:41.184762: [TUN] [PI-Bonn] Keypair 185 created for peer 1
2021-09-16 16:23:41.184762: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:24:04.005632: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:24:22.246466: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:24:47.260865: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:25:04.550100: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:25:29.561807: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:25:44.013937: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:25:44.014053: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:25:44.015307: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:25:44.015307: [TUN] [PI-Bonn] Keypair 184 destroyed for peer 1
2021-09-16 16:25:44.015307: [TUN] [PI-Bonn] Keypair 186 created for peer 1
2021-09-16 16:25:44.015307: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:25:56.961723: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:26:21.976510: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:26:46.987535: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:27:11.993789: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:27:24.023448: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:27:49.034443: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:27:49.034623: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:27:49.036237: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:27:49.036237: [TUN] [PI-Bonn] Keypair 185 destroyed for peer 1
2021-09-16 16:27:49.036237: [TUN] [PI-Bonn] Keypair 187 created for peer 1
2021-09-16 16:27:49.036237: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:28:14.042661: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:28:39.048428: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:29:04.038958: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:29:29.049750: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:29:54.051976: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:29:54.052195: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:29:54.054058: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:29:54.054058: [TUN] [PI-Bonn] Keypair 186 destroyed for peer 1
2021-09-16 16:29:54.054058: [TUN] [PI-Bonn] Keypair 188 created for peer 1
2021-09-16 16:29:54.054058: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:30:19.060231: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:30:44.049618: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:31:09.055271: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:31:34.066597: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:31:59.073656: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:31:59.073876: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:31:59.074928: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:31:59.074928: [TUN] [PI-Bonn] Keypair 187 destroyed for peer 1
2021-09-16 16:31:59.074928: [TUN] [PI-Bonn] Keypair 189 created for peer 1
2021-09-16 16:31:59.074928: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:32:24.061408: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:32:49.068230: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:33:14.074871: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:33:39.085923: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:34:04.076849: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:34:04.077049: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:34:04.078357: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:34:04.078357: [TUN] [PI-Bonn] Keypair 188 destroyed for peer 1
2021-09-16 16:34:04.078357: [TUN] [PI-Bonn] Keypair 190 created for peer 1
2021-09-16 16:34:04.078357: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:34:39.194824: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:34:50.452867: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:35:19.129036: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:35:44.080638: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:36:04.275939: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:36:04.277503: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:36:04.277503: [TUN] [PI-Bonn] Keypair 189 destroyed for peer 1
2021-09-16 16:36:04.277503: [TUN] [PI-Bonn] Keypair 191 created for peer 1
2021-09-16 16:36:04.277503: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:36:29.281022: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:36:46.695417: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:37:26.623591: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:37:51.635562: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:38:16.645829: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:38:16.645829: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:38:16.647494: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:38:16.647494: [TUN] [PI-Bonn] Keypair 190 destroyed for peer 1
2021-09-16 16:38:16.647494: [TUN] [PI-Bonn] Keypair 192 created for peer 1
2021-09-16 16:38:16.647494: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:38:40.345485: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:39:04.129390: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:39:29.135394: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:39:44.351868: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:40:14.553341: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:40:19.543012: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:40:19.544181: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:40:19.544181: [TUN] [PI-Bonn] Keypair 191 destroyed for peer 1
2021-09-16 16:40:19.544181: [TUN] [PI-Bonn] Keypair 193 created for peer 1
2021-09-16 16:40:19.544181: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:40:44.133285: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:41:09.141122: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:41:34.153385: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:41:50.791423: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:42:24.139833: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:42:24.139993: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:42:24.141063: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:42:24.141063: [TUN] [PI-Bonn] Keypair 192 destroyed for peer 1
2021-09-16 16:42:24.141063: [TUN] [PI-Bonn] Keypair 194 created for peer 1
2021-09-16 16:42:24.141063: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:42:39.455939: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:42:55.312949: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:43:10.683883: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:43:35.686424: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:44:06.503211: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:44:19.298387: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:44:29.008847: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:44:29.011056: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:44:29.011056: [TUN] [PI-Bonn] Keypair 193 destroyed for peer 1
2021-09-16 16:44:29.011056: [TUN] [PI-Bonn] Keypair 195 created for peer 1
2021-09-16 16:44:29.011056: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:44:44.383714: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:44:59.230203: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:45:24.245535: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:45:49.256590: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:46:14.262030: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:46:39.272998: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:46:39.273195: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:46:39.275085: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:46:39.275085: [TUN] [PI-Bonn] Keypair 194 destroyed for peer 1
2021-09-16 16:46:39.275085: [TUN] [PI-Bonn] Keypair 196 created for peer 1
2021-09-16 16:46:39.275085: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:47:04.281355: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:47:29.292740: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:47:54.299392: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:48:19.310359: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:48:44.321480: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:48:44.321689: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:48:44.322761: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:48:44.322761: [TUN] [PI-Bonn] Keypair 195 destroyed for peer 1
2021-09-16 16:48:44.322761: [TUN] [PI-Bonn] Keypair 197 created for peer 1
2021-09-16 16:48:44.322761: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:49:09.331410: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:49:41.335550: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:50:06.336284: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:50:31.346750: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:50:56.353356: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:50:56.353580: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:50:56.354267: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:50:56.354267: [TUN] [PI-Bonn] Keypair 196 destroyed for peer 1
2021-09-16 16:50:56.354267: [TUN] [PI-Bonn] Keypair 198 created for peer 1
2021-09-16 16:50:56.354267: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:51:21.366068: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:51:37.066669: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:52:02.079298: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:52:20.051795: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 16:52:45.059151: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:53:10.065661: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:53:10.065815: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:53:10.067121: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:53:10.067121: [TUN] [PI-Bonn] Keypair 197 destroyed for peer 1
2021-09-16 16:53:10.067121: [TUN] [PI-Bonn] Keypair 199 created for peer 1
2021-09-16 16:53:10.067121: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:53:35.068073: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:54:00.074686: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:54:25.085699: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:54:50.096742: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:55:15.102795: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:55:15.102959: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:55:15.106855: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:55:15.106855: [TUN] [PI-Bonn] Keypair 198 destroyed for peer 1
2021-09-16 16:55:15.106855: [TUN] [PI-Bonn] Keypair 200 created for peer 1
2021-09-16 16:55:15.106855: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:55:40.113560: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:56:05.120565: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:56:30.131568: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:56:55.138192: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:57:20.148641: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:57:20.148840: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:57:20.149477: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:57:20.149477: [TUN] [PI-Bonn] Keypair 199 destroyed for peer 1
2021-09-16 16:57:20.149477: [TUN] [PI-Bonn] Keypair 201 created for peer 1
2021-09-16 16:57:20.149477: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:57:45.155164: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:58:10.161718: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:58:35.172844: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:59:00.179460: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:59:25.190489: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:59:25.190628: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 16:59:25.192383: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 16:59:25.192383: [TUN] [PI-Bonn] Keypair 200 destroyed for peer 1
2021-09-16 16:59:25.192383: [TUN] [PI-Bonn] Keypair 202 created for peer 1
2021-09-16 16:59:25.192383: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 16:59:50.203202: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:00:19.817051: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:00:35.164462: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:01:00.165347: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:01:25.176385: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:01:50.187429: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:01:50.187609: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:01:50.193358: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:01:50.193358: [TUN] [PI-Bonn] Keypair 201 destroyed for peer 1
2021-09-16 17:01:50.193358: [TUN] [PI-Bonn] Keypair 203 created for peer 1
2021-09-16 17:01:50.193358: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:02:15.198198: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:02:40.203897: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:03:00.570967: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:03:15.935713: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:03:40.948285: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:03:56.658816: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:03:56.661552: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:03:56.661552: [TUN] [PI-Bonn] Keypair 202 destroyed for peer 1
2021-09-16 17:03:56.661552: [TUN] [PI-Bonn] Keypair 204 created for peer 1
2021-09-16 17:03:56.661552: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:04:08.158330: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:04:21.973786: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:04:46.980553: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:05:11.987212: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:05:36.998230: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:06:02.008014: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:06:02.008202: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:06:02.009291: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:06:02.009291: [TUN] [PI-Bonn] Keypair 203 destroyed for peer 1
2021-09-16 17:06:02.009291: [TUN] [PI-Bonn] Keypair 205 created for peer 1
2021-09-16 17:06:02.009291: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:06:27.022022: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:06:52.027440: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:07:17.042840: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:07:42.053921: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:08:07.061740: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:08:07.061966: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:08:07.063123: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:08:07.063123: [TUN] [PI-Bonn] Keypair 204 destroyed for peer 1
2021-09-16 17:08:07.063123: [TUN] [PI-Bonn] Keypair 206 created for peer 1
2021-09-16 17:08:07.063123: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:08:32.074636: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:08:56.924528: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:09:21.934771: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:09:46.944984: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:10:11.957742: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:10:11.957742: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:10:11.959193: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:10:11.959193: [TUN] [PI-Bonn] Keypair 205 destroyed for peer 1
2021-09-16 17:10:11.959193: [TUN] [PI-Bonn] Keypair 207 created for peer 1
2021-09-16 17:10:11.959193: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:10:36.970614: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:11:05.600813: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:11:30.611827: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:11:55.619376: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:12:06.368144: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:12:31.382674: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:12:31.382857: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:12:31.384501: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:12:31.384501: [TUN] [PI-Bonn] Keypair 206 destroyed for peer 1
2021-09-16 17:12:31.384501: [TUN] [PI-Bonn] Keypair 208 created for peer 1
2021-09-16 17:12:31.384501: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:12:56.385031: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:14:33.791703: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:14:33.793140: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:14:33.793140: [TUN] [PI-Bonn] Keypair 207 destroyed for peer 1
2021-09-16 17:14:33.793140: [TUN] [PI-Bonn] Keypair 209 created for peer 1
2021-09-16 17:14:33.793140: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:15:36.260002: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:15:46.268942: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:16:26.311887: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:16:36.196357: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:16:36.197958: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:16:36.197958: [TUN] [PI-Bonn] Keypair 208 destroyed for peer 1
2021-09-16 17:16:36.197958: [TUN] [PI-Bonn] Keypair 210 created for peer 1
2021-09-16 17:16:36.197958: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:16:46.358945: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:16:56.368751: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:17:38.142648: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:18:10.909770: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:18:26.789546: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:18:36.544932: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:18:36.547066: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:18:36.547066: [TUN] [PI-Bonn] Keypair 209 destroyed for peer 1
2021-09-16 17:18:36.547066: [TUN] [PI-Bonn] Keypair 211 created for peer 1
2021-09-16 17:18:36.547066: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:18:47.260601: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:18:58.006096: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:19:10.816154: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:19:31.288062: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:19:42.564455: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:19:54.849972: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:20:06.617609: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:20:20.957074: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:20:31.703987: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:20:36.547746: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:20:36.549519: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:20:36.549519: [TUN] [PI-Bonn] Keypair 210 destroyed for peer 1
2021-09-16 17:20:36.549519: [TUN] [PI-Bonn] Keypair 212 created for peer 1
2021-09-16 17:20:36.549519: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:20:50.652100: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:21:02.940141: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:21:14.716357: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:21:25.980728: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:21:46.972454: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:21:58.755666: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:22:11.044493: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:22:22.858024: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:22:34.593496: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:22:40.552654: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:22:40.558626: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:22:40.558626: [TUN] [PI-Bonn] Keypair 211 destroyed for peer 1
2021-09-16 17:22:40.558626: [TUN] [PI-Bonn] Keypair 213 created for peer 1
2021-09-16 17:22:40.558626: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:22:52.514500: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:23:02.752724: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:23:15.039881: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:23:26.824376: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:23:38.588772: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:23:54.976402: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:24:05.215754: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:24:30.216025: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:24:55.218047: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:24:55.218247: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:24:55.219495: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:24:55.219495: [TUN] [PI-Bonn] Keypair 212 destroyed for peer 1
2021-09-16 17:24:55.219495: [TUN] [PI-Bonn] Keypair 214 created for peer 1
2021-09-16 17:24:55.219495: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:25:13.826676: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 17:26:56.007449: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:26:56.014256: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:26:56.014256: [TUN] [PI-Bonn] Keypair 213 destroyed for peer 1
2021-09-16 17:26:56.014256: [TUN] [PI-Bonn] Keypair 215 created for peer 1
2021-09-16 17:26:56.014256: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:28:56.333054: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:28:56.346563: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:28:56.346563: [TUN] [PI-Bonn] Keypair 214 destroyed for peer 1
2021-09-16 17:28:56.346563: [TUN] [PI-Bonn] Keypair 216 created for peer 1
2021-09-16 17:28:56.346563: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:31:00.024108: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:31:05.026894: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:31:10.040239: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-16 17:31:10.040239: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:31:10.249224: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-16 17:31:15.048910: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:31:20.049420: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:32:01.789233: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-16 17:32:01.789233: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:32:01.792798: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:32:06.922988: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-16 17:32:06.923027: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:35:25.778698: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:35:30.890155: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-16 17:35:30.890155: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:35:35.918301: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:35:40.931771: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:35:40.938946: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:35:40.938946: [TUN] [PI-Bonn] Keypair 215 destroyed for peer 1
2021-09-16 17:35:40.938946: [TUN] [PI-Bonn] Keypair 217 created for peer 1
2021-09-16 17:37:41.210699: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:37:41.215171: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:37:41.215171: [TUN] [PI-Bonn] Keypair 216 destroyed for peer 1
2021-09-16 17:37:41.215171: [TUN] [PI-Bonn] Keypair 218 created for peer 1
2021-09-16 17:37:41.215171: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:39:41.454319: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 17:39:41.460626: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 17:39:41.460626: [TUN] [PI-Bonn] Keypair 217 destroyed for peer 1
2021-09-16 17:39:41.460626: [TUN] [PI-Bonn] Keypair 219 created for peer 1
2021-09-16 17:39:41.460626: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-16 17:55:29.092242: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 19:59:46.777956: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 19:59:51.782089: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 19:59:51.876865: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-16 19:59:51.876865: [TUN] [PI-Bonn] Keypair 218 destroyed for peer 1
2021-09-16 19:59:51.876865: [TUN] [PI-Bonn] Keypair 220 created for peer 1
2021-09-16 19:59:51.906397: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:40:26.322439: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-16 22:40:28.218653: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:40:28.218653: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:40:28.218845: [TUN] [PI-Bonn] Keypair 219 destroyed for peer 1
2021-09-16 22:40:28.218845: [TUN] [PI-Bonn] Keypair 221 created for peer 1
2021-09-16 22:40:28.350205: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:42:28.268605: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:42:28.268605: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:42:28.274224: [TUN] [PI-Bonn] Keypair 220 destroyed for peer 1
2021-09-16 22:42:28.274224: [TUN] [PI-Bonn] Keypair 222 created for peer 1
2021-09-16 22:42:28.289053: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:44:32.555941: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:44:32.555941: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:44:32.561244: [TUN] [PI-Bonn] Keypair 221 destroyed for peer 1
2021-09-16 22:44:32.561244: [TUN] [PI-Bonn] Keypair 223 created for peer 1
2021-09-16 22:44:32.597770: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:46:32.631305: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:46:32.631305: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:46:32.632688: [TUN] [PI-Bonn] Keypair 222 destroyed for peer 1
2021-09-16 22:46:32.632688: [TUN] [PI-Bonn] Keypair 224 created for peer 1
2021-09-16 22:46:32.652558: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:48:33.151477: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:48:33.151477: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:48:33.151696: [TUN] [PI-Bonn] Keypair 223 destroyed for peer 1
2021-09-16 22:48:33.151696: [TUN] [PI-Bonn] Keypair 225 created for peer 1
2021-09-16 22:48:33.174044: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:50:33.440352: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:50:33.440352: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:50:33.449200: [TUN] [PI-Bonn] Keypair 224 destroyed for peer 1
2021-09-16 22:50:33.449200: [TUN] [PI-Bonn] Keypair 226 created for peer 1
2021-09-16 22:50:33.461316: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:52:33.477302: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:52:33.477302: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:52:33.480654: [TUN] [PI-Bonn] Keypair 225 destroyed for peer 1
2021-09-16 22:52:33.480654: [TUN] [PI-Bonn] Keypair 227 created for peer 1
2021-09-16 22:52:33.495667: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:54:33.670167: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:54:33.670167: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:54:33.674008: [TUN] [PI-Bonn] Keypair 226 destroyed for peer 1
2021-09-16 22:54:33.674008: [TUN] [PI-Bonn] Keypair 228 created for peer 1
2021-09-16 22:54:33.690702: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:56:33.706041: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:56:33.706041: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:56:33.711144: [TUN] [PI-Bonn] Keypair 227 destroyed for peer 1
2021-09-16 22:56:33.711144: [TUN] [PI-Bonn] Keypair 229 created for peer 1
2021-09-16 22:56:33.747263: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 22:58:34.700397: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 22:58:34.700397: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 22:58:34.700397: [TUN] [PI-Bonn] Keypair 228 destroyed for peer 1
2021-09-16 22:58:34.700397: [TUN] [PI-Bonn] Keypair 230 created for peer 1
2021-09-16 22:58:34.731223: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:00:34.866139: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:00:34.866139: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:00:34.868341: [TUN] [PI-Bonn] Keypair 229 destroyed for peer 1
2021-09-16 23:00:34.868341: [TUN] [PI-Bonn] Keypair 231 created for peer 1
2021-09-16 23:00:34.887207: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:02:35.222648: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:02:35.222648: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:02:35.231633: [TUN] [PI-Bonn] Keypair 230 destroyed for peer 1
2021-09-16 23:02:35.231633: [TUN] [PI-Bonn] Keypair 232 created for peer 1
2021-09-16 23:02:35.253547: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:04:35.640805: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:04:35.640805: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:04:35.642239: [TUN] [PI-Bonn] Keypair 231 destroyed for peer 1
2021-09-16 23:04:35.642239: [TUN] [PI-Bonn] Keypair 233 created for peer 1
2021-09-16 23:04:35.661463: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:06:35.809986: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:06:35.809986: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:06:35.816866: [TUN] [PI-Bonn] Keypair 232 destroyed for peer 1
2021-09-16 23:06:35.816866: [TUN] [PI-Bonn] Keypair 234 created for peer 1
2021-09-16 23:06:35.830894: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:08:36.138877: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:08:36.138877: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:08:36.140573: [TUN] [PI-Bonn] Keypair 233 destroyed for peer 1
2021-09-16 23:08:36.140573: [TUN] [PI-Bonn] Keypair 235 created for peer 1
2021-09-16 23:08:36.159447: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:10:36.359022: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:10:36.359022: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:10:36.364354: [TUN] [PI-Bonn] Keypair 234 destroyed for peer 1
2021-09-16 23:10:36.364354: [TUN] [PI-Bonn] Keypair 236 created for peer 1
2021-09-16 23:10:36.379188: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:12:36.688242: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:12:36.688242: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:12:36.693016: [TUN] [PI-Bonn] Keypair 235 destroyed for peer 1
2021-09-16 23:12:36.693016: [TUN] [PI-Bonn] Keypair 237 created for peer 1
2021-09-16 23:12:36.704458: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:14:37.028386: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:14:37.028386: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:14:37.034839: [TUN] [PI-Bonn] Keypair 236 destroyed for peer 1
2021-09-16 23:14:37.034839: [TUN] [PI-Bonn] Keypair 238 created for peer 1
2021-09-16 23:14:37.046227: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:16:37.401473: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:16:37.401473: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:16:37.404649: [TUN] [PI-Bonn] Keypair 237 destroyed for peer 1
2021-09-16 23:16:37.404649: [TUN] [PI-Bonn] Keypair 239 created for peer 1
2021-09-16 23:16:37.415999: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:18:37.727936: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:18:37.727936: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:18:37.727936: [TUN] [PI-Bonn] Keypair 238 destroyed for peer 1
2021-09-16 23:18:37.727936: [TUN] [PI-Bonn] Keypair 240 created for peer 1
2021-09-16 23:18:37.746708: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:20:38.056185: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:20:38.056185: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:20:38.060665: [TUN] [PI-Bonn] Keypair 239 destroyed for peer 1
2021-09-16 23:20:38.060665: [TUN] [PI-Bonn] Keypair 241 created for peer 1
2021-09-16 23:20:38.071994: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:22:38.336705: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:22:38.336705: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:22:38.351404: [TUN] [PI-Bonn] Keypair 240 destroyed for peer 1
2021-09-16 23:22:38.351404: [TUN] [PI-Bonn] Keypair 242 created for peer 1
2021-09-16 23:22:38.372272: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:24:38.650968: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:24:38.650968: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:24:38.662584: [TUN] [PI-Bonn] Keypair 241 destroyed for peer 1
2021-09-16 23:24:38.662584: [TUN] [PI-Bonn] Keypair 243 created for peer 1
2021-09-16 23:24:38.679124: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:26:38.911101: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:26:38.911101: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:26:38.919512: [TUN] [PI-Bonn] Keypair 242 destroyed for peer 1
2021-09-16 23:26:38.919512: [TUN] [PI-Bonn] Keypair 244 created for peer 1
2021-09-16 23:26:38.940945: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:28:39.420964: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:28:39.420964: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:28:39.424524: [TUN] [PI-Bonn] Keypair 243 destroyed for peer 1
2021-09-16 23:28:39.424524: [TUN] [PI-Bonn] Keypair 245 created for peer 1
2021-09-16 23:28:39.451775: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:30:39.545519: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:30:39.545519: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:30:39.547595: [TUN] [PI-Bonn] Keypair 244 destroyed for peer 1
2021-09-16 23:30:39.547595: [TUN] [PI-Bonn] Keypair 246 created for peer 1
2021-09-16 23:30:39.558999: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:32:39.789545: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:32:39.789545: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:32:39.790939: [TUN] [PI-Bonn] Keypair 245 destroyed for peer 1
2021-09-16 23:32:39.790939: [TUN] [PI-Bonn] Keypair 247 created for peer 1
2021-09-16 23:32:39.811505: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:34:40.192313: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:34:40.192313: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:34:40.196885: [TUN] [PI-Bonn] Keypair 246 destroyed for peer 1
2021-09-16 23:34:40.196885: [TUN] [PI-Bonn] Keypair 248 created for peer 1
2021-09-16 23:34:40.207195: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:36:40.534601: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:36:40.534601: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:36:40.537012: [TUN] [PI-Bonn] Keypair 247 destroyed for peer 1
2021-09-16 23:36:40.537012: [TUN] [PI-Bonn] Keypair 249 created for peer 1
2021-09-16 23:36:40.548244: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:38:40.858383: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:38:40.858383: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:38:40.866177: [TUN] [PI-Bonn] Keypair 248 destroyed for peer 1
2021-09-16 23:38:40.866177: [TUN] [PI-Bonn] Keypair 250 created for peer 1
2021-09-16 23:38:40.887037: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:40:41.045977: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:40:41.045977: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:40:41.051380: [TUN] [PI-Bonn] Keypair 249 destroyed for peer 1
2021-09-16 23:40:41.051380: [TUN] [PI-Bonn] Keypair 251 created for peer 1
2021-09-16 23:40:41.062552: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:42:41.542370: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:42:41.542370: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:42:41.551052: [TUN] [PI-Bonn] Keypair 250 destroyed for peer 1
2021-09-16 23:42:41.551052: [TUN] [PI-Bonn] Keypair 252 created for peer 1
2021-09-16 23:42:41.572482: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:44:41.882945: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:44:41.882945: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:44:41.890825: [TUN] [PI-Bonn] Keypair 251 destroyed for peer 1
2021-09-16 23:44:41.890825: [TUN] [PI-Bonn] Keypair 253 created for peer 1
2021-09-16 23:44:41.902122: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:46:42.215455: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:46:42.215455: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:46:42.225558: [TUN] [PI-Bonn] Keypair 252 destroyed for peer 1
2021-09-16 23:46:42.225558: [TUN] [PI-Bonn] Keypair 254 created for peer 1
2021-09-16 23:46:42.242285: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:48:42.279137: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:48:42.279137: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:48:42.284229: [TUN] [PI-Bonn] Keypair 253 destroyed for peer 1
2021-09-16 23:48:42.284229: [TUN] [PI-Bonn] Keypair 255 created for peer 1
2021-09-16 23:48:42.295271: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:50:42.829045: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:50:42.829045: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:50:42.834443: [TUN] [PI-Bonn] Keypair 254 destroyed for peer 1
2021-09-16 23:50:42.834443: [TUN] [PI-Bonn] Keypair 256 created for peer 1
2021-09-16 23:50:42.850942: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:52:43.145437: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:52:43.145437: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:52:43.153081: [TUN] [PI-Bonn] Keypair 255 destroyed for peer 1
2021-09-16 23:52:43.153081: [TUN] [PI-Bonn] Keypair 257 created for peer 1
2021-09-16 23:52:43.164884: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:54:43.441530: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:54:43.441530: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:54:43.456319: [TUN] [PI-Bonn] Keypair 256 destroyed for peer 1
2021-09-16 23:54:43.456319: [TUN] [PI-Bonn] Keypair 258 created for peer 1
2021-09-16 23:54:43.472275: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:56:43.580156: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:56:43.580156: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:56:43.588285: [TUN] [PI-Bonn] Keypair 257 destroyed for peer 1
2021-09-16 23:56:43.588285: [TUN] [PI-Bonn] Keypair 259 created for peer 1
2021-09-16 23:56:43.605082: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-16 23:58:44.049148: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-16 23:58:44.049148: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-16 23:58:44.053242: [TUN] [PI-Bonn] Keypair 258 destroyed for peer 1
2021-09-16 23:58:44.053242: [TUN] [PI-Bonn] Keypair 260 created for peer 1
2021-09-16 23:58:44.070031: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:00:44.332847: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:00:44.332847: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:00:44.340192: [TUN] [PI-Bonn] Keypair 259 destroyed for peer 1
2021-09-17 00:00:44.340192: [TUN] [PI-Bonn] Keypair 261 created for peer 1
2021-09-17 00:00:44.353280: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:02:44.666750: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:02:44.666750: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:02:44.673384: [TUN] [PI-Bonn] Keypair 260 destroyed for peer 1
2021-09-17 00:02:44.673384: [TUN] [PI-Bonn] Keypair 262 created for peer 1
2021-09-17 00:02:44.694886: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:04:44.951683: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:04:44.951683: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:04:44.953849: [TUN] [PI-Bonn] Keypair 261 destroyed for peer 1
2021-09-17 00:04:44.953849: [TUN] [PI-Bonn] Keypair 263 created for peer 1
2021-09-17 00:04:44.965493: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:06:45.233109: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:06:45.233109: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:06:45.239551: [TUN] [PI-Bonn] Keypair 262 destroyed for peer 1
2021-09-17 00:06:45.239551: [TUN] [PI-Bonn] Keypair 264 created for peer 1
2021-09-17 00:06:45.250470: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:08:45.525078: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:08:45.525078: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:08:45.525475: [TUN] [PI-Bonn] Keypair 263 destroyed for peer 1
2021-09-17 00:08:45.525475: [TUN] [PI-Bonn] Keypair 265 created for peer 1
2021-09-17 00:08:45.546871: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:10:45.814521: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:10:45.814521: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:10:45.825976: [TUN] [PI-Bonn] Keypair 264 destroyed for peer 1
2021-09-17 00:10:45.825976: [TUN] [PI-Bonn] Keypair 266 created for peer 1
2021-09-17 00:10:45.843015: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:12:45.861905: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:12:45.861905: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:12:45.865802: [TUN] [PI-Bonn] Keypair 265 destroyed for peer 1
2021-09-17 00:12:45.865802: [TUN] [PI-Bonn] Keypair 267 created for peer 1
2021-09-17 00:12:45.877290: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:14:46.213507: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:14:46.213507: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:14:46.219852: [TUN] [PI-Bonn] Keypair 266 destroyed for peer 1
2021-09-17 00:14:46.219852: [TUN] [PI-Bonn] Keypair 268 created for peer 1
2021-09-17 00:14:46.231337: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:16:46.749806: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:16:46.749806: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:16:46.754086: [TUN] [PI-Bonn] Keypair 267 destroyed for peer 1
2021-09-17 00:16:46.754086: [TUN] [PI-Bonn] Keypair 269 created for peer 1
2021-09-17 00:16:46.764971: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:18:47.054397: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:18:47.054397: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:18:47.063739: [TUN] [PI-Bonn] Keypair 268 destroyed for peer 1
2021-09-17 00:18:47.063739: [TUN] [PI-Bonn] Keypair 270 created for peer 1
2021-09-17 00:18:47.085073: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:20:47.373236: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:20:47.373236: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:20:47.374823: [TUN] [PI-Bonn] Keypair 269 destroyed for peer 1
2021-09-17 00:20:47.374823: [TUN] [PI-Bonn] Keypair 271 created for peer 1
2021-09-17 00:20:47.386233: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:22:47.669140: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:22:47.669140: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:22:47.683485: [TUN] [PI-Bonn] Keypair 270 destroyed for peer 1
2021-09-17 00:22:47.683485: [TUN] [PI-Bonn] Keypair 272 created for peer 1
2021-09-17 00:22:47.700434: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:24:48.007033: [TUN] [PI-Bonn] Receiving handshake initiation from peer 1 (serverip:53115)
2021-09-17 00:24:48.007033: [TUN] [PI-Bonn] Sending handshake response to peer 1 (serverip:53115)
2021-09-17 00:24:48.013820: [TUN] [PI-Bonn] Keypair 271 destroyed for peer 1
2021-09-17 00:24:48.013820: [TUN] [PI-Bonn] Keypair 273 created for peer 1
2021-09-17 00:24:48.025499: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:26:01.296715: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-17 00:26:02.327501: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-17 00:26:03.786032: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-17 00:26:04.786419: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-17 00:26:05.775526: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-17 00:26:06.777299: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-17 00:26:06.777888: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-17 00:26:18.048092: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:26:38.019564: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-17 00:27:07.327228: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-17 00:27:25.005444: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-17 00:27:25.005444: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 16:11:34.494395: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 16:11:34.518714: [MGR] Update checker: There are no more endpoints available from the endpoint mapper.
2021-09-20 16:11:35.090713: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:11:38.410599: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 16:11:44.516852: [MGR] Removing network adapter ?PI-Bonn? because its service is stopped
2021-09-20 16:13:13.882330: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 16:13:14.885864: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:13:18.893423: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 16:13:19.207641: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 16:13:19.895943: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:13:19.895943: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 16:13:46.473284: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 16:13:46.479806: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 16:13:46.479806: [TUN] [PI-Bonn] SCM locked for 2s by .\NT Service Control Manager, marking service as started
2021-09-20 16:13:46.479806: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 16:13:46.489322: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 16:13:46.506657: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:13:46.515469: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 16:13:50.517808: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:13:53.475808: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:13:54.527428: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:13:58.540981: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:14:02.556878: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 16:14:02.559931: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 16:14:02.659744: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 16:14:04.099175: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 16:14:04.099175: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 16:14:04.078506: [TUN] [PI-Bonn] Interface created
2021-09-20 16:14:04.103633: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 16:14:04.103921: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 16:14:04.104436: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 16:14:04.113908: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 16:14:04.113908: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 16:14:04.113908: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 16:14:04.113908: [TUN] [PI-Bonn] Interface up
2021-09-20 16:14:04.116087: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 16:14:04.117299: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 16:14:04.117803: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 16:14:04.120713: [TUN] [PI-Bonn] Startup complete
2021-09-20 16:14:04.164756: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 16:14:04.164756: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 16:16:04.177037: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 16:16:04.185213: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 16:16:04.185213: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-20 16:16:04.185213: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 16:17:12.714574: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 16:17:13.731998: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:17:13.731998: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 16:17:19.930103: [TUN] [PI-Bonn] Shutting down
2021-09-20 16:17:19.933139: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 16:25:40.290856: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 16:25:40.312577: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 16:25:40.314559: [TUN] [PI-Bonn] SCM locked for 1s by .\NT Service Control Manager, marking service as started
2021-09-20 16:25:40.315067: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 16:25:40.320078: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 16:25:40.360919: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 16:25:40.360919: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:25:44.380184: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 16:25:46.979369: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 16:25:52.433570: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 16:25:52.437809: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 16:25:52.590707: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 16:25:52.847380: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 16:25:52.847380: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 16:25:52.821503: [TUN] [PI-Bonn] Interface created
2021-09-20 16:25:52.852960: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 16:25:52.852960: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 16:25:52.853662: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 16:25:52.854997: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 16:25:52.854494: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 16:25:52.854494: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 16:25:52.854997: [TUN] [PI-Bonn] Interface up
2021-09-20 16:25:52.857112: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 16:25:52.857112: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 16:25:52.858109: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 16:25:52.860116: [TUN] [PI-Bonn] Startup complete
2021-09-20 16:25:52.872859: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 16:25:52.873731: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 16:26:27.673384: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:27:51.083435: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:27:51.086951: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:27:51.086951: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-20 18:27:51.086951: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:28:46.387848: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:29:52.226039: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:29:52.268913: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:29:52.268913: [TUN] [PI-Bonn] Keypair 1 destroyed for peer 1
2021-09-20 18:29:52.268913: [TUN] [PI-Bonn] Keypair 3 created for peer 1
2021-09-20 18:29:52.268913: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:30:14.965679: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:30:45.178742: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:31:18.995996: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:31:46.202698: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 18:31:47.214427: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:31:47.214427: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 18:31:55.042968: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:31:59.366185: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-20 18:32:00.065033: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:00.065033: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:05.153482: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:05.153482: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:10.184243: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:10.184243: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:15.230755: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:15.230755: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:20.292653: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:20.292653: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:25.448343: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:25.448343: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:30.588368: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-20 18:32:30.588368: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:32:34.609426: [TUN] [PI-Bonn] Shutting down
2021-09-20 18:32:34.621299: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 18:32:59.774025: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:32:59.784265: [TUN] [PI-Bonn] SCM locked for 1s by .\NT Service Control Manager, marking service as started
2021-09-20 18:32:59.792309: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 18:32:59.834809: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 18:32:59.896408: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:33:00.210018: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:00.241160: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 18:33:04.213398: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:08.228435: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:12.232849: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:16.247392: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:19.861787: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:33:20.260552: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:33:24.287055: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 18:33:24.391720: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 18:33:24.543717: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 18:33:25.180413: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 18:33:25.180413: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 18:33:25.139336: [TUN] [PI-Bonn] Interface created
2021-09-20 18:33:25.302165: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 18:33:25.302165: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 18:33:25.311248: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 18:33:25.302165: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 18:33:25.308281: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:33:25.308281: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:33:25.311248: [TUN] [PI-Bonn] Interface up
2021-09-20 18:33:25.325585: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 18:33:25.327091: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:33:25.327091: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 18:33:25.334431: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 18:33:25.335429: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 18:33:25.335429: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:33:25.343362: [TUN] [PI-Bonn] Startup complete
2021-09-20 18:33:53.654495: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:35:09.883821: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-20 18:35:09.883821: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:35:09.887436: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:35:09.887436: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-20 18:35:09.887436: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:37:02.401248: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 18:37:03.404432: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:37:03.404432: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 18:37:09.403325: [TUN] [PI-Bonn] Shutting down
2021-09-20 18:37:09.417997: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 18:37:49.564209: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:37:49.574324: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:37:49.574324: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 18:37:49.575423: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 18:37:49.622804: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:37:49.653945: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 18:37:52.267250: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:37:57.656943: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 18:37:57.671241: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 18:37:57.825783: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 18:37:58.047296: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 18:37:58.047296: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 18:37:58.030693: [TUN] [PI-Bonn] Interface created
2021-09-20 18:37:58.052396: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 18:37:58.052396: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 18:37:58.052948: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 18:37:58.056563: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 18:37:58.056563: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:37:58.056563: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:37:58.056563: [TUN] [PI-Bonn] Interface up
2021-09-20 18:37:58.060051: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 18:37:58.060967: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 18:37:58.060967: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 18:37:58.061967: [TUN] [PI-Bonn] Startup complete
2021-09-20 18:37:58.137907: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:37:58.137907: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 18:38:31.837708: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:39:29.265348: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:39:58.851433: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:39:58.858133: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:39:58.858133: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-20 18:39:58.858133: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:40:00.415170: [TUN] [PI-Bonn] Packet has invalid nonce 77 (max 78)
2021-09-20 18:40:49.895507: [TUN] [PI-Bonn] Packet has invalid nonce 562 (max 567)
2021-09-20 18:40:49.895507: [TUN] [PI-Bonn] Packet has invalid nonce 564 (max 567)
2021-09-20 18:40:49.895507: [TUN] [PI-Bonn] Packet has invalid nonce 565 (max 567)
2021-09-20 18:40:49.895507: [TUN] [PI-Bonn] Packet has invalid nonce 566 (max 567)
2021-09-20 18:40:49.897577: [TUN] [PI-Bonn] Packet has invalid nonce 562 (max 567)
2021-09-20 18:40:49.897577: [TUN] [PI-Bonn] Packet has invalid nonce 564 (max 567)
2021-09-20 18:40:49.897577: [TUN] [PI-Bonn] Packet has invalid nonce 565 (max 567)
2021-09-20 18:40:49.897577: [TUN] [PI-Bonn] Packet has invalid nonce 566 (max 567)
2021-09-20 18:41:45.438618: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 18:41:46.448611: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:41:46.448611: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 18:41:49.663503: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 18:41:50.409912: [TUN] [PI-Bonn] Shutting down
2021-09-20 18:41:50.413105: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 18:43:38.032137: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:43:38.063427: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:43:38.091054: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:43:38.091142: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 18:43:38.096545: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 18:43:38.120281: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-20 18:43:38.145314: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-20 18:43:42.192048: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 18:43:42.196587: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 18:43:42.275197: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 18:43:44.470326: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 18:43:44.470326: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 18:43:44.457234: [TUN] [PI-Bonn] Interface created
2021-09-20 18:43:44.475069: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 18:43:44.475521: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 18:43:44.475739: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 18:43:44.478107: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 18:43:44.476760: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:43:44.476760: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:43:44.478107: [TUN] [PI-Bonn] Interface up
2021-09-20 18:43:44.480042: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 18:43:44.484493: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 18:43:44.484493: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 18:43:44.488773: [TUN] [PI-Bonn] Startup complete
2021-09-20 18:43:44.534125: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:43:44.534125: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 18:43:53.591165: [TUN] [PI-Bonn] Shutting down
2021-09-20 18:43:53.591743: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-20 18:45:44.263492: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-20 18:45:44.263492: [TUN] [PI-Bonn] Watching network interfaces
2021-09-20 18:45:44.264558: [TUN] [PI-Bonn] Resolving DNS names
2021-09-20 18:45:44.271618: [TUN] [PI-Bonn] Creating network adapter
2021-09-20 18:45:44.274309: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-20 18:45:44.338359: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-20 18:45:44.492408: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-20 18:45:44.492408: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-20 18:45:44.482127: [TUN] [PI-Bonn] Interface created
2021-09-20 18:45:44.499021: [TUN] [PI-Bonn] Dropping privileges
2021-09-20 18:45:44.499534: [TUN] [PI-Bonn] Setting interface configuration
2021-09-20 18:45:44.500046: [TUN] [PI-Bonn] Peer 1 created
2021-09-20 18:45:44.502113: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:45:44.502721: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-20 18:45:44.502721: [TUN] [PI-Bonn] Interface up
2021-09-20 18:45:44.503754: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:45:44.504267: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-20 18:45:44.505330: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-20 18:45:44.505330: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-20 18:45:44.508441: [TUN] [PI-Bonn] Startup complete
2021-09-20 18:45:44.529174: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:45:44.529174: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-20 18:47:27.104507: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:47:44.836220: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:47:44.841043: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:47:44.841043: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-20 18:47:44.841043: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:47:55.718150: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:49:15.096778: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:49:48.632952: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:49:48.636773: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:49:48.636773: [TUN] [PI-Bonn] Keypair 1 destroyed for peer 1
2021-09-20 18:49:48.636773: [TUN] [PI-Bonn] Keypair 3 created for peer 1
2021-09-20 18:49:48.636773: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:50:08.824294: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-20 18:50:15.998077: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-20 18:50:17.012419: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-20 18:50:17.012419: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-20 18:50:20.987889: [TUN] [PI-Bonn] Keypair 2 destroyed for peer 1
2021-09-20 18:50:20.987889: [TUN] [PI-Bonn] Keypair 3 destroyed for peer 1
2021-09-20 18:51:14.421544: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-20 18:51:14.421544: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:51:15.912164: [MGR] Starting UI process for user ?theuser at laptop? for session 2
2021-09-20 18:51:19.503665: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-20 18:51:19.541258: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-20 18:51:19.541258: [TUN] [PI-Bonn] Keypair 4 created for peer 1
2021-09-20 18:52:47.219699: [MGR] Exited UI process for user 'theuser at laptop' for session 2 with status 40010004
2021-09-20 18:52:48.225917: [MGR] Starting UI process for user ?theuser at laptop? for session 2
2021-09-20 18:52:48.225917: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 2: Session has logged out
2021-09-22 23:54:03.098881: [MGR] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-22 23:54:03.224517: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-22 23:54:03.385294: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-22 23:54:03.385670: [TUN] [PI-Bonn] Watching network interfaces
2021-09-22 23:54:03.402676: [TUN] [PI-Bonn] Resolving DNS names
2021-09-22 23:54:03.473391: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:03.631181: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-22 23:54:07.473760: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:11.484418: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:15.489101: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:19.507324: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:23.517384: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:27.527978: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:31.541270: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:35.549110: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:39.553110: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:43.566205: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:47.566685: [TUN] [PI-Bonn] Host not found when resolving wireguard.physik.uni-bonn.de, but no Internet connection available, sleeping for 4 seconds
2021-09-22 23:54:51.600341: [TUN] [PI-Bonn] Creating network adapter
2021-09-22 23:54:51.613322: [TUN] [PI-Bonn] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-22 23:54:51.614454: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-22 23:54:51.675993: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-22 23:54:54.634185: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-22 23:54:54.634185: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-22 23:54:54.599079: [TUN] [PI-Bonn] Interface created
2021-09-22 23:54:54.639255: [TUN] [PI-Bonn] Dropping privileges
2021-09-22 23:54:54.639700: [TUN] [PI-Bonn] Setting interface configuration
2021-09-22 23:54:54.640258: [TUN] [PI-Bonn] Peer 1 created
2021-09-22 23:54:54.641063: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-22 23:54:54.640843: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-22 23:54:54.641063: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-22 23:54:54.641063: [TUN] [PI-Bonn] Interface up
2021-09-22 23:54:54.643741: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-22 23:54:54.644247: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-22 23:54:54.644247: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-22 23:54:54.646245: [TUN] [PI-Bonn] Startup complete
2021-09-22 23:54:54.683982: [MGR] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-22 23:54:54.697462: [MGR] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-22 23:54:59.677861: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-22 23:54:59.761552: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-22 23:54:59.761552: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-22 23:54:59.782794: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-22 23:56:59.789803: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-22 23:56:59.834044: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-22 23:56:59.834044: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-22 23:56:59.834044: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-22 23:58:59.836554: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-22 23:58:59.873672: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-22 23:58:59.873672: [TUN] [PI-Bonn] Keypair 1 destroyed for peer 1
2021-09-22 23:58:59.873672: [TUN] [PI-Bonn] Keypair 3 created for peer 1
2021-09-22 23:58:59.873672: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-23 00:00:59.879687: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:01:04.888720: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:01:04.916281: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-23 00:01:04.916281: [TUN] [PI-Bonn] Keypair 2 destroyed for peer 1
2021-09-23 00:01:04.916281: [TUN] [PI-Bonn] Keypair 4 created for peer 1
2021-09-23 00:01:04.916281: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-23 00:03:04.921269: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:03:04.946213: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-23 00:03:04.946213: [TUN] [PI-Bonn] Keypair 3 destroyed for peer 1
2021-09-23 00:03:04.946213: [TUN] [PI-Bonn] Keypair 5 created for peer 1
2021-09-23 00:03:04.946213: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-23 00:05:04.949421: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:04.975677: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-23 00:05:04.975677: [TUN] [PI-Bonn] Keypair 4 destroyed for peer 1
2021-09-23 00:05:04.975677: [TUN] [PI-Bonn] Keypair 6 created for peer 1
2021-09-23 00:05:04.975677: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-23 00:05:30.432063: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-23 00:05:30.432063: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:35.488087: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-23 00:05:35.488087: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:40.583668: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 3)
2021-09-23 00:05:40.583668: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:45.496043: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-23 00:05:45.662548: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-23 00:05:45.662548: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:50.770413: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 3)
2021-09-23 00:05:50.770413: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:05:55.870407: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 4)
2021-09-23 00:05:55.870672: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:06:00.807349: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-23 00:06:00.902486: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-23 00:06:00.902486: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:06:05.928264: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 3)
2021-09-23 00:06:05.928264: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:06:11.057176: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 4)
2021-09-23 00:06:11.057176: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:06:16.035859: [TUN] [PI-Bonn] Retrying handshake with peer 1 (serverip:53115) because we stopped hearing back after 15 seconds
2021-09-23 00:06:16.235686: [TUN] [PI-Bonn] Handshake for peer 1 (serverip:53115) did not complete after 5 seconds, retrying (try 2)
2021-09-23 00:06:16.235686: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-23 00:06:19.079000: [MGR] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-23 00:06:19.569910: [MGR] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-23 00:06:20.568410: [MGR] EnsureDeviceObject: Failed to determine adapter ROOT\NET\0000 device object: Das Ger?t kann nicht verwendet werden. (Code 0x000010DF)
2021-09-23 00:06:20.829558: [TUN] [PI-Bonn] Shutting down
2021-09-23 00:06:20.830641: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-23 00:06:30.729497: [MGR] Removing network adapter ?PI-Bonn? because no service for it exists
2021-09-23 00:13:00.717692: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-23 00:13:01.732063: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-23 00:13:06.943364: [MGR] Exited UI process for user 'theuser at laptop' for session 1 with status 40010004
2021-09-23 00:13:07.949589: [MGR] Starting UI process for user ?theuser at laptop? for session 1
2021-09-23 00:13:07.949589: [MGR] Unable to start manager UI process for user 'theuser at laptop' for session 1: Session has logged out
2021-09-23 07:33:15.575873: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-23 07:33:17.068938: [MGR] Starting UI process for user ?theuser at laptop? for session 2
2021-09-23 15:45:18.785252: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-23 16:22:04.315409: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-23 19:36:01.247845: [MGR] Update checker: Der Servername oder die Serveradresse konnte nicht verarbeitet werden.
2021-09-24 07:02:42.291313: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-24 07:02:42.291313: [TUN] [PI-Bonn] Watching network interfaces
2021-09-24 07:02:42.294444: [TUN] [PI-Bonn] Resolving DNS names
2021-09-24 07:02:42.328952: [TUN] [PI-Bonn] Creating network adapter
2021-09-24 07:02:42.338025: [TUN] [PI-Bonn] WireGuardCreateAdapter: Creating adapter
2021-09-24 07:02:42.485548: [TUN] [PI-Bonn] SelectDriver: Using existing driver 0.8
2021-09-24 07:02:42.678393: [TUN] [PI-Bonn] Using WireGuardNT/0.8
2021-09-24 07:02:42.678393: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-24 07:02:42.651384: [TUN] [PI-Bonn] Interface created
2021-09-24 07:02:42.682754: [TUN] [PI-Bonn] Dropping privileges
2021-09-24 07:02:42.682754: [TUN] [PI-Bonn] Setting interface configuration
2021-09-24 07:02:42.683265: [TUN] [PI-Bonn] Peer 1 created
2021-09-24 07:02:42.685252: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-24 07:02:42.686785: [TUN] [PI-Bonn] Monitoring MTU of default v6 routes
2021-09-24 07:02:42.685252: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-24 07:02:42.686785: [TUN] [PI-Bonn] Interface up
2021-09-24 07:02:42.689759: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-24 07:02:42.697534: [TUN] [PI-Bonn] Monitoring MTU of default v4 routes
2021-09-24 07:02:42.698531: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-24 07:02:42.700101: [TUN] [PI-Bonn] Startup complete
2021-09-24 07:02:42.786228: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-24 07:02:42.786228: [TUN] [PI-Bonn] Keypair 1 created for peer 1
2021-09-24 07:02:42.840801: [TUN] [PI-Bonn] Receiving keepalive packet from peer 1 (serverip:53115)
2021-09-24 07:04:44.264133: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-24 07:04:44.293683: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-24 07:04:44.293683: [TUN] [PI-Bonn] Keypair 2 created for peer 1
2021-09-24 07:04:44.293683: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-24 07:06:44.354410: [TUN] [PI-Bonn] Sending handshake initiation to peer 1 (serverip:53115)
2021-09-24 07:06:44.375706: [TUN] [PI-Bonn] Receiving handshake response from peer 1 (serverip:53115)
2021-09-24 07:06:44.375706: [TUN] [PI-Bonn] Keypair 1 destroyed for peer 1
2021-09-24 07:06:44.375706: [TUN] [PI-Bonn] Keypair 3 created for peer 1
2021-09-24 07:06:44.375706: [TUN] [PI-Bonn] Sending keepalive packet to peer 1 (serverip:53115)
2021-09-24 07:07:12.593727: [TUN] [PI-Bonn] Shutting down
2021-09-24 07:07:12.594761: [MGR] [PI-Bonn] Tunnel service tracker finished
2021-09-24 07:27:12.383271: [TUN] [PI-Bonn] Starting WireGuard/0.4.9 (Windows 10.0.19042; amd64)
2021-09-24 07:27:12.383787: [TUN] [PI-Bonn] Watching network interfaces
2021-09-24 07:27:12.384834: [TUN] [PI-Bonn] Resolving DNS names
2021-09-24 07:27:12.392089: [TUN] [PI-Bonn] Creating network adapter
2021-09-24 07:27:12.400661: [TUN] [PI-Bonn] [Wintun] WintunCreateAdapter: Creating adapter
2021-09-24 07:27:12.494076: [TUN] [PI-Bonn] [Wintun] SelectDriver: Installing driver 0.13
2021-09-24 07:27:12.494911: [TUN] [PI-Bonn] [Wintun] SelectDriver: Extracting driver
2021-09-24 07:27:12.495935: [TUN] [PI-Bonn] [Wintun] SelectDriver: Installing driver
2021-09-24 07:27:12.935912: [TUN] [PI-Bonn] Using Wintun/0.13
2021-09-24 07:27:12.935912: [TUN] [PI-Bonn] Enabling firewall rules
2021-09-24 07:27:12.951525: [TUN] [PI-Bonn] Dropping privileges
2021-09-24 07:27:12.952035: [TUN] [PI-Bonn] Creating interface instance
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 1 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 3 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 2 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 2 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 2 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 1 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 4 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 3 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 4 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 3 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 4 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 5 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 1 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 5 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 5 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Setting interface configuration
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 7 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 6 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 7 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 6 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 6 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 8 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: handshake worker 7 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: decryption worker 8 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: encryption worker 8 - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: TUN reader - started
2021-09-24 07:27:12.953359: [TUN] [PI-Bonn] Routine: event worker - started
2021-09-24 07:27:12.953907: [TUN] [PI-Bonn] UAPI: Updating private key
2021-09-24 07:27:12.954400: [TUN] [PI-Bonn] UAPI: Removing all peers
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] peer(iwnI?NtBc) - UAPI: Created
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] peer(iwnI?NtBc) - UAPI: Updating endpoint
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] peer(iwnI?NtBc) - UAPI: Updating persistent keepalive interval
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] peer(iwnI?NtBc) - UAPI: Removing all allowedips
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] peer(iwnI?NtBc) - UAPI: Adding allowedip
2021-09-24 07:27:12.954542: [TUN] [PI-Bonn] Bringing peers up
2021-09-24 07:27:12.959902: [TUN] [PI-Bonn] UDP bind has been updated
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Starting
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Sending keepalive packet
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Sending handshake initiation
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Routine: sequential sender - started
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Routine: sequential receiver - started
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] Routine: receive incoming v4 - started
2021-09-24 07:27:12.959911: [TUN] [PI-Bonn] Routine: receive incoming v6 - started
2021-09-24 07:27:12.960938: [TUN] [PI-Bonn] Interface state was Down, requested Up, now Up
2021-09-24 07:27:12.960938: [TUN] [PI-Bonn] Monitoring default v6 routes
2021-09-24 07:27:12.960938: [TUN] [PI-Bonn] Binding v6 socket to interface 0 (blackhole=false)
2021-09-24 07:27:12.961448: [TUN] [PI-Bonn] Setting device v6 addresses
2021-09-24 07:27:12.963678: [TUN] [PI-Bonn] Monitoring default v4 routes
2021-09-24 07:27:12.963678: [TUN] [PI-Bonn] Binding v4 socket to interface 10 (blackhole=false)
2021-09-24 07:27:12.963678: [TUN] [PI-Bonn] Setting device v4 addresses
2021-09-24 07:27:12.971355: [TUN] [PI-Bonn] Listening for UAPI requests
2021-09-24 07:27:12.998506: [TUN] [PI-Bonn] Startup complete
2021-09-24 07:27:13.133804: [TUN] [PI-Bonn] peer(iwnI?NtBc) - Received handshake response
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5432 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210924/322a6f06/attachment.p7s>

From nekochan at tuta.io  Fri Sep 24 10:23:16 2021
From: nekochan at tuta.io (nekochan at tuta.io)
Date: Fri, 24 Sep 2021 12:23:16 +0200 (CEST)
Subject: Wireguard massive amount data
In-Reply-To: <EBVVZQ.U9BF94AEV1NE@dumke.me>
References: <EBVVZQ.U9BF94AEV1NE@dumke.me>
Message-ID: <MkMK9M9--3-2@tuta.io>

This is sending telemetry to Fedora.


Sep 23, 2021, 13:47 by daniel at dumke.me:

> Hi,
>
> I am trying to connect to a Mullvad Wireguard Host with my Fedora Linux using nmcli, as soon as I up the connection (nmcli con up Mullvad) massive amounts of data are sent through the tunnel (according to wg 1.4 GiB in the first 20 secs).
>
> Any hints on why this huge amount of data is transfered?
>
> Daniel
>
> '''
> root at lenovo# wg
> interface: wg1
>  public key: zr0q0pxcOfSoiKWjXEfuHqM58GMjE4HBLr8FzQIHYxM=
>  private key: (hidden)
>  listening port: 40360
>  fwmark: 0xcbdf
>
> peer: C2TUHPoZlT08iceLM2coBDTbcfg9tTKrUt7tRBWP0nk=
>  endpoint: 45.8.223.195:51820
>  allowed ips: 0.0.0.0/0, ::/0
>  latest handshake: 20 seconds ago
>  transfer: 4.23 KiB received, 1.39 GiB sent
>  persistent keepalive: every 33 seconds
>
>
> root at lenovo# route
> Kernel IP Routentabelle
> Ziel            Router          Genmask         Flags Metric Ref    Use Iface
> default         _gateway        0.0.0.0         UG    50     0        0 wg1
> default         _gateway        0.0.0.0         UG    600    0        0 wlp0s12f0
> _gateway        0.0.0.0         255.255.255.255 UH    20050  0        0 wg1
> 10.0.2.0        0.0.0.0         255.255.255.0   U     600    0        0 wlp0s12f0
> 192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
>
>
> '''
>


From freyermuth at physik.uni-bonn.de  Fri Sep 24 17:57:35 2021
From: freyermuth at physik.uni-bonn.de (Oliver Freyermuth)
Date: Fri, 24 Sep 2021 19:57:35 +0200
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CALaUSusvu8iJTXNc_07=tQ=yNKJ+HXOe1J5A=HRyAAJbzDjjYg@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
 <CALaUSusvu8iJTXNc_07=tQ=yNKJ+HXOe1J5A=HRyAAJbzDjjYg@mail.gmail.com>
Message-ID: <adac36f3-e33c-606e-d287-c11467b70606@physik.uni-bonn.de>

Awesome indeed :-).
I'll contact our two affected users once 0.4.10 is released, especially the one who managed to trigger it twice in one week
should be a good test candidate.

Cheers and a nice weekend,
	Oliver

Am 24.09.21 um 19:53 schrieb Joshua Sjoding:
> Awesome! Can do. Thanks Jason!
> 
> Joshua Sjoding
> SCJ Alliance
> IT Specialist
> 
> On Fri, Sep 24, 2021 at 10:49 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>>
>> Hey guys,
>>
>> I think we might be onto something with https://w-g.pw/l/ZO5Z ...
>>
>> I'm going to cut a new release in the next few hours here. When that's
>> released, would you try updating to 0.4.10, going back to using the
>> kernel implementation, and letting me know whether the problem
>> resurfaces? In the absence of being able to locally produce this on a
>> debuggable machine, I think this kind of trial and error is all we've
>> got. Hopefully the theory behind https://w-g.pw/l/ZO5Z is correct.
>>
>> Jason


-- 
Oliver Freyermuth
Universit?t Bonn
Physikalisches Institut, Raum 1.047
Nu?allee 12
53115 Bonn
--
Tel.: +49 228 73 2367
Fax:  +49 228 73 7869
--

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5432 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20210924/4f943392/attachment.p7s>

From Arlo at StarcubeDesign.com  Fri Sep 24 20:15:44 2021
From: Arlo at StarcubeDesign.com (Arlo Clauser)
Date: Fri, 24 Sep 2021 20:15:44 +0000
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <CAHmME9rknanKEdk8L5PJxbg1OZejN59z5xuh5y54O7y+zWb1nw@mail.gmail.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
 <CAHmME9rknanKEdk8L5PJxbg1OZejN59z5xuh5y54O7y+zWb1nw@mail.gmail.com>
Message-ID: <3A98C85E-26A7-4A7B-84E3-2A512DE1C3BA@StarcubeDesign.com>

My trouble cases are installing it now. Thanks!

> On Sep 24, 2021, at 3:59 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 
> On Fri, Sep 24, 2021 at 11:48 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> I'm going to cut a new release in the next few hours here. When that's
>> released
> 
> v0.4.10 is now released.


From jandreini at geonerco.com  Fri Sep 24 20:17:27 2021
From: jandreini at geonerco.com (John-Paul Andreini)
Date: Fri, 24 Sep 2021 20:17:27 +0000
Subject: Windows stuck in boot after WireGuard update (switch to
 WireGuardNT?)
In-Reply-To: <3A98C85E-26A7-4A7B-84E3-2A512DE1C3BA@StarcubeDesign.com>
References: <e0d4dcbb-b0c8-1214-ff0c-c856d168d67f@physik.uni-bonn.de>
 <CAHmME9oSSzJU4H8jc__HiFsexpB6jJUKM84kN+_9WesoTSMMsQ@mail.gmail.com>
 <CAHmME9rknanKEdk8L5PJxbg1OZejN59z5xuh5y54O7y+zWb1nw@mail.gmail.com>
 <3A98C85E-26A7-4A7B-84E3-2A512DE1C3BA@StarcubeDesign.com>
Message-ID: <d63dde47ad8d4a28b7dd48fe83f15841@geonerco.com>

I'll roll it as well. If you see a news item about a murdered IT admin you'll know the change didn't work this time and my users have sought retribution.

John-Paul

IMPORTANT/CONFIDENTIAL:  This e-mail and any attachments may contain confidential information protected by the attorney-client privilege or other privileges, and intended for use only by the intended recipient(s).  If you have received this e-mail in error, please do not read, reproduce or distribute the contents, but rather, immediately notify the sender, delete the e-mail and destroy all copies of the e-mail and any attachments.  Pursuant to corporate policy and resolutions, E-mail correspondence is insufficient to amend or modify contracts.
-----Original Message-----
From: Arlo Clauser <Arlo at StarcubeDesign.com>
Sent: Friday, September 24, 2021 1:16 PM
To: Jason A. Donenfeld <Jason at zx2c4.com>
Cc: Oliver Freyermuth <freyermuth at physik.uni-bonn.de>; Joshua Sjoding <joshua.sjoding at scjalliance.com>; John-Paul Andreini <jandreini at geonerco.com>; WireGuard mailing list <wireguard at lists.zx2c4.com>
Subject: Re: Windows stuck in boot after WireGuard update (switch to WireGuardNT?)

CAUTION - This message originated outside of the Company.

My trouble cases are installing it now. Thanks!

> On Sep 24, 2021, at 3:59 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> On Fri, Sep 24, 2021 at 11:48 AM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>> I'm going to cut a new release in the next few hours here. When
>> that's released
>
> v0.4.10 is now released.



From alexis.geoffrey97 at gmail.com  Sun Sep 26 00:43:32 2021
From: alexis.geoffrey97 at gmail.com (Alexis Geoffrey)
Date: Sat, 25 Sep 2021 19:43:32 -0500
Subject: Can't add search domain in Wireguard Android App
Message-ID: <CAKFP4-gORakAyi7A+f2uMwRiE5LT5Ui7rBgZedqoBPcV6Q0M0Q@mail.gmail.com>

Hello,

I'm not sure if this has been posted before, but I am unable to add a
custom search domain to the "DNS servers" field of the Wireguard
Android app. The app responds "Cannot parse IP address "<my local
domain>" in Interface's DNS." Is there an alternative way to do this
on Android, or will this feature be added in a future update? Or is
simply a result of running wireguard as non-root, and so this is
impossible on an Android phone?

Thanks,
Alexis

From Jason at zx2c4.com  Sun Sep 26 04:24:20 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Sat, 25 Sep 2021 22:24:20 -0600
Subject: Can't add search domain in Wireguard Android App
In-Reply-To: <CAKFP4-gORakAyi7A+f2uMwRiE5LT5Ui7rBgZedqoBPcV6Q0M0Q@mail.gmail.com>
References: <CAKFP4-gORakAyi7A+f2uMwRiE5LT5Ui7rBgZedqoBPcV6Q0M0Q@mail.gmail.com>
Message-ID: <CAHmME9o2+1Wrmd9y1i-YLwQpa4rHTc_1CEbbmA_f4_mKj2AYqg@mail.gmail.com>

Hi Alexis,

Thanks for the reminder to actually implement this. Voila:
https://git.zx2c4.com/wireguard-android/commit/?id=3935a369b866c67705f3e27944be56b94ea2b245

Jason

From jeremy at pregonetwork.net  Sun Sep 26 11:02:20 2021
From: jeremy at pregonetwork.net (=?UTF-8?B?SsOpcsOpbXkgUHJlZ28=?=)
Date: Sun, 26 Sep 2021 13:02:20 +0200
Subject: wireguard android don't prefer IPV6 endpoint
In-Reply-To: <9367b4c7-73a1-93f6-ec6d-6d7c0cca25cd@pregonetwork.net>
References: <ead64d0f-af1e-8d5c-3d87-ed14902c5e1e@pregonetwork.net>
 <64137c2f-266a-1a06-9130-e8b42ecd4edf@pregonetwork.net>
 <37dc844baef3dd8540df172318dafa21@msfjarvis.dev>
 <9367b4c7-73a1-93f6-ec6d-6d7c0cca25cd@pregonetwork.net>
Message-ID: <f1b3f08f-3633-48d5-065d-b126eb32be51@pregonetwork.net>

Hello,

I think it is useful that I revive this topic.

is it possible to add an option so that i can use an ipv4 / ipv6 
endpoint but using ipv6 by default when available?

With the shortage of ipv4, internet operators now very often provide 
subscribers with native ipv6 but ipv4 in tunnel, hence the performance 
of the wireguard tunnel is affected by this, as it uses ipv4 by default.

if this is not possible in the official client, which wireguard client 
would allow me to have this behavior?

Thanks,

Jerem
Le 03/01/2021 ? 16:58, J?r?my Prego a ?crit?:
> hello Harsh,
>
>> The WireGuard Android client is designed to prefer IPv4 over IPv6 as
>> of now
> why did you make this choice? is there a known bug with ipv6? I think it
> would be useful to put an option in the wireguard application, so that
> we can choose.
>
> if I want to use an ipv6 tunnel, do I have another solution than to
> create 2 tunels, one in ipv6 only, and another in ipv4 in order to be
> able to use ipv6 when available and ipv4 when the place where i am has
> no ipv6?
>
> I did not manage to add 2 endpoint in a single tunnel to put an endpoint
> only ipv6 and another endpoint ipv4 / ipv6 to bypass the problem
>
> thanks,
>
> Jerem
> Le 03/01/2021 ? 14:48, Harsh Shandilya a ?crit?:
>> Hey J?r?my,
>>
>> On 2021-01-02 08:27, J?r?my Prego wrote:
>>> I confirm the same problem in wifi
>>>
>>> Le 27/12/2020 ? 07:02, J?r?my Prego a ?crit?:
>>>> hello,
>>>>
>>>> I've always encountered a bug with android wireguard when using an ipv4
>>>> / ipv6 endpoint.
>>>>
>>>> I tested with two phones:
>>>> Huawei p10 lite android 8.0 emui 8
>>>> Xiaomi poco m3 android 10.0 miui 12
>>>>
>>>> When i'm in LTE (not yet been able to test in wifi), wireguard connects
>>>> to the endpoint in ipv4 and not in ipv6, and i don't understand why it
>>>> is doing that.
>> The WireGuard Android client is designed to prefer IPv4 over IPv6 as
>> of now
>> (https://git.zx2c4.com/wireguard-android/tree/tunnel/src/main/java/com/wireguard/config/InetEndpoint.java#n97).
>> This may or may not change in the future, and we'll announce here if
>> it does.
>>
>>>> However, chrome, for example, does use ipv6 by default and not ipv4.
>>>>
>>>> My phone does recover an ipv6 in 2a01: cb1a ........ / 64 and not an
>>>> ipv6 type fc00 / fd00 / fe80 ...
>>>> I also specify that if I only have an AAAA record, the tunnel works
>>>> fine
>>>> in ipv6. but suddenly, I can no longer connect to wifi which only
>>>> have ipv4.
>>>>
>>>> I would like wireguard to favor ipv6 when it is available, and
>>>> otherwise
>>>> switch to ipv4.
>>>>
>>>> Is it possible ?
>>>>
>>>> Thanks,
>>>>
>>>> Jerem
>> Cheers,
>> Harsh


From tlhackque at yahoo.com  Sun Sep 26 11:50:16 2021
From: tlhackque at yahoo.com (tlhackque)
Date: Sun, 26 Sep 2021 07:50:16 -0400
Subject: wireguard android don't prefer IPV6 endpoint
In-Reply-To: <f1b3f08f-3633-48d5-065d-b126eb32be51@pregonetwork.net>
References: <ead64d0f-af1e-8d5c-3d87-ed14902c5e1e@pregonetwork.net>
 <64137c2f-266a-1a06-9130-e8b42ecd4edf@pregonetwork.net>
 <37dc844baef3dd8540df172318dafa21@msfjarvis.dev>
 <9367b4c7-73a1-93f6-ec6d-6d7c0cca25cd@pregonetwork.net>
 <f1b3f08f-3633-48d5-065d-b126eb32be51@pregonetwork.net>
Message-ID: <39d400ca-bc03-0ad9-5fb9-726376ce6047@yahoo.com>

On 26-Sep-21 07:02, J?r?my Prego wrote:
> Hello,
>
> I think it is useful that I revive this topic.
>
> is it possible to add an option so that i can use an ipv4 / ipv6
> endpoint but using ipv6 by default when available?
>
> With the shortage of ipv4, internet operators now very often provide
> subscribers with native ipv6 but ipv4 in tunnel, hence the performance
> of the wireguard tunnel is affected by this, as it uses ipv4 by default.
>
> if this is not possible in the official client, which wireguard client
> would allow me to have this behavior?
>
> Thanks,
>
> Jerem
> Le 03/01/2021 ? 16:58, J?r?my Prego a ?crit?:
>> hello Harsh,
>>
>>> The WireGuard Android client is designed to prefer IPv4 over IPv6 as
>>> of now
>> why did you make this choice? is there a known bug with ipv6? I think it
>> would be useful to put an option in the wireguard application, so that
>> we can choose.
>>
>> if I want to use an ipv6 tunnel, do I have another solution than to
>> create 2 tunels, one in ipv6 only, and another in ipv4 in order to be
>> able to use ipv6 when available and ipv4 when the place where i am has
>> no ipv6?
>>
>> I did not manage to add 2 endpoint in a single tunnel to put an endpoint
>> only ipv6 and another endpoint ipv4 / ipv6 to bypass the problem
>>
>> thanks,
>>
>> Jerem
>> Le 03/01/2021 ? 14:48, Harsh Shandilya a ?crit?:
>>> Hey J?r?my,
>>>
>>> On 2021-01-02 08:27, J?r?my Prego wrote:
>>>> I confirm the same problem in wifi
>>>>
>>>> Le 27/12/2020 ? 07:02, J?r?my Prego a ?crit?:
>>>>> hello,
>>>>>
>>>>> I've always encountered a bug with android wireguard when using an
>>>>> ipv4
>>>>> / ipv6 endpoint.
>>>>>
>>>>> I tested with two phones:
>>>>> Huawei p10 lite android 8.0 emui 8
>>>>> Xiaomi poco m3 android 10.0 miui 12
>>>>>
>>>>> When i'm in LTE (not yet been able to test in wifi), wireguard
>>>>> connects
>>>>> to the endpoint in ipv4 and not in ipv6, and i don't understand
>>>>> why it
>>>>> is doing that.
>>> The WireGuard Android client is designed to prefer IPv4 over IPv6 as
>>> of now
>>> (https://git.zx2c4.com/wireguard-android/tree/tunnel/src/main/java/com/wireguard/config/InetEndpoint.java#n97).
>>>
>>> This may or may not change in the future, and we'll announce here if
>>> it does.
>>>
>>>>> However, chrome, for example, does use ipv6 by default and not ipv4.
>>>>>
>>>>> My phone does recover an ipv6 in 2a01: cb1a ........ / 64 and not an
>>>>> ipv6 type fc00 / fd00 / fe80 ...
>>>>> I also specify that if I only have an AAAA record, the tunnel works
>>>>> fine
>>>>> in ipv6. but suddenly, I can no longer connect to wifi which only
>>>>> have ipv4.
>>>>>
>>>>> I would like wireguard to favor ipv6 when it is available, and
>>>>> otherwise
>>>>> switch to ipv4.
>>>>>
>>>>> Is it possible ?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jerem
>>> Cheers,
>>> Harsh
>
I agree that it should be selectable - but note that there are many
inverse situations, where IPv6 is tunneled and IPv4 is direct.? There
are still ISPs (including half of mine) that will not provide end users
with an IPv6 native connection.?

This is a bit difficult, since the situation can occur at both the
client and server end.? For the server end, if the client knows what's
best for the server, the tunnel configuration could be set to prefer the
best protocol.? But for a roaming client, it's not so easy.? E.g. Using
Cellphone wireless is almost always IPv6, but if connected via WiFi,
it's almost always IPv4.? And if you plug your portable machine into a
client's ethernet, you don't know what you'll get (or whether its
connection is tunneled).

So if the client does anything, it probably needs a 3-way switch: "Use
IPv4", "Use IPv6", "Autoselect".? (Or if you really want to complicate
things, you could break Autoselect into Auto-prefer IPv4 and Auto-prefer
IPv6.)? While this makes sense to technical people, it's not obvious
that the performance difference is worth exposing the complication to
all users.

Since there's also the issue of which DNS servers to use when resolving
the endpoint name - perhaps it's time for an "advanced" sub-panel of
options in the GUI.? Keeping things simple for the casual/first-time
user is a strength of WireGuard.

For what it's worth, you can specify a numeric IP address to force IPv6
- e.g. [2001:db8::1234]:5522

Of course, that doesn't work if your endpoint address is dynamic & you
need the DNS lookup.

With respect to Chrome - last I knew, it uses the "Happy Eyeballs"
(RFC6555/8305) algorithm, which tries to prefer IPv6.? And there's
no(longer) any way to influence it in Chrome.

Basic address selection is up to the OS - see rfc6724, 3484.? Most
provide a way to specify a global preference - which in the situation
you described, you probably want to do when not tunneled.? E.g. for
glib-based systems, see /etc/gai.conf, and for windows see the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\
registry key.

If you control the endpoint, another approach is to add a DNS record
that only returns the AAAA record (for the IPv6) address, e.g.
endpoint.v6.example.net.? For situations like this, I often have three
address records - the generic host.example.net, and host.v6.example.net
and host.v4.example.net.? But I try not to expose the latter two.

I wish things were simpler...





From alexis.geoffrey97 at gmail.com  Sun Sep 26 14:45:55 2021
From: alexis.geoffrey97 at gmail.com (Alexis Geoffrey)
Date: Sun, 26 Sep 2021 09:45:55 -0500
Subject: Can't add search domain in Wireguard Android App
In-Reply-To: <CAHmME9o2+1Wrmd9y1i-YLwQpa4rHTc_1CEbbmA_f4_mKj2AYqg@mail.gmail.com>
References: <CAKFP4-gORakAyi7A+f2uMwRiE5LT5Ui7rBgZedqoBPcV6Q0M0Q@mail.gmail.com>
 <CAHmME9o2+1Wrmd9y1i-YLwQpa4rHTc_1CEbbmA_f4_mKj2AYqg@mail.gmail.com>
Message-ID: <CAKFP4-jh1OvViU3LO=zn0kzcZu6znG7iAO4JHDCVE=6ogrkO=w@mail.gmail.com>

Wow! Thanks for such a quick turnaround! Looking forward to
downloading the update.

Thanks for all your great work on Wireguard,
Alexis

From el3xyz at protonmail.com  Sun Sep 26 12:09:18 2021
From: el3xyz at protonmail.com (el3xyz)
Date: Sun, 26 Sep 2021 12:09:18 +0000
Subject: WireGuard with obfuscation support
Message-ID: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>

Hey all,

I guess this topic is, at the very least, not new, but there is still no solution. In the country where I live internet censorship increases year after year and more network operators start blocking WG. With that being done I'm stuck to ShadowSocks which is slower and less secure on desktops then WG. That said I decided to implement obfuscation for WG at least for my own use and kindly asking for code review and possible improvements:

https://github.com/el3xyz/wireguard-linux-compat

To my understanding there are several ways WG is detected by DPI
* Port 51820 (easily fixed)
* 4-byte message tag
* Fixed message lengths
* MAC2 which is all zeroes, unless cookie message is received (high load scenario)


To make detection more difficult two things are being done
* handshake initiation, response and cookie messages are padded with random sized garbage
* Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions).

I have tools and Linux driver working already so anyone interested can try this out.
Cheers

From nico.schottelius at ungleich.ch  Mon Sep 27 00:53:08 2021
From: nico.schottelius at ungleich.ch (Nico Schottelius)
Date: Mon, 27 Sep 2021 09:53:08 +0900
Subject: WireGuard with obfuscation support
In-Reply-To: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
Message-ID: <877df2d5px.fsf@ungleich.ch>


Hey,

el3xyz <el3xyz at protonmail.com> writes:
> [...]
> To make detection more difficult two things are being done
> * handshake initiation, response and cookie messages are padded with random sized garbage
> * Up to 192 bytes of each message is encrypted with obfuscation key derived from peer public key (different keys are used in different directions).
> [...]

I did not have a look at the code itself, but travelling around the
world, I appreciate the direction a lot. While from a safety perspective
this does not anything, it can add a lot to the usability / being able
to use wireguard at all.

I'd appreciate if wireguard upstream would take this in, maybe even
supporting multiple / dynamic listen ports.

Best regards,

Nico



--
Sustainable and modern Infrastructures by ungleich.ch

From bruno at wolff.to  Mon Sep 27 07:11:30 2021
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 27 Sep 2021 02:11:30 -0500
Subject: WireGuard with obfuscation support
In-Reply-To: <877df2d5px.fsf@ungleich.ch>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch>
Message-ID: <20210927071130.GA13681@wolff.to>

On Mon, Sep 27, 2021 at 09:53:08 +0900,
  Nico Schottelius <nico.schottelius at ungleich.ch> wrote:
>
>I'd appreciate if wireguard upstream would take this in, maybe even
>supporting multiple / dynamic listen ports.

The problem is mostly orthogonal to Wireguard. There isn't going to be a 
one size fits all solution for hiding traffic. Failures in hiding traffic 
are potentially very bad for individuals. As such general solutions are 
not something you can recommend universally to people, as amateurs are 
not going to be able to make good decisions about the risks and some may 
get themselves tortured and killed.

This may not be something the developers for Wireguard want to be 
responsible for.

From rm at romanrm.net  Mon Sep 27 07:34:39 2021
From: rm at romanrm.net (Roman Mamedov)
Date: Mon, 27 Sep 2021 12:34:39 +0500
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927071130.GA13681@wolff.to>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
Message-ID: <20210927123439.7a551913@nvm>

On Mon, 27 Sep 2021 02:11:30 -0500
Bruno Wolff III <bruno at wolff.to> wrote:

> On Mon, Sep 27, 2021 at 09:53:08 +0900,
>   Nico Schottelius <nico.schottelius at ungleich.ch> wrote:
> >
> >I'd appreciate if wireguard upstream would take this in, maybe even
> >supporting multiple / dynamic listen ports.
> 
> The problem is mostly orthogonal to Wireguard. There isn't going to be a 
> one size fits all solution for hiding traffic. Failures in hiding traffic 
> are potentially very bad for individuals. As such general solutions are 
> not something you can recommend universally to people, as amateurs are 
> not going to be able to make good decisions about the risks and some may 
> get themselves tortured and killed.
> 
> This may not be something the developers for Wireguard want to be 
> responsible for.

No need to make DPI's job especially easy either.

Don't over-estimate the resources available to DPIs, if there aren't easy
ways to block, it might be almost as good as unblockable.

And it is far from all cases that hiding traffic would result in bad
consequences. Just hiding it enough so it evades the dumb automated filter,
many people will thank you.

As far as I understand right now WireGuard is very vulnerable to being
blocked, due to the fixed 4 bytes at the beginning(?) of each packet. At least
that needs to be randomized/encrypted. Just make the entire packet look like
random noise - that's the sign of good crypto, right? It is even somewhat
surprising as to why that's not the case already.

-- 
With respect,
Roman

From nico.schottelius at ungleich.ch  Mon Sep 27 07:44:58 2021
From: nico.schottelius at ungleich.ch (Nico Schottelius)
Date: Mon, 27 Sep 2021 16:44:58 +0900
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927071130.GA13681@wolff.to>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
Message-ID: <87y27ibgjp.fsf@ungleich.ch>


Bruno,

thanks for raising 2 very important points:

Bruno Wolff III <bruno at wolff.to> writes:

> On Mon, Sep 27, 2021 at 09:53:08 +0900,
>  Nico Schottelius <nico.schottelius at ungleich.ch> wrote:
>>
>>I'd appreciate if wireguard upstream would take this in, maybe even
>>supporting multiple / dynamic listen ports.
>
> The problem is mostly orthogonal to Wireguard. There isn't going to be
> a one size fits all solution for hiding traffic. Failures in hiding
> traffic are potentially very bad for individuals. As such general
> solutions are not something you can recommend universally to people,
> as amateurs are not going to be able to make good decisions about the
> risks and some may get themselves tortured and killed.

1) being able to communicate for non-tech savvy users

This is a very important point, especially a failure to do so might be
critical in reality like you pointed out. So the easier we make it for
non-tech people to "just get it working", many more life's will be saved
from torture. Because the alternative are insecure communication channels.

> This may not be something the developers for Wireguard want to be
> responsible for.

2) The responsibility of software developers

As usual with GPL/similar licenses, software is provided AS-IS. We are
not selling a "fully autonomous car" here that is actually not able to
drive on its own, but instead giving a warranty free software to people.

It's important to raise these points, but from what I can see the easier
we make it for people to securely communicate, the less likely threats
arrive.

Outside of the scope of wireguard I see tunnel combinations like moving
wireguard traffic through udp+tcp/53, tcp/80+443, which are also
interesting options, but are probably solved with other tunneling tools.

Cheers,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

From stromberg at mullvad.net  Mon Sep 27 08:17:42 2021
From: stromberg at mullvad.net (=?UTF-8?Q?Fredrik_Str=C3=B6mberg?=)
Date: Mon, 27 Sep 2021 10:17:42 +0200
Subject: WireGuard with obfuscation support
In-Reply-To: <87y27ibgjp.fsf@ungleich.ch>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <87y27ibgjp.fsf@ungleich.ch>
Message-ID: <CANTUoedCxBRNHXj1C+moFx2Ut4uK4JN+eNe7vFjsyec1UVs+EQ@mail.gmail.com>

Hi everyone,

On Mon, Sep 27, 2021 at 9:55 AM Nico Schottelius
<nico.schottelius at ungleich.ch> wrote:
> Bruno Wolff III <bruno at wolff.to> writes:
> > On Mon, Sep 27, 2021 at 09:53:08 +0900,
> >  Nico Schottelius <nico.schottelius at ungleich.ch> wrote:
> >
> > The problem is mostly orthogonal to Wireguard. There isn't going to be
> > a one size fits all solution for hiding traffic.

Exactly. And it would be a big mistake to attempt to merge obfuscation
support into WireGuard itself. Tor's approach of pluggable transports
is probably the right one.

https://www.wireguard.com/known-limitations/
"WireGuard does not focus on obfuscation. Obfuscation, rather, should
happen at a layer above WireGuard, with WireGuard focused on providing
solid crypto with a simple implementation. It is quite possible to
plug in various forms of obfuscation, however."

Here are my arguments:
https://lists.zx2c4.com/pipermail/wireguard/2018-September/003292.html

Cheers,
Fredrik Stromberg

From bruno at wolff.to  Mon Sep 27 09:14:35 2021
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 27 Sep 2021 04:14:35 -0500
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927123439.7a551913@nvm>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm>
Message-ID: <20210927091435.GA10234@wolff.to>

On Mon, Sep 27, 2021 at 12:34:39 +0500,
  Roman Mamedov <rm at romanrm.net> wrote:
>On Mon, 27 Sep 2021 02:11:30 -0500
>
>Don't over-estimate the resources available to DPIs, if there aren't easy
>ways to block, it might be almost as good as unblockable.
>
>And it is far from all cases that hiding traffic would result in bad
>consequences. Just hiding it enough so it evades the dumb automated filter,
>many people will thank you.

If someone is having their Wireguard traffic blogged, there is a good 
chance that they will be negative consequences to trying to evade the 
block. Just getting detected will often be enough to trigger these 
consequences, even if the traffic is getting through.

This isn't a simple problem. The assumption is that someone is seeing 
your network traffic and blocking it. They are still going to see it 
even if you disguise it. So you are going to need to disquise it as 
something that whoever is watching isn't going to care about. That 
is going to vary a lot depending on who is watching. You may also need 
to hide who you are communicating with. In some cases that will be even 
more important.

There are going to be a number of ways to detect Wireguard traffic and 
it is pretty unlikely that the bar for detection can be raised enough to 
be relevant with a few simple changes to the protocol.

This suggest that Wireguard is not the correct place to be doing these 
things. As suggested in another followup, this fits a lot closer to 
tor's mission and that would probably be a better place to look for 
help.

From rm at romanrm.net  Mon Sep 27 09:36:28 2021
From: rm at romanrm.net (Roman Mamedov)
Date: Mon, 27 Sep 2021 14:36:28 +0500
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927091435.GA10234@wolff.to>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
Message-ID: <20210927143628.36c2ceab@nvm>

On Mon, 27 Sep 2021 04:14:35 -0500
Bruno Wolff III <bruno at wolff.to> wrote:

> This isn't a simple problem. The assumption is that someone is seeing 
> your network traffic and blocking it.

The assumption is that there's an appliance at the ISP which has a DROP rule
for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules
to process as well, so it can't spend "too much" time on specifically WG.

> They are still going to see it  even if you disguise it.

With obfuscation there would be UDP packets of random junk, and it would be a
much harder job to come up with a rule to drop those without affecting
anything else.

> So you are going to need to disquise it as  something that whoever is
> watching isn't going to care about. That is going to vary a lot depending on
> who is watching. You may also need to hide who you are communicating with.
> In some cases that will be even more important.

You are going full-on "Enemy of the state" movie. The reality is most often a
lot simpler and more benign.

> There are going to be a number of ways to detect Wireguard traffic and 
> it is pretty unlikely that the bar for detection can be raised enough to 
> be relevant with a few simple changes to the protocol.

That's not a justification for not trying at all.

-- 
With respect,
Roman

From bruno at wolff.to  Mon Sep 27 10:21:57 2021
From: bruno at wolff.to (Bruno Wolff III)
Date: Mon, 27 Sep 2021 05:21:57 -0500
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927143628.36c2ceab@nvm>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm>
Message-ID: <20210927102157.GA23755@wolff.to>

On Mon, Sep 27, 2021 at 14:36:28 +0500,
  Roman Mamedov <rm at romanrm.net> wrote:
>On Mon, 27 Sep 2021 04:14:35 -0500
>Bruno Wolff III <bruno at wolff.to> wrote:
>
>> This isn't a simple problem. The assumption is that someone is seeing
>> your network traffic and blocking it.
>
>The assumption is that there's an appliance at the ISP which has a DROP rule
>for UDP with 4 fixed bytes at a fixed offset. It has five hundreds other rules
>to process as well, so it can't spend "too much" time on specifically WG.
>
>> They are still going to see it  even if you disguise it.
>
>With obfuscation there would be UDP packets of random junk, and it would be a
>much harder job to come up with a rule to drop those without affecting
>anything else.

If your ISP is blocking your Wireguard traffic call them up and complain.

From konstantin at linuxfoundation.org  Mon Sep 27 13:01:38 2021
From: konstantin at linuxfoundation.org (Konstantin Ryabitsev)
Date: Mon, 27 Sep 2021 09:01:38 -0400
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927102157.GA23755@wolff.to>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm> <20210927102157.GA23755@wolff.to>
Message-ID: <20210927130138.54zkvlokogcu6o3q@meerkat.local>

On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote:
> > With obfuscation there would be UDP packets of random junk, and it would be a
> > much harder job to come up with a rule to drop those without affecting
> > anything else.
> 
> If your ISP is blocking your Wireguard traffic call them up and complain.

There have been times when I found myself briefly at a location that didn't
allow wireguard traffic, like an airport or a public library. Complaining
wouldn't have been a useful course of action to take, since I needed a
solution at that particular time and place.

-K

From lists at lonnie.abelbeck.com  Mon Sep 27 13:48:38 2021
From: lists at lonnie.abelbeck.com (Lonnie Abelbeck)
Date: Mon, 27 Sep 2021 08:48:38 -0500
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927130138.54zkvlokogcu6o3q@meerkat.local>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm> <20210927102157.GA23755@wolff.to>
 <20210927130138.54zkvlokogcu6o3q@meerkat.local>
Message-ID: <9C6A0167-0DC0-4500-A843-AD03688FD05D@lonnie.abelbeck.com>



> On Sep 27, 2021, at 8:01 AM, Konstantin Ryabitsev <konstantin at linuxfoundation.org> wrote:
> 
> On Mon, Sep 27, 2021 at 05:21:57AM -0500, Bruno Wolff III wrote:
>>> With obfuscation there would be UDP packets of random junk, and it would be a
>>> much harder job to come up with a rule to drop those without affecting
>>> anything else.
>> 
>> If your ISP is blocking your Wireguard traffic call them up and complain.
> 
> There have been times when I found myself briefly at a location that didn't
> allow wireguard traffic, like an airport or a public library. Complaining
> wouldn't have been a useful course of action to take, since I needed a
> solution at that particular time and place.

Public hotspots may just be blocking UDP/51820, not DPI.

Some time ago Jason posted an iptables REDIRECT workaround at your WG "server" endpoint [1]

I have found typically either 443 or 4500 will work if 51820 is blocked.

Lonnie

[1] https://lists.zx2c4.com/pipermail/wireguard/2018-November/003503.html


From coder at poorlab.com  Mon Sep 27 15:28:52 2021
From: coder at poorlab.com (StarBrilliant)
Date: Mon, 27 Sep 2021 15:28:52 +0000
Subject: WireGuard with obfuscation support
In-Reply-To: <20210927102157.GA23755@wolff.to>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm> <20210927102157.GA23755@wolff.to>
Message-ID: <d071a9ed-a1cf-4b4c-85ba-8a918a6e331a@www.fastmail.com>

On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote:
> If your ISP is blocking your Wireguard traffic call them up and complain.

All ISPs in China is blocking Wireguard traffic. If you call any of them up, you will end up in jail. There was a case where one user sued their ISP for blocking Google, and got prosecuted until disappear in public.

I believe the original poster is located in China rather than other countries, because the word ?Shadowsocks? was mentioned, which is the only operable proxy software there -- its obfuscation is strong, but is slow and never cryptographically proved safe.

I would highly recommend you to test Wireguard on a virtual host in China to experience how the DPI is carried out, or to run a VPN service for Chinese users. The DPI system tries to create evidences to fool the user into believing it to be a network congestion, rather than an interference. The traffic will get interrupted after a few days, with increased packet loss rate each day. After a certain number of days, all packets will get dropped.

For any of you who is curious: The DPI system uses a statistical model, which means you get a higher chance of blocking if the source ASN is from a data center rather ran residential Internet; or if your size / timing / number of packets also match the characteristics of web browsing in addition to the usual Wireguard pattern. The sensitivity can even be tuned so the interference becomes stronger during June, August, and October.

It is so unfortunate this situation affects 1/5 of the world population. The Chinese users used to be too optimistic about Wireguard. Developing an obfuscation plugin framework is not sufficient to fight against it, but there aren't too much that one can do.

From nico.schottelius at ungleich.ch  Mon Sep 27 15:59:19 2021
From: nico.schottelius at ungleich.ch (Nico Schottelius)
Date: Tue, 28 Sep 2021 00:59:19 +0900
Subject: WireGuard with obfuscation support
In-Reply-To: <d071a9ed-a1cf-4b4c-85ba-8a918a6e331a@www.fastmail.com>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm> <20210927102157.GA23755@wolff.to>
 <d071a9ed-a1cf-4b4c-85ba-8a918a6e331a@www.fastmail.com>
Message-ID: <87tui6yozj.fsf@ungleich.ch>


StarBrilliant <coder at poorlab.com> writes:

> On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote:
>> If your ISP is blocking your Wireguard traffic call them up and complain.
>
> All ISPs in China is blocking Wireguard traffic. If you call any of
> them up, you will end up in jail. There was a case where one user sued
> their ISP for blocking Google, and got prosecuted until disappear in
> public.
> [...]

Thanks a lot for the detailed explanation. While we have become a bit
off-topic (more of the why then the how) in regards to wireguard, I
think above explanation is important.

Wireguard's purpose is to be a secure VPN tunnel and I personally would
love if we can add "reliable" to its feature list. However that would
need more advanced support, like obfuscation is providing.

I'm not saying obfuscation is the only method, but compared to
a DPI with statistical analysis, I think we are pretty far away from
being reliable in hostile networks. Maybe extending wireguard with
obfuscation is out of scope of this project, but then it might be an
idea to wrap the wireguard traffic into other protocols.

I'm not sure how much wireguard depends on the IP/UDP layers, but
assuming it only uses it for payload, maybe it makes sense to
wrap wireguard into HTTP, HTTPS, SMTP (+TLS), IMAP(S) or even DNS
(slow). I am aware that there is a variety of tools out there that
handle some of the tunnel ideas.

Given that all of these approaches are actually rather trivial to
implement, is there any easy way to grab the outgoing wireguard packets
without the need of creating n artifical local UDP endpoints?

Best regards,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

From Jason at zx2c4.com  Mon Sep 27 16:21:03 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Sep 2021 10:21:03 -0600
Subject: WireGuard with obfuscation support
In-Reply-To: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
Message-ID: <CAHmME9rDj9dDGSY0E6ZtE88vObS5Hjd=ocpt3hz1gfVAkaxPgg@mail.gmail.com>

Hey Evgeny,

There are some neat aspects of the approach here. Encrypting using the
pubkey has the nice effect of making packets look like noise while
also being sufficiently peer-linked that it might not be super
feasible to detect (though still possible I suppose).

I don't think we'd merge something like this into wireguard-itself,
unfortunately. Obfuscation is a bit of a cat and mouse game, and were
we to bake a handful of methods into wireguard, much focus would be
spent on detecting those, and then the whole thing would be moot.

>From my own obfuscation projects, I've found the most effective
techniques involve mimicry of other explicitly-allowed protocols,
rather than just turning packets into noise, and mimicking the related
packet timing and length relations of those protocols too. It's
possible to do this in part using Markov chains, but also for your
likely use case, you may be able to just code logic for fake tcp +
http -looking sessions, or perhaps quic in the future.

But your likely use case is also not likely to be the same as others'
use cases for obfuscation. For example, while much obfuscation focuses
on censorship resistance, there's another corner that focuses on IDS
evasion, like hiding inside of Kerberos or RDP or even resembling
SIGTRAN packets. And even in the censorship resistance space, there
are often important tradeoffs to be made between performance and
detection: do you want your connection to be as speedy as possible, or
do you want to ensure that you won't be detected? What are the
repercussions of failure for each case? And moreover, what about when
targeted traffic shaping is used in connection with DPI or related
heuristics? In that case, a popular technique appears to be adding FEC
to packets. And so on and so forth.

This all is to say that the obfuscation game is a big rabbit hole of
sorts, and there's unlikely to be one solution for the many
applications of it.

For that reason, as I've written on this list before, I think
obfuscation ought to be in a layer above wireguard, not within it. You
can do this by setting the endpoint to be a localhost udp port, or
better, by writing a netfilter module or using something like NFQUEUE
to do it in userspace. While there's a lot of enthusiasm for
"pluggable transports" and such, I actually don't think it's a bad
idea to violate the layering distinction and borrow things like peer
public keys when that makes for a potentially slicker system.

For example, I could imagine a netfilter plugin that specifically
attaches to a wireguard interface, and uses config information from it
to do per-peer obfuscation, so that additional identities don't need
to be configured. An admin would run `iptables -t mangle -A OUTPUT -m
evgeny_wg_thing --out-iface wg0 -j EVGENYS_COOL_OBFS_THING_OUT &&
iptables -t mangle -A INPUT -m evgeny_wg_thing --in-iface wg0 -j
EVGENYS_COOL_OBFS_THING_IN` and then presto, everything would work
with no additional configuration.

Splitting out your ideas into something that runs adjacent to
wireguard but works intimately with it might require a little bit more
work in the short term, but I think long term that will lead to a more
sound design, and it could grow and morph all sorts of interesting
different modes.

Jason

From coder at poorlab.com  Mon Sep 27 16:37:18 2021
From: coder at poorlab.com (StarBrilliant)
Date: Mon, 27 Sep 2021 16:37:18 +0000
Subject: WireGuard with obfuscation support
In-Reply-To: <87tui6yozj.fsf@ungleich.ch>
References: <XhEJRjPvvlk57PFUWApI0RPX2-dCuDbQ9RYxw9Y5GxzMs8YEpwVc4U-fR3avC-NT1X2UlBNQerMkOxgqrue_EEOtyZR18V329KuKev_i3aE=@protonmail.com>
 <877df2d5px.fsf@ungleich.ch> <20210927071130.GA13681@wolff.to>
 <20210927123439.7a551913@nvm> <20210927091435.GA10234@wolff.to>
 <20210927143628.36c2ceab@nvm> <20210927102157.GA23755@wolff.to>
 <d071a9ed-a1cf-4b4c-85ba-8a918a6e331a@www.fastmail.com>
 <87tui6yozj.fsf@ungleich.ch>
Message-ID: <f69bd6c2-0b56-47b7-b793-835791b4e585@www.fastmail.com>

On Mon, Sep 27, 2021, at 15:59, Nico Schottelius wrote:
> 
> StarBrilliant <coder at poorlab.com> writes:
> 
> > On Mon, Sep 27, 2021, at 10:21, Bruno Wolff III wrote:
> >> If your ISP is blocking your Wireguard traffic call them up and complain.
> >
> > All ISPs in China is blocking Wireguard traffic. If you call any of
> > them up, you will end up in jail. There was a case where one user sued
> > their ISP for blocking Google, and got prosecuted until disappear in
> > public.
> > [...]
> 
> I'm not sure how much wireguard depends on the IP/UDP layers, but
> assuming it only uses it for payload, maybe it makes sense to
> wrap wireguard into HTTP, HTTPS, SMTP (+TLS), IMAP(S) or even DNS
> (slow). I am aware that there is a variety of tools out there that
> handle some of the tunnel ideas.
> 
> Given that all of these approaches are actually rather trivial to
> implement, is there any easy way to grab the outgoing wireguard packets
> without the need of creating n artifical local UDP endpoints?
> 

For your first question: There have been multiple success stories for pluggable obfuscation layers: One from Tor Project, another from V2Ray. They proved even if any single obfuscation is not mature, as long as new obfuscation plugins emerge way way faster than their statistical model training speed, this cat-and-mouse game can win. So no worries about this question.

For the second question: This is very important because current Wireguard has huge pain with obfuscation plugins.
* Firstly, Wireguard cannot bind to localhost only. Using iptables to restrict access does not avoid port number wasting.
* Second, Wireguard can't use Unix socket for transport -- there are only 65535 UDP ports, it is not economic to waste a dozen of them just for connecting to an obfuscation plugin located at localhost.
* Last but not least, Wireguard relies on certain end-to-end features: If the a fragmented IP packet arrives, which is a feature that some obfuscation plugin relies on, Wireguard's kernel implementation will behave strangely. Also Wireguard needs to know the endpoint IP address to perform roaming.

Previously we prefer to patch the Go version because the above three issues are almost impossible to solve in kernel space. But the Wireguard upstream is going to deprecate the Go version on Linux platforms, which would not be a good news for the obfuscation world.

If Wireguard supports listening onto a Unix socket and plugin protocols like ?HAProxy protocol?, or ?Tor FTE protocol? or ?Shadowsocks SIP003 protocol? (not sure which can work with UDP), then obfuscation plugins can happily work with Wireguard.

From xiyou.wangcong at gmail.com  Tue Sep 28 03:19:38 2021
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Mon, 27 Sep 2021 20:19:38 -0700
Subject: [Patch net] wireguard: preserve skb->mark on ingress side
Message-ID: <20210928031938.17902-1-xiyou.wangcong@gmail.com>

From: Cong Wang <cong.wang at bytedance.com>

On ingress side, wg_reset_packet() resets skb->mark twice: with
skb_scrub_packet() (xnet==true) and with memset() following it. But
skb->mark does not have to be cleared at least when staying in the
same net namespace, and other tunnels preserve it too similarly,
especially vxlan.

In our use case, we would like to preserve this skb->mark to
distinguish which wireguard device the packets are routed from.

Tested-by: Peilin Ye <peilin.ye at bytedance.com>
Cc: "Jason A. Donenfeld" <Jason at zx2c4.com>
Signed-off-by: Cong Wang <cong.wang at bytedance.com>
---
 drivers/net/wireguard/queueing.h | 9 +++++++--
 drivers/net/wireguard/receive.c  | 2 +-
 drivers/net/wireguard/send.c     | 2 +-
 3 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h
index 4ef2944a68bc..3516c1c59df0 100644
--- a/drivers/net/wireguard/queueing.h
+++ b/drivers/net/wireguard/queueing.h
@@ -73,15 +73,20 @@ static inline bool wg_check_packet_protocol(struct sk_buff *skb)
 	return real_protocol && skb->protocol == real_protocol;
 }
 
-static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating)
+static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating,
+				   bool xnet)
 {
 	u8 l4_hash = skb->l4_hash;
 	u8 sw_hash = skb->sw_hash;
 	u32 hash = skb->hash;
-	skb_scrub_packet(skb, true);
+	u32 mark;
+
+	skb_scrub_packet(skb, xnet);
+	mark = skb->mark;
 	memset(&skb->headers_start, 0,
 	       offsetof(struct sk_buff, headers_end) -
 		       offsetof(struct sk_buff, headers_start));
+	skb->mark = mark;
 	if (encapsulating) {
 		skb->l4_hash = l4_hash;
 		skb->sw_hash = sw_hash;
diff --git a/drivers/net/wireguard/receive.c b/drivers/net/wireguard/receive.c
index 7dc84bcca261..385b2b60cfd9 100644
--- a/drivers/net/wireguard/receive.c
+++ b/drivers/net/wireguard/receive.c
@@ -476,7 +476,7 @@ int wg_packet_rx_poll(struct napi_struct *napi, int budget)
 		if (unlikely(wg_socket_endpoint_from_skb(&endpoint, skb)))
 			goto next;
 
-		wg_reset_packet(skb, false);
+		wg_reset_packet(skb, false, !net_eq(dev_net(peer->device->dev), dev_net(skb->dev)));
 		wg_packet_consume_data_done(peer, skb, &endpoint);
 		free = false;
 
diff --git a/drivers/net/wireguard/send.c b/drivers/net/wireguard/send.c
index 5368f7c35b4b..c77ef0815c2e 100644
--- a/drivers/net/wireguard/send.c
+++ b/drivers/net/wireguard/send.c
@@ -296,7 +296,7 @@ void wg_packet_encrypt_worker(struct work_struct *work)
 		skb_list_walk_safe(first, skb, next) {
 			if (likely(encrypt_packet(skb,
 					PACKET_CB(first)->keypair))) {
-				wg_reset_packet(skb, true);
+				wg_reset_packet(skb, true, true);
 			} else {
 				state = PACKET_STATE_DEAD;
 				break;
-- 
2.30.2


From wireguard_mailing_list_user at stdmail.de  Mon Sep 27 21:36:26 2021
From: wireguard_mailing_list_user at stdmail.de (wireguard_mailing_list_user at stdmail.de)
Date: Mon, 27 Sep 2021 21:36:26 -0000
Subject: Feature request - Number of tunnel entries in root of tray icon
 context menu
Message-ID: <163277858699.7.10950010429724590941.14337061@stdmail.de>

Hi,

the hardcoded value is 10 (in ui/tray.go)

Wouldn't it be possible to allow a user to set this value instead of 
using a hardcoded one?

E.g. via:
HKEY_CURRENT_USER\SOFTWARE\WireGuard\TunnelsInRootMenu
Default is 10 and if that registry value doesn't exist, 10 is also the 
default

It should accept values from 0 (display all tunnels) to +x (display at 
maximum x tunnels)

Vertical screen space shouldn't be an issue nowadays and imho the value 
of 10 is a bit too limiting.

Thank you!



From Jason at zx2c4.com  Tue Sep 28 03:22:44 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Mon, 27 Sep 2021 21:22:44 -0600
Subject: [Patch net] wireguard: preserve skb->mark on ingress side
In-Reply-To: <20210928031938.17902-1-xiyou.wangcong@gmail.com>
References: <20210928031938.17902-1-xiyou.wangcong@gmail.com>
Message-ID: <CAHmME9rbfBHUnoifdQV6pOp8MHwowEp7ooOhV-JSJmanRzksLA@mail.gmail.com>

Hi Cong,

I'm not so sure this makes sense, as the inner packet is in fact
totally different. If you want to distinguish the ingress interface,
can't you just use `iptables -i wg0` or `ip rule add ... iif wg0`?

Jason

From xiyou.wangcong at gmail.com  Tue Sep 28 03:27:55 2021
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Mon, 27 Sep 2021 20:27:55 -0700
Subject: [Patch net] wireguard: preserve skb->mark on ingress side
In-Reply-To: <CAHmME9rbfBHUnoifdQV6pOp8MHwowEp7ooOhV-JSJmanRzksLA@mail.gmail.com>
References: <20210928031938.17902-1-xiyou.wangcong@gmail.com>
 <CAHmME9rbfBHUnoifdQV6pOp8MHwowEp7ooOhV-JSJmanRzksLA@mail.gmail.com>
Message-ID: <CAM_iQpV-JKrk8vaHDeD0pXaheN0APUxH5Lp+mGCM=_yZQ1hd4w@mail.gmail.com>

On Mon, Sep 27, 2021 at 8:22 PM Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> Hi Cong,
>
> I'm not so sure this makes sense, as the inner packet is in fact
> totally different. If you want to distinguish the ingress interface,

The contents are definitely different, but skb itself is the same.

Please also take a look at other tunnels, they all preserve this
in similar ways, that is, comparing net namespaces. Any reason
why wireguard is so different from other tunnels?

> can't you just use `iptables -i wg0` or `ip rule add ... iif wg0`?
>

My bad, I forgot to mention we run eBPF on egress side, where
skb->dev is already set to egress device (a non-wireguard device),
and of course skb_iif has been cleared even earlier.

Thanks.

From and at mullvad.net  Tue Sep 28 11:03:59 2021
From: and at mullvad.net (Andrej Mihajlov)
Date: Tue, 28 Sep 2021 13:03:59 +0200
Subject: [wireguard-apple] [iOS] Changing network fails with
 includeAllNetworks (Kill Switch)
In-Reply-To: <E65FFE7D-9BCC-4EEF-9CF0-FA46CE6B9096@gmail.com>
References: <B3A4A27C-1FBF-4098-B38F-9F87F8C115B5@gmail.com>
 <5569D8DF-A7E8-4A13-BA6B-913785819E4E@mullvad.net>
 <CB84BD03-DB8A-4855-94CC-898100C0B97E@gmail.com>
 <9D47F45A-59C7-4FB0-A9F8-2F13A1D4AB1A@mullvad.net>
 <E65FFE7D-9BCC-4EEF-9CF0-FA46CE6B9096@gmail.com>
Message-ID: <85F39D56-E800-4EAE-B159-85335D150A4A@mullvad.net>

Hi,

I can confirm that it behaves correctly on iOS 15 (tested on iPhone 12) and iOS 15.1 beta (tested on iPhone 7). Tested by toggling cellular/wi-fi and airplane mode on both devices and network monitor seems to be functioning properly. 

I haven?t tested this patch on iOS 14.8, but I had previously tested it on iOS 14.5 (IIRC) and it didn?t work there, that's why this patch is scoped to iOS 15+.

I am running the "am/enable-include-all-networks" branch which has the following changeset:
https://git.zx2c4.com/wireguard-apple/commit/?id=07bc66e7b181fb2068d457b31c1fdd05bdd2214a&id2=58e94f077329f6c7b96ec069243495d4e649fe36

Cheers,
Andrej

> On 22 Sep 2021, at 15:26, Juraj Hilje <juraj.hilje at gmail.com> wrote:
> 
> Hi Andrej,
> 
> I've tested on iOS/iPadOS 15.1 Beta, and it looks like the issue is fixed there.
> Let me know if you can confirm the same on your end.
> 
> Cheers,
> Juraj H.
> 
>> On 22.09.2021., at 10:59, Andrej Mihajlov <and at mullvad.net> wrote:
>> 
>> Hi Juraj,
>> 
>> Installing iOS 15 right now. I am gonna test it today too. 
>> 
>> What stands out to me that, while you have multiple interfaces available, the network monitor still says that the network is unsatisfied. Very odd.
>> 
>> Cheers,
>> Andrej
>> 
>>> On 22 Sep 2021, at 10:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>>> 
>>> Hey Andrej, thanks for the response!
>>> 
>>> I've tested on iOS 14.8 and iOS 15.0 (public release), and even with the patch (b244febfdf3069dd4e8db2d31f0368d5474d7616) i still have the same issue on my end.
>>> 
>>> I will test the new iOS 15.1 Beta later today and let you know how it goes.
>>> 
>>> Juraj H.
>>> 
>>>> On 22.09.2021., at 10:08, Andrej Mihajlov <and at mullvad.net> wrote:
>>>> 
>>>> Have you tried on the most recent beta? I think it works over there, but requires some tweaks to the network monitor code in WireGuard. I had a patch somewhere here but haven?t spent much time testing it:
>>>> 
>>>> https://git.zx2c4.com/wireguard-apple/commit/?h=am/enable-include-all-networks&id=b244febfdf3069dd4e8db2d31f0368d5474d7616
>>>> 
>>>> Waiting for the final release of iOS 15.
>>>> 
>>>>> On 21 Sep 2021, at 12:55, Juraj Hilje <juraj.hilje at gmail.com> wrote:
>>>>> 
>>>>> If NETunnelProviderProtocol is configured with includeAllNetworks=true (Kill Switch), when network change is detected the device connectivity goes offline instead of routing VPN tunnel traffic through a new network.
>>>>> 
>>>>> Here are some logs from the moment of this event:
>>>>> 2021-09-20 12:07:26.735453: [NET] Network change detected with unsatisfied route and interface order [en0, utun4, pdp_ip0]
>>>>> 2021-09-20 12:07:26.736186: [NET] Connectivity offline, pausing backend.
>>>>> 2021-09-20 12:07:26.736732: [NET] Device closing
>>>>> 2021-09-20 12:07:26.737503: [NET] Routine: TUN reader - stopped
>>>>> 2021-09-20 12:07:26.738970: [NET] Routine: event worker - stopped
>>>>> 2021-09-20 12:07:26.739613: [NET] Routine: receive incoming v4 - stopped
>>>>> 2021-09-20 12:07:26.742070: [NET] Routine: receive incoming v6 - stopped
>>>>> 2021-09-20 12:07:26.746712: [NET] peer(eN1f?Oymc) - Stopping
>>>>> 2021-09-20 12:07:26.751550: [NET] peer(eN1f?Oymc) - Routine: sequential receiver - stopped
>>>>> 2021-09-20 12:07:26.751597: [NET] peer(eN1f?Oymc) - Routine: sequential sender - stopped
>>>>> 2021-09-20 12:07:26.753433: [NET] Device closed
>>>>> 2021-09-20 12:07:26.754097: [NET] Routine: decryption worker 5 - stopped
>>>>> 
>>>>> Tested on devices: iOS 14.8, iPadOS 15
>>>>> WireGuardKit: 79aeb0be0d0aa3f6c8bd24309aaa8dcf03216fb4
>>>>> 
>>>>> More info on includeAllNetworks option:
>>>>> https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks
>>>>> 
>>>>> Can someone confirm this issue or point to a possible workaround?
>>>>> Thanks!
>>>>> 
>>>>> Juraj H.
>>>> 
>>> 
>> 
> 


From tlhackque at yahoo.com  Tue Sep 28 19:53:39 2021
From: tlhackque at yahoo.com (tlhackque)
Date: Tue, 28 Sep 2021 15:53:39 -0400
Subject: Configuring an endpoint with multiple listening ports
References: <4a40d2e4-2ed8-7e79-cd8f-7ef71e731e38.ref@yahoo.com>
Message-ID: <4a40d2e4-2ed8-7e79-cd8f-7ef71e731e38@yahoo.com>

Recent discussions have suggested opening multiple UDP ports at the
"server" Endpoint of a tunnel to help overcome blocked ports, as
suggested in
https://lists.zx2c4.com/pipermail/wireguard/2018-November/003503.html.

As noted, it's fairly easy to redirect multiple ports on the server end
to a single ListenPort with NAT - whether with iptables or with
proprietary routers.

For the client (windows, android) as far as I can tell, the
configuration file syntax only allows a single Endpoint, with a single port.

This would indicate that either one should setup multiple peers (with
the same public key, AllowedIPs, etc) - one for each possible port - but
with different endpoint ports), or multiple tunnels (again duplicating
everything except the endpoint port).

If this is correct, it's awkward and error-prone.? It would be nice to
be able to specify something like [db8:123::10]:(51820,80,443,...) and
have the client try each port until it gets a response when it
(re-)initiates contact. It doesn't matter which port responds, since the
server's kernel sees the same listen port in every case.? (I guess the
client could even be aggressive and send the first packet to all ports -
since a quick reading of the protocol paper says that duplicates will be
discarded based on the timestamp.)

In any case, how do you recommend handling this configuration on the
client end?





From gustavoars at kernel.org  Tue Sep 28 22:17:05 2021
From: gustavoars at kernel.org (Gustavo A. R. Silva)
Date: Tue, 28 Sep 2021 17:17:05 -0500
Subject: [PATCH][net-next] net: wireguard: Use kvcalloc() instead of kvzalloc()
Message-ID: <20210928221705.GA279593@embeddedor>

Use 2-factor argument form kvcalloc() instead of kvzalloc().

Link: https://github.com/KSPP/linux/issues/162
Signed-off-by: Gustavo A. R. Silva <gustavoars at kernel.org>
---
 drivers/net/wireguard/ratelimiter.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireguard/ratelimiter.c b/drivers/net/wireguard/ratelimiter.c
index 3fedd1d21f5e..dd55e5c26f46 100644
--- a/drivers/net/wireguard/ratelimiter.c
+++ b/drivers/net/wireguard/ratelimiter.c
@@ -176,12 +176,12 @@ int wg_ratelimiter_init(void)
 			(1U << 14) / sizeof(struct hlist_head)));
 	max_entries = table_size * 8;
 
-	table_v4 = kvzalloc(table_size * sizeof(*table_v4), GFP_KERNEL);
+	table_v4 = kvcalloc(table_size, sizeof(*table_v4), GFP_KERNEL);
 	if (unlikely(!table_v4))
 		goto err_kmemcache;
 
 #if IS_ENABLED(CONFIG_IPV6)
-	table_v6 = kvzalloc(table_size * sizeof(*table_v6), GFP_KERNEL);
+	table_v6 = kvcalloc(table_size, sizeof(*table_v6), GFP_KERNEL);
 	if (unlikely(!table_v6)) {
 		kvfree(table_v4);
 		goto err_kmemcache;
-- 
2.27.0


From Jason at zx2c4.com  Tue Sep 28 22:35:07 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Sep 2021 16:35:07 -0600
Subject: [PATCH][net-next] net: wireguard: Use kvcalloc() instead of
 kvzalloc()
In-Reply-To: <20210928221705.GA279593@embeddedor>
References: <20210928221705.GA279593@embeddedor>
Message-ID: <CAHmME9o7dapX5-aQ76HtXWPmUHJ0GutxSfzWJ9TbpCrkvunt_g@mail.gmail.com>

Hi Gustavo,

table_size never exceeds 8192, so there's really not an issue with
integer overflow here. However, I checked the codegen of before/after
this patch, and it looks like gcc realizes this too, and so elides
them to be basically the same. So I'll apply this to the
wireguard-linux tree. Thanks for the patch.

Jason

From Jason at zx2c4.com  Tue Sep 28 23:16:13 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Tue, 28 Sep 2021 17:16:13 -0600
Subject: Feature request - Number of tunnel entries in root of tray icon
 context menu
In-Reply-To: <163277858699.7.10950010429724590941.14337061@stdmail.de>
References: <163277858699.7.10950010429724590941.14337061@stdmail.de>
Message-ID: <CAHmME9pnqk2Z_G3+SYzR4sYRuQQdOzJfncVYYXF7_Nigxc1fDw@mail.gmail.com>

Hi,

I don't want to add a knob for this, but I would take a patch that
uses a smarter heuristic than just "10". Feel free to send patches to
the list. The code in question is here:

https://git.zx2c4.com/wireguard-windows/tree/ui/tray.go#n225

For example, if you can calculate the number of entries that can fit
on the vertical height of the screen, maybe take a third? Or two
fifths?

Jason

From lists at wildgooses.com  Tue Sep 28 14:43:02 2021
From: lists at wildgooses.com (Ed W)
Date: Tue, 28 Sep 2021 15:43:02 +0100
Subject: Ultra low bandwidth wireguard question
Message-ID: <25dd7f3d-c4c3-32d5-da3e-fb95d85ee3df@wildgooses.com>

Hi, I have a satellite ISP where bandwidth costs around the $10-100/MB range (that's MB, not GB).
There are also additional costs for each "connection", meaning its more efficient to transmit in
bursts, than a gentle trickle of packets intermittently

An additional limitation of the network is that it takes 5-15 seconds to start passing packets once
it's been idle for a while ("a while" is about 25 seconds), and during that time wireguard will
retransmit packets on a 5 sec fixed interval, however, the network queues all these packets and so
after say 15 seconds I might have 4+ rekey packets queued, which result in 4+ responses from the far
end. Such data is quite expensive for this network

The device side is behind a network NAT and my goal is to keep a reverse connection in place, ie the
far end of the network can send packets back to the device. So I enable Keepalive in the wireguard
config

A conceptual description would be: hub and spoke arrangement of IOT devices on the far end of a
satellite internet link, where we want the hub to be able to keep an open pipe and push commands to
the IOT devices. The NAT UDP timeout on the satellite link firewalls is measured at approx 3 minutes.


So I face 3 challenges:

- keepalive packets are desired to be retransmitted every 3 minutes, but the encryption rekey timers
are set closer to 2 minutes. For example setting the keepalive timer to 2 minutes leads to sending
148 byte rekey packets for each rekey. However, setting the keepalive timer just short of 2 minutes
leads to a situation of 1 keepalive around the 2 min mark, followed by a rekey packet at the second
2 min mark, etc)

- wireguard has a 2 minute ish rekey timeout which causes sending a 148 byte request and triggering
a 92 byte response. However, as the retry interval is every 5 seconds, which usually leads to
sending 3-10x 148 byte requests (which are queued and retransmitted one the interface is up) and
leads to an equal number of 92 byte responses


So questions:

- Is it feasible within the design of wireguard to be able to "debounce" a stream of rekey packets
that will arrive reasonably consecutively (at about 22kbit/s), particularly it's the replies that I
want to queue and only send the latest? I couldn't see that this was feasible from the code as it
stands today? Suggestions appreciated though?


- Is it possible to adjust these constants

???? REKEY_AFTER_TIME = 120,
???? REJECT_AFTER_TIME = 180,

My concern looking at the code is that if I have some unmodified clients using the default settings,
then it's not clear to me how they would respond if one side has passed the REJECT_AFTER_TIME
interval and the other has not? (The intended scenario might be a hub spoke of IOT clients on the
satellite network, being accessed by other clients via general internet. The IOT clients and hub
server would be modified, but the other clients would be at defaults)

Can anyone comment on the implications of say altering only the client IOT devices to have a say
REKEY/REJECT times closer to 30 minutes? (ie server remaining on defaults)


- I implemented a very basic backoff on the resend of rekeys which better suits the characteristics
of this network, eg first retry is not until after 15 seconds, then it retries at 10, 15, 20, 25 sec
interval after that. Usually this leads to very few retries for my network. Code is below, any
comments?


Results:

With these changes and assuming a somewhat unreliable satellite network which might not have
coverage for some of the time (leading to additional retransmits), I see theoretical monthly idle
usage close to 3MB/month. However, being able to increase the REKEY/REJECT times to 30 mins might
drop this by a factor 10x or more. Can it be done?

Thanks

Ed W


Patch:

--- a/src/messages.h??? 2021-09-06 16:24:47.121985094 +0000
+++ b/src/messages.h??? 2021-09-06 13:54:59.879700016 +0000
@@ -40,14 +40,15 @@
?enum limits {
???? REKEY_AFTER_MESSAGES = 1ULL << 60,
???? REJECT_AFTER_MESSAGES = U64_MAX - COUNTER_WINDOW_SIZE - 1,
-??? REKEY_TIMEOUT = 5,
+??? REKEY_TIMEOUT = 10,
+??? REKEY_BACKOFF = 5,
???? REKEY_TIMEOUT_JITTER_MAX_JIFFIES = HZ / 3,
???? REKEY_AFTER_TIME = 120,
???? REJECT_AFTER_TIME = 180,
???? INITIATIONS_PER_SECOND = 50,
???? MAX_PEERS_PER_DEVICE = 1U << 20,
???? KEEPALIVE_TIMEOUT = 10,
-??? MAX_TIMER_HANDSHAKES = 90 / REKEY_TIMEOUT,
+??? MAX_TIMER_HANDSHAKES = 5, /* 100 secs */
???? MAX_QUEUED_INCOMING_HANDSHAKES = 4096, /* TODO: replace this with DQL */
???? MAX_STAGED_PACKETS = 128,
???? MAX_QUEUED_PACKETS = 1024 /* TODO: replace this with DQL */
--- a/src/timers.c??? 2021-09-06 16:24:47.122985106 +0000
+++ b/src/timers.c??? 2021-09-06 16:27:41.050156437 +0000
@@ -64,7 +64,7 @@
???? ??? ++peer->timer_handshake_attempts;
???? ??? pr_debug("%s: Handshake for peer %llu (%pISpfsc) did not complete after %d seconds,
retrying (try %d)\n",
???? ??? ??? ?peer->device->dev->name, peer->internal_id,
-??? ??? ??? ?&peer->endpoint.addr, REKEY_TIMEOUT,
+??? ??? ??? ?&peer->endpoint.addr, (REKEY_TIMEOUT + (peer->timer_handshake_attempts * REKEY_BACKOFF)),
???? ??? ??? ?peer->timer_handshake_attempts + 1);

???? ??? /* We clear the endpoint address src address, in case this is
@@ -182,7 +182,7 @@
?void wg_timers_handshake_initiated(struct wg_peer *peer)
?{
???? mod_peer_timer(peer, &peer->timer_retransmit_handshake,
-??? ??? ?????? jiffies + REKEY_TIMEOUT * HZ +
+??? ??? ?????? jiffies + (REKEY_TIMEOUT + (peer->timer_handshake_attempts * REKEY_BACKOFF) + 5) * HZ +
???? ??? ?????? prandom_u32_max(REKEY_TIMEOUT_JITTER_MAX_JIFFIES));
?}





From florent at coppint.com  Thu Sep 30 10:40:46 2021
From: florent at coppint.com (Florent B.)
Date: Thu, 30 Sep 2021 12:40:46 +0200
Subject: Enable Wireguard only for specific user
Message-ID: <0fd0ed22-732c-0ea5-5067-538dc0842869@coppint.com>

Hi list,

On a Linux system (Ubuntu), I would like to enable Wireguard VPN only 
for a single user on my system.

Currently by default, every packet of every user is getting though 
Wireguard.

How can I do to route packets only for 1 user ?

I think I have to play with packets marking (wg show wg0 fwmark / 
iptables owner/mark module), I tried some commands but was unable to 
success.

Can someone help please ?

Thank you.

Florent


From me at lochnair.net  Thu Sep 30 10:53:29 2021
From: me at lochnair.net (Nils Andreas Svee)
Date: Thu, 30 Sep 2021 12:53:29 +0200
Subject: Enable Wireguard only for specific user
In-Reply-To: <0fd0ed22-732c-0ea5-5067-538dc0842869@coppint.com>
References: <0fd0ed22-732c-0ea5-5067-538dc0842869@coppint.com>
Message-ID: <ac93f873-83fd-43b1-a247-f7df94cf0c36@www.fastmail.com>

Hi,

What I've had success with is using policy-based routing, selecting the routing table to use based on UID's.
You create a new routing table for the WireGuard VPN and add a rule directing that users traffic to that table.

Using commands you can do this to route traffic from the user with UID 1000 to table 500.
> ip rule add pref 20 uidrange 1000-1000 lookup 500

You can also do this in systemd-networkd if you're using that. Not sure about other network managers.

Best Regards
Nils

On Thu, Sep 30, 2021, at 12:40, Florent B. wrote:
> Hi list,
>
> On a Linux system (Ubuntu), I would like to enable Wireguard VPN only 
> for a single user on my system.
>
> Currently by default, every packet of every user is getting though 
> Wireguard.
>
> How can I do to route packets only for 1 user ?
>
> I think I have to play with packets marking (wg show wg0 fwmark / 
> iptables owner/mark module), I tried some commands but was unable to 
> success.
>
> Can someone help please ?
>
> Thank you.
>
> Florent

From florent at coppint.com  Thu Sep 30 11:01:38 2021
From: florent at coppint.com (Florent B.)
Date: Thu, 30 Sep 2021 13:01:38 +0200
Subject: Enable Wireguard only for specific user
In-Reply-To: <ac93f873-83fd-43b1-a247-f7df94cf0c36@www.fastmail.com>
References: <0fd0ed22-732c-0ea5-5067-538dc0842869@coppint.com>
 <ac93f873-83fd-43b1-a247-f7df94cf0c36@www.fastmail.com>
Message-ID: <906dc97b-d6e9-63a1-3a6a-65bd36d5671b@coppint.com>

Hi,

Thank you it works very well matching my excluded user and using "lookup 
main" ;)

 > ip rule add pref 20 uidrange 1001-1001 lookup main

I though it was more difficult and didn't know that "uid matching" in 
"ip rule".

Thanks

Le 30/09/2021 ? 12:53, Nils Andreas Svee a ?crit?:
> Hi,
>
> What I've had success with is using policy-based routing, selecting the routing table to use based on UID's.
> You create a new routing table for the WireGuard VPN and add a rule directing that users traffic to that table.
>
> Using commands you can do this to route traffic from the user with UID 1000 to table 500.
>> ip rule add pref 20 uidrange 1000-1000 lookup 500
> You can also do this in systemd-networkd if you're using that. Not sure about other network managers.
>
> Best Regards
> Nils
>
> On Thu, Sep 30, 2021, at 12:40, Florent B. wrote:
>> Hi list,
>>
>> On a Linux system (Ubuntu), I would like to enable Wireguard VPN only
>> for a single user on my system.
>>
>> Currently by default, every packet of every user is getting though
>> Wireguard.
>>
>> How can I do to route packets only for 1 user ?
>>
>> I think I have to play with packets marking (wg show wg0 fwmark /
>> iptables owner/mark module), I tried some commands but was unable to
>> success.
>>
>> Can someone help please ?
>>
>> Thank you.
>>
>> Florent

From wireguard_mailing_list_user at stdmail.de  Thu Sep 30 11:09:10 2021
From: wireguard_mailing_list_user at stdmail.de (wireguard_mailing_list_user at stdmail.de)
Date: Thu, 30 Sep 2021 11:09:10 -0000
Subject: Feature request - Number of tunnel entries in root of tray icon
 context menu
In-Reply-To: <163287098886.7.7062947333110889290.14414570@simplelogin.co>
References: <163277858699.7.10950010429724590941.14337061@stdmail.de>
 <163287098886.7.7062947333110889290.14414570@simplelogin.co>
Message-ID: <163300015018.6.7640455085114865179.14515199@stdmail.de>

Hi,

Apart from the problem that I'm not that much into go(lang) that I could 
provide such a patch myself...

I just don't see the gain that this way would yield because that would 
just replace one knob with another:
A registry value for a fixed amount of maximum entries or a ratio value 
(e.g.: 0.33 or 0.4). The ratio would require a knob as well, otherwise 
the next person comes and asks how to change it because it doesn't fit 
his needs...

Regards,
Ulf



From Jason at zx2c4.com  Thu Sep 30 16:41:32 2021
From: Jason at zx2c4.com (Jason A. Donenfeld)
Date: Thu, 30 Sep 2021 10:41:32 -0600
Subject: Feature request - Number of tunnel entries in root of tray icon
 context menu
In-Reply-To: <163300015018.6.7640455085114865179.14515199@stdmail.de>
References: <163277858699.7.10950010429724590941.14337061@stdmail.de>
 <163287098886.7.7062947333110889290.14414570@simplelogin.co>
 <163300015018.6.7640455085114865179.14515199@stdmail.de>
Message-ID: <CAHmME9q2GX9Oq1V2Gu4x0uGpY3MKP6pejBOuniv=s8hEh4Eb3A@mail.gmail.com>

On Thu, Sep 30, 2021 at 5:15 AM <wireguard_mailing_list_user at stdmail.de> wrote:
> The ratio would require a knob as well

Why?

Anyway, we're not adding knobs for any of this, as already stated. If
you've got a better heuristic than "10", then by all means send a
patch and I'd be happy to apply it. If you don't like "10" and you
don't like percentage of the vertical resolution, then come up with a
different heuristic and make a strong argument for it.