From mjt at tls.msk.ru Sun Aug 1 08:37:47 2021 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sun, 1 Aug 2021 11:37:47 +0300 Subject: names in wireguard.conf & bringing interface up Message-ID: Hello. We're having fun issue with wireguard at boot. The thing is that there are a few "Endpoint" settings in wg.conf which are names, not IP addresses - names which are being resolved over DNS. The problem is that DNS startup is scheduled AFTER the interfaces are up, but in order to bring interfaces up, we're waiting for DNS. For the wg interface to be up there's no need to resolve names. Yet `wg setconf' insists on resovling everything. As the result, system waits (deadwaits) for quite some time and does not bring wg interfaces up, resulting in network being !up. Like this: ... ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 7.43 seconds... ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 8.92 seconds... ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 10.70 seconds... ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820'. Trying again in 12.84 seconds... ifup[952]: Temporary failure in name resolution: `wg.corpit.ru:51820' ifup[952]: Configuration parsing error ifup[530]: ifup: failed to bring up wgtls We used tinc before trying out wireguard. In tinc, we had an asyncronous DNS resolution which continued as long as the daemon is running (and since the daemon must run all the time the tunnel is up, it were always running - unlike wg). So the DNS resolution has always worked. Now I wonder how I can solve this. Maybe I can configure the basic interface parameters (local IP address/netmask, routes, etc), and try to actually set all the info about remotes in the background somehow? But this still looks quite fragile - we should not fail to bring whole thing up even if we can't connect to just one endpoint, - this way we also can't connect TO the server to fix things if the tunnel is the only way to log in. All local config does not require any DNS or other remote info, only the few "connect to this remote" require it. Please note that we can't connect TO this server from the outside even if I put process of configuring the peer into background, until everything is working. I also tried to split configuration into two parts, one which require some network access and one which doesn't, but this way commands like syncconf does not work anymore, obviously - we can't change configuration at runtime and reload it. Comments? Thanks, /mjt From Jason at zx2c4.com Mon Aug 2 14:02:04 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 2 Aug 2021 16:02:04 +0200 Subject: wireguard command line, dumplog and GUI pop-up in 0.3.16 In-Reply-To: References: Message-ID: wireguard.exe /dumplog > log.txt per the documentation: https://git.zx2c4.com/wireguard-windows/about/docs/enterprise.md#diagnostic-logs From Jason at zx2c4.com Mon Aug 2 17:27:37 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 2 Aug 2021 19:27:37 +0200 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel Message-ID: Hey everyone, After many months of work, Simon and I are pleased to announce the WireGuardNT project, a native port of WireGuard to the Windows kernel. This has been a monumental undertaking, and if you've noticed that I haven't read emails in about two months, now you know why. WireGuardNT, lower-cased as "wireguard-nt" like the other repos, began as a port of the Linux codebase, so that we could benefit from the analysis and scrutiny that that code has already received. After the initial porting efforts there succeeded, the NT codebase quickly diverged to fit well with native NTisms and NDIS (Windows networking stack) APIs. The end result is a deeply integrated and highly performant implementation of WireGuard for the NT kernel, that makes use of the full gamut of NT kernel and NDIS capabilities. You can read about the project and look at its source code here: https://git.zx2c4.com/wireguard-nt/about/ For the Windows platform, this project is a big deal to me, as it marks the graduation of WireGuard to being a serious operating system component, meant for more serious usage. It's also a rather significant open source release, as there generally isn't so much (though there is some) open source crypto-NIC driver code already out there that does this kind of thing while pulling together various kernel capabilities in the process. To frame what WireGuardNT is, a bit of background for how WireGuard on Windows _currently_ works, prior to this, might be in store. We currently have a cross-platform Go codebase, called wireguard-go, which uses a generic TUN driver we developed called Wintun (see wintun.net for info). The implementation lives in userspace, and shepherds packets to and from the Wintun interface. WireGuardNT will (eventually) replace that, placing all of the WireGuard protocol implementation directly into the networking stack for deeper integration, in the same way that it's done currently on Linux, OpenBSD, and FreeBSD. With the old wireguard-go/Wintun implementation, the fact of being in userspace means that for each RX UDP packet that arrives in the kernel from the NIC and gets put in a UDP socket buffer, there's a context switch to userspace to receive it, and then a trip through the Go scheduler to decrypt it, and then it's written to Wintun's ring buffer, where it is then processed upon the next context switch. For TX, things happen in reverse: userspace sends a packet, and there's a context switch to the kernel to hand it off to Wintun, which places it into a ring buffer, and then there's another context switch to userspace, and a trip through the Go scheduler to encrypt it, and then it's sent through a socket, which involves another context switch to send it. All of the ring buffers -- Wintun's rings and Winsock's RIO rings -- amortize context switches as much as possible and make this decently fast, but all and all it still constitutes overhead and latency. WireGuardNT gets rid of all of that. While performance is quite good right now (~7.5Gbps TX on my small test box), not a lot of effort has yet been spent on optimizing it, and there's still a lot more performance to eek out of it, I suspect, especially as we learn more about NT's scheduler and threading model particulars. Yet, by simply being in the kernel, we significantly reduce latency and do away with the context switch problems of wireguard-go/Wintun. Most Windows users, however, don't really care what happens beyond 1Gbps, and this is where things get interesting. Windows users with an Ethernet connection generally haven't had much trouble getting close to 1Gbps or so with the old slow wireguard-go/Wintun, but over WiFi, those same users would commonly see massive slowdowns. With the significantly decreased latency of WireGuardNT, it appears that these slowdowns are no more. Jonathan Tooker reported to me that, on his system with an Intel AC9560 WiFi card, he gets ~600Mbps without WireGuard, ~600Mbps with wireguard-go/Wintun over Ethernet, ~95Mbps with wireguard-go/Wintun over WiFi, and ~600Mbps with WireGuardNT over WiFi. In other words, the WiFi performance hit from wireguard-go/Wintun has evaporated when using WireGuardNT. Power consumption, and hence battery usage, should be lower too. And of course, on the multigig throughput side of things, Windows Server users will no doubt benefit. The project is still at its early stages, and for now (August 2021; if you're reading this in the future this might not apply) this should be considered "experimental". There's a decent amount of new code on which I'd like to spend a bit more time scrutinizing and analyzing. And hopefully by putting the code online in an "earlier" stage of development, others might be interested in studying the source and reporting bugs in it. 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. 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. [Do note: as projects and codebases, both Wintun and wireguard-go will continue to be maintained, as they have applications and uses outside of our WireGuard client, and Wintun has uses outside of WireGuard in general.] The leap between each phase is rather large, and I'll update this thread when each one happens. Moving from 1 to 2 will happen when things seem okay for general consumption and from 2 to 3 when we're reasonably sure there's the same level of stability. Since we don't include any telemetry in the client, a lot of this assessment will be a matter of you, mailing list readers, sending bug reports or not sending bug reports. And of course, having testers during the unstable phase 1 will be a great boon. Instructions on enabling these knobs can be found in the usual place: https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md [ If you're reading this email in the future and that page either does not exist or does not contain mention of "ExperimentalKernelDriver" or "UseUserspaceImplementation", then we have already moved to phase 3, as above, and none of this applies any more. ] So, please do give it a whirl, check out the documentation and code, and let me know what you think. I'm looking forward to hearing your thoughts and receiving bug reports, experience reports, and overall feedback. Enjoy! Jason From peter.whisker at gmail.com Tue Aug 3 08:57:14 2021 From: peter.whisker at gmail.com (Peter Whisker) Date: Tue, 3 Aug 2021 09:57:14 +0100 Subject: Problems with Windows client over PulseSecure VPN In-Reply-To: References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com> <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com> Message-ID: <4ff6b3ed-66c0-82d4-1641-44849ca390ef@gmail.com> Hi Jason and team Thank you all for this amazing effort! I upgraded to v0.4 this morning and thought I should give it a go. I set DWORD "ExperimentalKernelDriver = 1" in the registry. My simple "normal" tunnel which goes directly and not via PulseSecure works fine. :) I removed the "PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0" from my configs which go via the PulseSecure tunnel however traffic does not flow, the received byte counter remains at zero although the tunnel allegedly becomes "Activated" - see the log below. Regards Peter 2021-08-03 09:52:13.130462: [TUN] [mini-deb2] Starting WireGuard/0.4 (Windows 10.0.19042; amd64) 2021-08-03 09:52:13.130462: [TUN] [mini-deb2] Watching network interfaces 2021-08-03 09:52:13.134477: [TUN] [mini-deb2] Resolving DNS names 2021-08-03 09:52:13.144960: [TUN] [mini-deb2] Creating network adapter 2021-08-03 09:52:13.150857: [TUN] [mini-deb2] WireGuardCreateAdapter: Creating adapter 2021-08-03 09:52:13.357365: [TUN] [mini-deb2] SelectDriver: Using existing driver 0.1 2021-08-03 09:52:13.986764: [TUN] [mini-deb2] Using WireGuardNT/0.1 2021-08-03 09:52:13.990466: [TUN] [mini-deb2] Enabling firewall rules 2021-08-03 09:52:13.990984: [TUN] [mini-deb2] Interface created 2021-08-03 09:52:13.994159: [TUN] [mini-deb2] Dropping privileges 2021-08-03 09:52:13.995190: [TUN] [mini-deb2] Peer 1 created 2021-08-03 09:52:13.997778: [TUN] [mini-deb2] Monitoring MTU of default v4 routes 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Sending keepalive packet to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Interface up 2021-08-03 09:52:14.009369: [TUN] [mini-deb2] Setting device v4 addresses 2021-08-03 09:52:14.012575: [TUN] [mini-deb2] Monitoring MTU of default v6 routes 2021-08-03 09:52:14.012575: [TUN] [mini-deb2] Setting device v6 addresses 2021-08-03 09:52:14.017056: [TUN] [mini-deb2] Startup complete 2021-08-03 09:52:19.001078: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:24.162600: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 2) 2021-08-03 09:52:24.162600: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:29.276205: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 2) 2021-08-03 09:52:29.276205: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:34.380120: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 3) 2021-08-03 09:52:34.380120: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:39.412842: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 4) 2021-08-03 09:52:39.412842: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:44.441204: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 5) 2021-08-03 09:52:44.443407: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:49.471250: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 6) 2021-08-03 09:52:49.471250: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) On 29/07/2021 12:00, Jason A. Donenfeld wrote: > Hi Peter, Heiko, Christopher, and others, > > An update on: > >> I had a strange idea for how to fix this without requiring >> recompilation or removal of that code. >> >> 1) Enable DangerousScriptExecution: >> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution >> >> 2) Add a PostUp line to your [Interface] section: >> >> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > I just wanted to let you know that this problem has been entirely > fixed (I think?) in the "WireGuardNT" kernel driver project I've been > working on (and haven't yet announced aside from development > screenshots on Twitter), and therefore the above steps will no longer > be necessary. When that ships as part of the v0.4 series of the normal > wireguard-windows client, you won't need the "listen-port 0" hack > anymore, as the kernel driver uses a more clever trick than the one > used by wireguard-go. So please do watch this mailing list in the next > few weeks for an announcement of that project, as I'll be very > interested in some real world tests and confirmation of the fix. > > Thanks, > Jason From Jason at zx2c4.com Tue Aug 3 10:57:37 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Aug 2021 12:57:37 +0200 Subject: Problems with Windows client over PulseSecure VPN In-Reply-To: <4ff6b3ed-66c0-82d4-1641-44849ca390ef@gmail.com> References: <9f621ce6-ec3d-0641-c359-756d0ad36f65@gmail.com> <6a01b182-a98f-1736-676f-d0811f6de086@gmail.com> <4ff6b3ed-66c0-82d4-1641-44849ca390ef@gmail.com> Message-ID: Hi Peter, Thanks for the report. This is due to an embarrassing mistake on my part, fixed here: https://git.zx2c4.com/wireguard-nt/commit/?id=9da6a84089d01ddee0018198eea0ab271916d934 . But hey, that's what experimental registry flags are for, right? ;-) I'll email you offlist with a testing build and some instructions in case you're eager to see this work before the next release. Jason From christantoandre at gmail.com Tue Aug 3 10:20:35 2021 From: christantoandre at gmail.com (Andre Christanto) Date: Tue, 3 Aug 2021 17:20:35 +0700 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad Message-ID: Hi all, Thank you very much for developing WireGuard. I have been using it daily for all my VPN needs. This is my first time using mailing list, so please give me feedback if I'm using this wrong. Today after I received notification that an update was available, I immediately update my WireGuard installation and while waiting for the installation to complete, I enabled the ExperimentalKernelDriver flag. After the update was completed and WireGuard automatically reconnected my VPN connection, my Windows almost immediately got BSOD (~2-3s after VPN connected notification) and keep getting it after restarts (I set my account to auto-login). Thinking that maybe I shouldn't enable the flag immediately after an update, I disabled the flag through Safe Mode. But after a restart and enablement of the flag, I still got BSOD after WireGuard was connected. In the end, I decided to disable WireGuardNT for now and report this feedback. I am using WireGuard on my Windows 10 x64 21H1 installation. My VPN provider is Mullvad and I am connected through wireless (Wi-Fi 5) connection using Intel 9260 network card. I also attached WireGuard's log to this email. Please let me know if you need more information. Thank you very much for the support! Best regards, Andre Christanto -------------- next part -------------- A non-text attachment was scrubbed... Name: wireguard-log-2021-08-03T170801.zip Type: application/x-zip-compressed Size: 16017 bytes Desc: not available URL: From h.shirosaki at gmail.com Tue Aug 3 05:06:34 2021 From: h.shirosaki at gmail.com (Hiroshi Shirosaki) Date: Tue, 3 Aug 2021 14:06:34 +0900 Subject: Blue Screen errors with WireGuardNT using two peers Message-ID: Hi, I tried to use WireGuard 0.4.0 with ExperimentalKernelDriver on. When I use only one peer, it seems to work fine. When I used another peer to ssh at the same time, Windows 10 became blue screen and rebooted. Windows 10 Pro 21H1. Is using multiple peers at the same time not supported? Thanks, Hiroshi Shirosaki From Jason at zx2c4.com Tue Aug 3 15:00:07 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Aug 2021 17:00:07 +0200 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad In-Reply-To: References: Message-ID: <3f38eb92-9ed6-5903-d96c-3161de5330f7@zx2c4.com> Hi Andre, On 8/3/21 12:20 PM, Andre Christanto wrote: > Today after I received notification that an update was available, I > immediately update my WireGuard installation and while waiting for the > installation to complete, I enabled the ExperimentalKernelDriver flag. > After the update was completed and WireGuard automatically reconnected > my VPN connection, my Windows almost immediately got BSOD (~2-3s after > VPN connected notification) Thank you for the bug report. I fixed a similar sounding bug yesterday, but perhaps this is a new one. Do you think you could send me the files in the C:\windows\minidump directory? It's probably best to mail these to me personally rather than sending them to the mailing list. Thanks, Jason From Jason at zx2c4.com Tue Aug 3 15:01:05 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Aug 2021 17:01:05 +0200 Subject: Blue Screen errors with WireGuardNT using two peers In-Reply-To: References: Message-ID: <6d0a94a0-ae09-39a3-7b83-c40efe40246b@zx2c4.com> Hi Hiroshi, On 8/3/21 7:06 AM, Hiroshi Shirosaki wrote: > I tried to use WireGuard 0.4.0 with ExperimentalKernelDriver on. > When I use only one peer, it seems to work fine. > When I used another peer to ssh at the same time, Windows 10 became > blue screen and rebooted. > Windows 10 Pro 21H1. > Is using multiple peers at the same time not supported? Multiple peers _should_ be supported, but you've evidently hit some kind of bug. Do you think you could send me the files in the C:\windows\minidump\ directory? It's probably best to mail these to me personally rather than sending them to the mailing list. Thanks, Jason From Jason at zx2c4.com Tue Aug 3 17:25:24 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Aug 2021 19:25:24 +0200 Subject: Blue Screen errors with WireGuardNT using two peers In-Reply-To: <6d0a94a0-ae09-39a3-7b83-c40efe40246b@zx2c4.com> References: <6d0a94a0-ae09-39a3-7b83-c40efe40246b@zx2c4.com> Message-ID: <50d9869c-0b89-c62e-35ff-79186413727c@zx2c4.com> On 8/3/21 5:01 PM, Jason A. Donenfeld wrote: > On 8/3/21 7:06 AM, Hiroshi Shirosaki wrote: >> I tried to use WireGuard 0.4.0 with ExperimentalKernelDriver on. >> When I use only one peer, it seems to work fine. >> When I used another peer to ssh at the same time, Windows 10 became >> blue screen and rebooted. >> Windows 10 Pro 21H1. >> Is using multiple peers at the same time not supported? > > Multiple peers _should_ be supported, but you've evidently hit some kind > of bug. Do you think you could send me the files in the > C:\windows\minidump\ directory? It's probably best to mail these to me > personally rather than sending them to the mailing list. v0.4.1 is now released. Please see if that fixes the issue. Jason From Jason at zx2c4.com Tue Aug 3 17:25:46 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 3 Aug 2021 19:25:46 +0200 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad In-Reply-To: <3f38eb92-9ed6-5903-d96c-3161de5330f7@zx2c4.com> References: <3f38eb92-9ed6-5903-d96c-3161de5330f7@zx2c4.com> Message-ID: <0253f078-4d5a-25ce-36c9-02d917dd2e54@zx2c4.com> On 8/3/21 5:00 PM, Jason A. Donenfeld wrote: > On 8/3/21 12:20 PM, Andre Christanto wrote: >> Today after I received notification that an update was available, I >> immediately update my WireGuard installation and while waiting for the >> installation to complete, I enabled the ExperimentalKernelDriver flag. >> After the update was completed and WireGuard automatically reconnected >> my VPN connection, my Windows almost immediately got BSOD (~2-3s after >> VPN connected notification) > > Thank you for the bug report. I fixed a similar sounding bug yesterday, > but perhaps this is a new one. Do you think you could send me the files > in the C:\windows\minidump directory? It's probably best to mail these > to me personally rather than sending them to the mailing list. v0.4.1 is now released. Please see if that fixes the issue. Jason From h.shirosaki at gmail.com Wed Aug 4 00:34:13 2021 From: h.shirosaki at gmail.com (Hiroshi Shirosaki) Date: Wed, 4 Aug 2021 09:34:13 +0900 Subject: Blue Screen errors with WireGuardNT using two peers In-Reply-To: <50d9869c-0b89-c62e-35ff-79186413727c@zx2c4.com> References: <6d0a94a0-ae09-39a3-7b83-c40efe40246b@zx2c4.com> <50d9869c-0b89-c62e-35ff-79186413727c@zx2c4.com> Message-ID: On Wed, Aug 4, 2021 at 2:25 AM Jason A. Donenfeld wrote: > > v0.4.1 is now released. Please see if that fixes the issue. Thank you for the fix. I tried and it works stably for now. FYI I confirmed windbg minidump result of the previous(v0.4.0) failure. It shows the following. 2: kd> !analyze -v DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high. This is usually caused by drivers using improper addresses. If kernel debugger is available get stack backtrace. Arguments: Arg1: 0000000000000024, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000000, value 0 = read operation, 1 = write operation Arg4: fffff801245e2d54, address which referenced memory Debugging Details: ------------------ (snip) Thanks, Hiroshi Shirosaki From Jason at zx2c4.com Wed Aug 4 00:36:01 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 4 Aug 2021 02:36:01 +0200 Subject: Blue Screen errors with WireGuardNT using two peers In-Reply-To: References: <6d0a94a0-ae09-39a3-7b83-c40efe40246b@zx2c4.com> <50d9869c-0b89-c62e-35ff-79186413727c@zx2c4.com> Message-ID: Hi Hiroshi, > I confirmed windbg minidump result of the previous(v0.4.0) failure. > It shows the following. > > 2: kd> !analyze -v > > DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1) > An attempt was made to access a pageable (or completely invalid) address at an > interrupt request level (IRQL) that is too high. This is usually > caused by drivers using improper addresses. > If kernel debugger is available get stack backtrace. > Arguments: > Arg1: 0000000000000024, memory referenced > Arg2: 0000000000000002, IRQL > Arg3: 0000000000000000, value 0 = read operation, 1 = write operation > Arg4: fffff801245e2d54, address which referenced memory > > Debugging Details: > ------------------ > (snip) Thank you for letting me know that 0.4.1 fixes the issue. With regards to your windbg - could you send the snipped part, just to be sure? Jason From onekopaka at theoks.net Wed Aug 4 01:51:19 2021 From: onekopaka at theoks.net (Darren VanBuren) Date: Tue, 3 Aug 2021 18:51:19 -0700 Subject: WireGuardNT with a peer with a v6 endpoint address Message-ID: Hello WireGuard list, I was very excited to see that WireGuardNT was available to test with the WireGuard Windows 0.4 release and I jumped right on it. I have upgraded to 0.4.1 since then. However, both from my desktop and laptop, where the laptop is on Windows 10 build 19043 and the desktop is on Windows 10 build 19042, I'm not seeing even a handshake go out on the wire / air when I use a v6 endpoint address for a peer, in my simple single peer configuration. When I switch down to a v4 endpoint address for the peer, it does work. wireguard-go worked fine with the v6 endpoint address, and continues to work fine. Has anyone else seen this? Thanks so much to the developers for the tremendous work on WireGuard in all its forms. Here's the log from my laptop trying to handshake for a bit, I have censored my VPS' IP and cut the log after the 20 attempts to handshake: 2021-08-03 18:23:58.478: [TUN] [MainVPS] Starting WireGuard/0.4.1 (Windows 10.0.19043; amd64) 2021-08-03 18:23:58.478: [TUN] [MainVPS] Watching network interfaces 2021-08-03 18:23:58.483: [TUN] [MainVPS] Resolving DNS names 2021-08-03 18:23:58.527: [TUN] [MainVPS] Creating network adapter 2021-08-03 18:23:58.532: [TUN] [MainVPS] WireGuardCreateAdapter: Creating adapter 2021-08-03 18:23:58.656: [TUN] [MainVPS] SelectDriver: Using existing driver 0.2 2021-08-03 18:23:59.170: [TUN] [MainVPS] Using WireGuardNT/0.2 2021-08-03 18:23:59.170: [TUN] [MainVPS] Enabling firewall rules 2021-08-03 18:23:59.170: [TUN] [MainVPS] Interface created 2021-08-03 18:23:59.178: [TUN] [MainVPS] Dropping privileges 2021-08-03 18:23:59.178: [TUN] [MainVPS] Peer 1 created 2021-08-03 18:23:59.190: [TUN] [MainVPS] Monitoring MTU of default v4 routes 2021-08-03 18:23:59.198: [TUN] [MainVPS] Setting device v4 addresses 2021-08-03 18:23:59.210: [TUN] [MainVPS] Monitoring MTU of default v6 routes 2021-08-03 18:23:59.210: [TUN] [MainVPS] Interface up 2021-08-03 18:23:59.210: [TUN] [MainVPS] Setting device v6 addresses 2021-08-03 18:23:59.270: [TUN] [MainVPS] Startup complete 2021-08-03 18:24:02.495: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:07.664: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 2) 2021-08-03 18:24:07.664: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:12.753: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 3) 2021-08-03 18:24:12.753: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:17.876: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 2) 2021-08-03 18:24:17.876: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:22.923: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 3) 2021-08-03 18:24:22.923: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:28.089: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 4) 2021-08-03 18:24:28.089: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:33.197: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 5) 2021-08-03 18:24:33.197: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:38.280: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 6) 2021-08-03 18:24:38.280: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:43.373: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 7) 2021-08-03 18:24:43.373: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:48.482: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 8) 2021-08-03 18:24:48.482: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:53.484: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 9) 2021-08-03 18:24:53.484: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:24:58.567: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 10) 2021-08-03 18:24:58.567: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:03.672: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 11) 2021-08-03 18:25:03.672: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:08.760: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 12) 2021-08-03 18:25:08.760: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:13.828: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 13) 2021-08-03 18:25:13.828: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:18.913: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 14) 2021-08-03 18:25:18.913: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:23.940: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 15) 2021-08-03 18:25:23.940: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:29.096: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 16) 2021-08-03 18:25:29.096: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:34.110: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 17) 2021-08-03 18:25:34.110: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:39.244: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 18) 2021-08-03 18:25:39.244: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:44.387: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 19) 2021-08-03 18:25:44.387: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:49.455: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 5 seconds, retrying (try 20) 2021-08-03 18:25:49.455: [TUN] [MainVPS] Sending handshake initiation to peer 1 ([2605:6400:20:xx:xxxx::1]:56780) 2021-08-03 18:25:54.502: [TUN] [MainVPS] Handshake for peer 1 ([2605:6400:20:xx:xxxx::1]:56780) did not complete after 20 attempts, giving up From peter.whisker at gmail.com Wed Aug 4 10:02:07 2021 From: peter.whisker at gmail.com (Peter Whisker) Date: Wed, 4 Aug 2021 11:02:07 +0100 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad In-Reply-To: References: Message-ID: <8282408d-8910-3e8d-2274-ac438380d90b@gmail.com> Hi Yes, I saw similar BSOD on a workstation I run yesterday but as it is remote it's a nuisance if I have to go and restart it in safe mode to disable the kernel flag. I may get to re-try it later in the week. However my work laptop has been rock solid with the WireguardNT driver and now works both directly and also through a PulseSecure tunnel, running a total of three tunnels and six peers simultaneously. :) Peter On 03/08/2021 11:20, Andre Christanto wrote: > Hi all, > > Thank you very much for developing WireGuard. I have been using it > daily for all my VPN needs. > This is my first time using mailing list, so please give me feedback > if I'm using this wrong. > > Today after I received notification that an update was available, I > immediately update my WireGuard installation and while waiting for the > installation to complete, I enabled the ExperimentalKernelDriver flag. > After the update was completed and WireGuard automatically reconnected > my VPN connection, my Windows almost immediately got BSOD (~2-3s after > VPN connected notification) and keep getting it after restarts (I set > my account to auto-login). Thinking that maybe I shouldn't enable the > flag immediately after an update, I disabled the flag through Safe > Mode. But after a restart and enablement of the flag, I still got BSOD > after WireGuard was connected. In the end, I decided to disable > WireGuardNT for now and report this feedback. > > I am using WireGuard on my Windows 10 x64 21H1 installation. My VPN > provider is Mullvad and I am connected through wireless (Wi-Fi 5) > connection using Intel 9260 network card. I also attached WireGuard's > log to this email. > Please let me know if you need more information. > > Thank you very much for the support! > > Best regards, > Andre Christanto From Jason at zx2c4.com Wed Aug 4 11:15:30 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 4 Aug 2021 13:15:30 +0200 Subject: WireGuardNT with a peer with a v6 endpoint address In-Reply-To: References: Message-ID: Hi Darren, Thanks very much for the report. Fixed here: https://git.zx2c4.com/wireguard-nt/commit/?id=a48d8a6751e35b6a3bc30062f6021673fccae1c4 . This will be part of the next build. Jason From Jason at zx2c4.com Wed Aug 4 11:17:31 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Wed, 4 Aug 2021 13:17:31 +0200 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad In-Reply-To: <8282408d-8910-3e8d-2274-ac438380d90b@gmail.com> References: <8282408d-8910-3e8d-2274-ac438380d90b@gmail.com> Message-ID: On Wed, Aug 4, 2021 at 12:05 PM Peter Whisker wrote: > Yes, I saw similar BSOD on a workstation I run yesterday but as it is > remote it's a nuisance if I have to go and restart it in safe mode to > disable the kernel flag. I may get to re-try it later in the week. Can you confirm that the BSOD was on 0.4 and not on 0.4.1? It's important for me to know whether this is a new bug or just a non-contributing "me too" for the old one. If this is a crash on 0.4.1, can you send me C:\windows\memory.dmp or C:\windows\minidump\*.dmp ? Thanks, Jason From peter.whisker at gmail.com Wed Aug 4 15:54:03 2021 From: peter.whisker at gmail.com (Peter Whisker) Date: Wed, 4 Aug 2021 16:54:03 +0100 Subject: WireGuardNT BSOD Windows 10 21H1 Mullvad In-Reply-To: References: <8282408d-8910-3e8d-2274-ac438380d90b@gmail.com> Message-ID: The original 0.4 On 04/08/2021 12:17, Jason A. Donenfeld wrote: > On Wed, Aug 4, 2021 at 12:05 PM Peter Whisker wrote: >> Yes, I saw similar BSOD on a workstation I run yesterday but as it is >> remote it's a nuisance if I have to go and restart it in safe mode to >> disable the kernel flag. I may get to re-try it later in the week. > Can you confirm that the BSOD was on 0.4 and not on 0.4.1? It's > important for me to know whether this is a new bug or just a > non-contributing "me too" for the old one. If this is a crash on > 0.4.1, can you send me C:\windows\memory.dmp or > C:\windows\minidump\*.dmp ? > > Thanks, > Jason From Jason at zx2c4.com Thu Aug 5 20:34:02 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Thu, 5 Aug 2021 22:34:02 +0200 Subject: Windows issue: impossible to add tunnels when install after setting program files to folder on other disk via reg value edit In-Reply-To: References: Message-ID: Thanks for the report. Fixed here: https://git.zx2c4.com/wireguard-windows/commit/?id=25bced8b3b1f9a13052516f15ed4e65014adac68 From s.devanath at gmail.com Fri Aug 6 00:36:17 2021 From: s.devanath at gmail.com (Devanath S) Date: Thu, 5 Aug 2021 17:36:17 -0700 Subject: wireguard tunnel UP/DOWN registration Message-ID: Hi All, Is there a way an application can register to wireguard to get tunnel handshake successful/failure events. Plz suggest. Regards, Dev From lsc at lv6.tw Sat Aug 7 14:53:52 2021 From: lsc at lv6.tw (SC Lee) Date: Sat, 7 Aug 2021 22:53:52 +0800 Subject: wireguard-windows incompatible with Win10 hotspot Message-ID: (This is my first time reporting wireguard issues, please kindly let me know if this is the wrong place.) I'm on Windows 10, and had no luck enabling WireGuard tunnels with the builtin WiFi hotspot feature at the same time. When I do so the tunnel stops working, and for some reason in Task Manager I'm seeing hundreds of Mbps of outbound traffic generated on the wireguard interface (but no actual traffic to the internet). The tunnel process also takes up a full CPU core seemingly due to the generated traffic. Upon switching off the hotspot the tunnel comes back to function. I wonder if this is a known issue? I believe it's a common use case to share a VPN tunnel with devices via hotspot. This seems unrelated to the "kill-switch" feature as it happens with or without it. FWIW I also tried both Wintun and WireGuardNT backends, and the same happened with both. My environment: Windows 10 version 20H2 build 19042.1110 wireguard-windows version 0.4.2 Thanks! From Jason at zx2c4.com Sat Aug 7 23:00:16 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 01:00:16 +0200 Subject: wireguard-windows incompatible with Win10 hotspot In-Reply-To: References: Message-ID: Hi lsc, Thanks for the report. That's a curious bug indeed, especially given that it affects both implementations. For the wireguard-go/wintun implementation, we're using setsockopt(IP_UNICAST_IF). For the wireguard-nt/kernel implementation, we're using IP_PKTINFO in a cmsghdr. Judging by the description of your report, it sounds like both of these cases are being ignored for some reason when hotspot mode is enabled. Having a functional IP_UNICAST_IF, and moreover a functional IP_PKTINFO, is extremely important for things to work properly, and without it you wind up with routing loops like the one you've described. It's actually not just wireguard that uses those too -- I was reading the msquic source last night and noticed that it does the same. So, hm. I'll have to try to make a test environment for that, though it might be slightly tricky given the hardware I have available. I'll see what I can do. Jason From Jason at zx2c4.com Sat Aug 7 23:19:44 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 01:19:44 +0200 Subject: wireguard-windows incompatible with Win10 hotspot In-Reply-To: References: Message-ID: On Sun, Aug 8, 2021 at 1:00 AM Jason A. Donenfeld wrote: > So, hm. I'll have to try to make a test environment for that, though > it might be slightly tricky given the hardware I have available. I'll > see what I can do. Turns out a USB wifi adapter and a boring VM made this very easy to reproduce. Indeed I can confirm the bug, though I don't yet understand it. I assume that the Windows 10 Hotspot feature is using some sort of redirection rules without taking into account IP_UNICAST_IF or IP_PKTINFO, so likely a Windows bug. Hm... From joshua.sjoding at scjalliance.com Sat Aug 7 23:38:51 2021 From: joshua.sjoding at scjalliance.com (Joshua Sjoding) Date: Sat, 7 Aug 2021 16:38:51 -0700 Subject: WireGuard for Windows 0.4.2 failed to start due to WintunSetAdapterName failure (Code 0x000006D9) Message-ID: Yesterday one of our older laptops hit an error during the startup of WireGuard for Windows 0.4.2 that I haven't seen before. It looks like it failed to set the name of the WinTun adapter because there were "no more endpoints available from the endpoint mapper". It left the tunnel in an inactive state, but it started up just fine when I told it to activate today. I've attached the log in case it's of interest. Here's the snippet where the failed startup took place: 2021-08-06 19:46:15.039160: [MGR] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 19:46:18.899902: [TUN] [SCJ] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 19:46:19.249315: [TUN] [SCJ] Watching network interfaces 2021-08-06 19:46:22.608757: [TUN] [SCJ] Resolving DNS names 2021-08-06 19:46:22.608757: [TUN] [SCJ] Creating network adapter 2021-08-06 19:46:32.157022: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Creating adapter 2021-08-06 19:46:41.129852: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.13 2021-08-06 19:46:41.237299: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Failed to register adapter 17 device: The device instance does not exist in the hardware tree. (Code 0xE000020B) 2021-08-06 19:46:42.457251: [TUN] [SCJ] Retrying adapter creation after failure because system just booted (T+1m39.109s): Error creating interface: winapi error #3758096907 2021-08-06 19:46:42.457251: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Creating adapter 2021-08-06 19:46:44.047474: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.13 2021-08-06 19:51:51.408322: [TUN] [SCJ] [Wintun] WintunSetAdapterName: Failed to set adapter name: There are no more endpoints available from the endpoint mapper. (Code 0x000006D9) 2021-08-06 19:51:51.408322: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Failed to set adapter name SCJ 2021-08-06 19:51:52.392522: [TUN] [SCJ] Unable to create network adapter: Error creating interface: There are no more endpoints available from the endpoint mapper. 2021-08-06 19:51:52.442380: [TUN] [SCJ] Shutting down 2021-08-06 19:51:52.540997: [MGR] [SCJ] Tunnel service tracker finished The Laptop is an old Lenovo E555 with an AMD A6-7000 in it. It's not fast. This could be some sort of race condition with slow-to-start Windows services. The log indicates that it was updated from WireGuard 0.3.11 to 0.4.2 earlier that day. That might be a coincidence, but it might not be. Joshua Sjoding SCJ Alliance IT Specialist www.scjalliance.com -------------- next part -------------- 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - stopped 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - stopped 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(1hMF?tqBw) - Stopping... 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - stopped 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - stopped 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(heWL?uHXY) - Stopping... 2021-08-06 16:17:56.308441: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Device closed 2021-08-06 16:17:56.309442: [TUN] [SCJ] Shutting down 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 16:17:56.309442: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 16:17:56.377535: [MGR] [SCJ] Tunnel service tracker finished 2021-08-06 16:19:29.360065: [MGR] Starting WireGuard/0.3.11 (Windows 10.0.19042; amd64) 2021-08-06 16:19:30.521419: [TUN] [SCJ] Starting WireGuard/0.3.11 (Windows 10.0.19042; amd64) 2021-08-06 16:19:30.605499: [TUN] [SCJ] SCM locked for 58s by .\NT Service Control Manager, marking service as started 2021-08-06 16:19:30.605499: [TUN] [SCJ] Watching network interfaces 2021-08-06 16:19:31.258786: [TUN] [SCJ] Resolving DNS names 2021-08-06 16:19:31.258786: [TUN] [SCJ] Creating Wintun interface 2021-08-06 16:19:33.495442: [TUN] [SCJ] [Wintun] CreateAdapter: Creating adapter 2021-08-06 16:19:34.479755: [MGR] An update is available 2021-08-06 16:19:38.144654: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.10 2021-08-06 16:19:45.935668: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 16:19:45.935668: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 16:19:45.935668: [TUN] [SCJ] Using Wintun/0.10 2021-08-06 16:19:45.935668: [TUN] [SCJ] Enabling firewall rules 2021-08-06 16:19:46.387591: [TUN] [SCJ] Dropping privileges 2021-08-06 16:19:46.387591: [TUN] [SCJ] Creating interface instance 2021-08-06 16:19:46.449546: [TUN] [SCJ] Setting interface configuration 2021-08-06 16:19:46.450120: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 16:19:46.450165: [TUN] [SCJ] UAPI: Updating private key 2021-08-06 16:19:46.450165: [TUN] [SCJ] UAPI: Removing all peers 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: event worker - started 2021-08-06 16:19:46.451026: [TUN] [SCJ] Routine: TUN reader - started 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Created 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating endpoint 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Removing all allowedips 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Adding allowedip 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Created 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating endpoint 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Removing all allowedips 2021-08-06 16:19:46.451592: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Adding allowedip 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Created 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating endpoint 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Removing all allowedips 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Adding allowedip 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Created 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating endpoint 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Removing all allowedips 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Adding allowedip 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Created 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating endpoint 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Removing all allowedips 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Adding allowedip 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Created 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating endpoint 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Removing all allowedips 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Adding allowedip 2021-08-06 16:19:46.452161: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Created 2021-08-06 16:19:46.453329: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating endpoint 2021-08-06 16:19:46.453329: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating persistent keepalive interval 2021-08-06 16:19:46.453329: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Removing all allowedips 2021-08-06 16:19:46.453329: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Adding allowedip 2021-08-06 16:19:46.453329: [TUN] [SCJ] Bringing peers up 2021-08-06 16:19:46.453896: [TUN] [SCJ] UDP bind has been updated 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(1hMF?tqBw) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(heWL?uHXY) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(YnSj?521U) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(8muY?GdG8) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(YEM2?4hlk) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(WBaN?k8hA) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(c9ys?npmo) - Starting... 2021-08-06 16:19:46.453896: [TUN] [SCJ] Interface state was Down, requested Up, now Up 2021-08-06 16:19:46.453896: [TUN] [SCJ] Monitoring default v6 routes 2021-08-06 16:19:46.453896: [TUN] [SCJ] Binding v6 socket to interface 11 (blackhole=false) 2021-08-06 16:19:46.453896: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - started 2021-08-06 16:19:46.463553: [TUN] [SCJ] Routine: receive incoming v4 - started 2021-08-06 16:19:46.463553: [TUN] [SCJ] Setting device v6 addresses 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] Routine: receive incoming v6 - started 2021-08-06 16:19:46.638360: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - started 2021-08-06 16:19:46.640574: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - started 2021-08-06 16:19:46.640574: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - started 2021-08-06 16:19:46.640574: [TUN] [SCJ] Monitoring default v4 routes 2021-08-06 16:19:46.640574: [TUN] [SCJ] Binding v4 socket to interface 11 (blackhole=false) 2021-08-06 16:19:46.640574: [TUN] [SCJ] Setting device v4 addresses 2021-08-06 16:19:46.703159: [TUN] [SCJ] Listening for UAPI requests 2021-08-06 16:19:46.703159: [TUN] [SCJ] Startup complete 2021-08-06 16:19:50.501014: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:19:51.016951: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:19:51.065251: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:19:51.096582: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:19:51.363618: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 16:19:51.462086: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 16:19:54.556144: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:19:54.650002: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:19:58.436603: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 16:19:58.552270: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 16:20:02.801938: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 16:20:05.740435: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:20:08.860981: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 16:20:08.989984: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:20:21.509187: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 16:20:32.256231: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:20:35.024373: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:21:05.501123: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:21:20.592850: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:21:29.022081: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 16:21:32.097772: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 16:21:37.570054: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake initiation 2021-08-06 16:21:37.570054: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake response 2021-08-06 16:21:37.877460: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 16:21:51.341629: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:21:51.683026: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:21:51.683026: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:21:54.728012: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:21:55.197334: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:21:55.197334: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:22:40.427730: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:22:40.548308: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:22:40.548308: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:22:53.035967: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:23:35.934433: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 16:23:40.153504: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:23:51.768848: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:23:51.873986: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:23:51.873986: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:23:52.768135: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:23:58.241738: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:23:58.322311: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:23:58.322311: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:24:09.273254: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:25:05.908124: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:25:05.939177: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:25:05.939177: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:25:07.933586: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 16:25:07.962373: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 16:25:09.463845: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:25:18.781031: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:25:19.011107: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:25:24.583522: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:25:42.010884: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:25:42.478687: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:25:51.908126: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:25:51.943089: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:25:51.943089: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:25:55.299756: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:25:58.337796: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:25:58.363082: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:25:58.363082: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:26:09.624468: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:26:11.193793: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:26:24.718731: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:26:45.817066: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:26:46.484861: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:27:01.122912: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:27:06.309128: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:27:06.339778: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:27:06.339778: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:27:12.076857: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:27:16.775651: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:27:16.996999: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 16:27:24.876741: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:27:41.625485: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:27:52.030455: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:27:52.174711: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:27:52.174711: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:27:59.637978: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:27:59.678005: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:27:59.678005: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:28:11.798448: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:28:25.037237: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:28:40.441614: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 16:28:40.566721: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 16:28:51.194438: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:28:56.556794: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:29:29.016433: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:29:29.047495: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:29:29.047495: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:29:38.040139: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 16:29:44.140498: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:29:46.196316: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:29:54.240822: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:29:54.274970: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:29:54.275575: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:29:59.904753: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:29:59.938894: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:29:59.938894: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:30:14.071133: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:30:25.099813: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:30:35.145452: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:30:37.578049: [TUN] [SCJ] peer(heWL?uHXY) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 16:30:44.125762: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:31:14.148400: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:31:18.670886: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:31:25.258727: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:31:35.560492: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:31:44.176173: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:31:44.204821: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:31:57.616091: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:31:57.656871: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:31:57.657443: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:32:00.111696: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:32:00.142072: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:32:00.142613: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:32:13.392605: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:32:13.451418: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:32:42.569817: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:32:53.583706: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:33:10.475333: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:33:25.586344: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:33:40.336335: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:33:47.878565: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:33:47.921667: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:33:48.283165: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 16:33:48.347552: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 16:33:59.401872: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 16:33:59.401872: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:33:59.434513: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:33:59.434513: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 16:33:59.436309: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:33:59.483257: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 16:33:59.483257: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:34:00.349495: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:34:00.385629: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:34:00.385629: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:34:10.636969: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:34:13.514995: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:34:26.129952: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:34:40.492673: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:34:53.640813: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:35:00.083001: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:35:11.092524: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:35:25.904048: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:35:40.592315: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:35:56.709826: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:36:00.632925: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:36:00.660386: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:36:00.660386: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:36:07.731559: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:36:10.958220: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:36:26.057852: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:36:40.750199: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:36:53.703047: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:37:11.113284: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:37:26.216977: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:37:40.576209: [TUN] [SCJ] peer(YEM2?4hlk) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 16:37:40.857069: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:37:57.772523: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:37:57.772523: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:38:00.855058: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:38:00.890380: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:38:00.890380: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:38:08.008028: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:38:11.282886: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:38:26.121306: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:38:47.443293: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:38:47.560389: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:39:17.365999: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:39:27.305210: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:39:47.396227: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:39:47.524315: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:40:01.782769: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:40:01.814754: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:40:01.814754: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:40:12.127174: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:40:27.222715: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:40:37.356955: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:40:37.356955: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:40:37.393433: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:40:47.454462: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:40:47.516757: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:41:12.039506: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:41:27.149607: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:41:42.014420: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:42:02.026196: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:42:02.059964: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:42:02.059964: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:42:12.222174: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:42:27.334404: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:42:37.483087: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:42:37.483087: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:42:37.524468: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:42:47.313127: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:42:47.626046: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:42:47.992164: [TUN] [SCJ] peer(8muY?GdG8) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 16:42:48.430288: [TUN] [SCJ] peer(heWL?uHXY) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 16:43:12.407179: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:43:27.518104: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:43:42.241873: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:44:02.257122: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:44:02.296487: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:44:02.296487: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:44:12.589961: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:44:27.698604: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:44:37.586693: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:44:37.586693: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:44:37.619812: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:44:47.419017: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:44:47.741794: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:45:12.625263: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:45:27.613637: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:45:42.433904: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:46:02.455100: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:46:02.488479: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:46:02.488479: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:46:12.670279: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:46:27.771812: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:46:37.637393: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:46:37.637393: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:46:37.680866: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:46:47.483846: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:46:47.804326: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:47:12.829068: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:47:27.931686: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:47:42.649554: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:48:02.687792: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:48:02.728548: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:48:02.728548: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:48:12.985820: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:48:28.093077: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:48:47.612934: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:48:47.613586: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:48:47.613586: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:48:47.646846: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:48:48.148470: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:49:17.505333: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:49:17.535257: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:49:28.103887: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:49:47.530353: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:49:47.592465: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:50:02.847666: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:50:02.876169: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:50:02.876169: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:50:13.049728: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:50:28.153168: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:50:47.614034: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:50:56.888194: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:50:56.888194: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:50:56.888801: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:50:56.925205: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:51:07.641910: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:51:13.212886: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:51:18.890341: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 16:51:18.915214: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 16:51:19.401719: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:51:19.430358: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:51:19.982715: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 16:51:20.023618: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 16:51:29.751200: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 16:51:30.443906: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 16:51:30.874221: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:51:31.361221: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:51:44.815029: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 16:51:45.209030: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:52:02.871672: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:52:03.021056: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:52:03.049887: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:52:03.049887: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:52:03.063969: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:52:04.213604: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:52:16.697522: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:52:28.221015: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:52:47.674345: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:52:57.446013: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:52:57.446013: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:52:57.477876: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:53:07.708228: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:53:13.273892: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:53:28.378244: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:53:43.223727: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:54:03.223820: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:54:03.253820: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:54:03.253820: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:54:13.437491: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:54:28.541681: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:54:47.739230: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:54:57.494561: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:54:57.494561: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:54:57.532377: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:55:07.773555: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:55:13.596071: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:55:28.701184: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:55:43.390396: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:56:03.393585: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:56:03.427844: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:56:03.428446: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:56:13.759489: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:56:28.608759: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:56:47.806054: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:56:57.545547: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:56:57.545547: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:56:57.579105: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:57:07.585673: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:57:13.662545: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:57:28.767899: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:57:43.564802: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:58:03.564284: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 16:58:03.593646: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 16:58:03.593646: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:58:13.823559: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:58:28.926801: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:58:47.933509: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:58:48.127972: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:58:59.890988: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 16:58:59.946771: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 16:59:07.864161: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 16:59:07.864161: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 16:59:07.897393: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 16:59:10.645943: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 16:59:17.859108: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 16:59:29.085810: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 16:59:36.397515: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 16:59:37.409171: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 16:59:37.988974: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status c000013a 2021-08-06 16:59:38.995848: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 16:59:41.487707: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 16:59:42.382354: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 16:59:42.430108: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 16:59:42.491987: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 16:59:42.491987: [MGR] Unable to start manager UI process for user 'username.redacted at SCJ' for session 1: Session has logged out 2021-08-06 16:59:48.010185: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 16:59:52.655115: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:00:02.944201: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:00:03.745725: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:00:03.782062: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:00:03.782062: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:00:16.129991: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:00:18.946703: [TUN] [SCJ] peer(YEM2?4hlk) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 17:00:20.457385: [TUN] [SCJ] Device closing 2021-08-06 17:00:20.517166: [TUN] [SCJ] Routine: TUN reader - stopped 2021-08-06 17:00:22.493452: [TUN] [SCJ] Routine: event worker - stopped 2021-08-06 17:00:22.534947: [TUN] [SCJ] Routine: receive incoming v4 - stopped 2021-08-06 17:00:22.534947: [TUN] [SCJ] Routine: receive incoming v6 - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YEM2?4hlk) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(WBaN?k8hA) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(c9ys?npmo) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(1hMF?tqBw) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(heWL?uHXY) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YnSj?521U) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(8muY?GdG8) - Stopping... 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Device closed 2021-08-06 17:00:22.535463: [TUN] [SCJ] Shutting down 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:00:22.535463: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:00:22.614742: [MGR] [SCJ] Tunnel service tracker finished 2021-08-06 17:01:53.401388: [MGR] Starting WireGuard/0.3.11 (Windows 10.0.19042; amd64) 2021-08-06 17:01:55.340640: [TUN] [SCJ] Starting WireGuard/0.3.11 (Windows 10.0.19042; amd64) 2021-08-06 17:01:55.401383: [TUN] [SCJ] SCM locked for 1m4s by .\NT Service Control Manager, marking service as started 2021-08-06 17:01:55.431556: [TUN] [SCJ] Watching network interfaces 2021-08-06 17:01:56.205706: [TUN] [SCJ] Resolving DNS names 2021-08-06 17:01:56.205706: [TUN] [SCJ] Creating Wintun interface 2021-08-06 17:02:10.006527: [MGR] An update is available 2021-08-06 17:02:17.894703: [TUN] [SCJ] [Wintun] CreateAdapter: Creating adapter 2021-08-06 17:02:18.119302: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 17:02:18.119302: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 17:02:26.980795: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.10 2021-08-06 17:02:35.374889: [TUN] [SCJ] Using Wintun/0.10 2021-08-06 17:02:35.374889: [TUN] [SCJ] Enabling firewall rules 2021-08-06 17:02:35.957609: [TUN] [SCJ] Dropping privileges 2021-08-06 17:02:36.044910: [TUN] [SCJ] Creating interface instance 2021-08-06 17:02:36.844889: [TUN] [SCJ] Setting interface configuration 2021-08-06 17:02:36.931971: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 17:02:36.931971: [TUN] [SCJ] UAPI: Updating private key 2021-08-06 17:02:36.931971: [TUN] [SCJ] UAPI: Removing all peers 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: event worker - started 2021-08-06 17:02:37.119456: [TUN] [SCJ] Routine: TUN reader - started 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating endpoint 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Removing all allowedips 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Adding allowedip 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Created 2021-08-06 17:02:37.586114: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating endpoint 2021-08-06 17:02:37.791100: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating persistent keepalive interval 2021-08-06 17:02:37.791100: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Removing all allowedips 2021-08-06 17:02:37.791100: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Adding allowedip 2021-08-06 17:02:37.792101: [TUN] [SCJ] Bringing peers up 2021-08-06 17:02:37.797098: [TUN] [SCJ] UDP bind has been updated 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(1hMF?tqBw) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(heWL?uHXY) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(YnSj?521U) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(8muY?GdG8) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(YEM2?4hlk) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(WBaN?k8hA) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] peer(c9ys?npmo) - Starting... 2021-08-06 17:02:37.797098: [TUN] [SCJ] Interface state was Down, requested Up, now Up 2021-08-06 17:02:37.797098: [TUN] [SCJ] Monitoring default v4 routes 2021-08-06 17:02:37.798098: [TUN] [SCJ] Binding v4 socket to interface 11 (blackhole=false) 2021-08-06 17:02:37.895041: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - started 2021-08-06 17:02:37.950802: [TUN] [SCJ] Routine: receive incoming v4 - started 2021-08-06 17:02:37.984376: [TUN] [SCJ] Routine: receive incoming v6 - started 2021-08-06 17:02:38.027674: [TUN] [SCJ] Setting device v4 addresses 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - started 2021-08-06 17:02:38.083677: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - started 2021-08-06 17:02:38.433564: [TUN] [SCJ] Monitoring default v6 routes 2021-08-06 17:02:38.433564: [TUN] [SCJ] Binding v6 socket to interface 11 (blackhole=false) 2021-08-06 17:02:38.433564: [TUN] [SCJ] Setting device v6 addresses 2021-08-06 17:02:39.019811: [TUN] [SCJ] Listening for UAPI requests 2021-08-06 17:02:39.019811: [TUN] [SCJ] Startup complete 2021-08-06 17:02:45.805945: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:02:46.030849: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:02:46.790245: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:02:46.882096: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:02:47.183366: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:02:47.215203: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:02:57.821367: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:03:05.039551: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:03:30.072835: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:03:42.849603: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:03:42.868368: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:03:50.768283: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:03:50.948382: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:03:57.718332: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:04:09.774180: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:04:09.845682: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:04:12.824405: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:04:20.506920: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:04:21.086151: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:04:21.439980: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:04:21.466923: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:04:27.579838: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:04:31.504023: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:04:46.893116: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:04:46.912032: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:04:46.912032: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:04:47.581675: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:04:47.601409: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:04:47.601409: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:04:57.880154: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:05:12.277560: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:05:12.979783: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:05:27.653964: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:05:58.039122: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:05:59.711840: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:05:59.769075: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:06:19.239251: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:06:19.272681: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:06:19.273306: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:06:21.946662: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:06:25.778704: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:06:25.802578: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:06:25.802578: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:06:29.855216: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:06:33.627167: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:06:35.976124: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:06:41.374125: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:06:47.749779: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:06:47.771097: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:06:47.771097: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:06:47.843034: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:06:47.874588: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:06:47.874588: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:07:31.291950: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:07:35.318527: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:07:42.289996: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:08:13.206448: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:08:23.969690: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:08:35.458553: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:08:46.484367: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:08:47.961264: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:08:47.979983: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:08:47.979983: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:08:52.416842: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:08:52.442330: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:08:52.442330: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:09:02.615694: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:09:13.367348: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:09:13.375599: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:09:40.714459: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:09:42.129640: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:09:42.165490: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:09:47.761739: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:09:59.867132: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:09:59.998612: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:10:08.383882: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:10:08.520617: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:10:16.402121: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:10:23.401754: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:10:23.723904: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:10:35.702960: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:10:41.834020: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:10:48.519930: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:10:48.561843: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:10:48.561843: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:10:52.458603: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:10:52.502100: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:10:52.502100: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:11:10.927554: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:11:35.453029: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:11:43.531591: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:11:43.733135: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:11:49.054575: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:11:49.165501: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:11:49.165501: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:12:01.027755: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:12:05.866382: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:12:25.416856: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:12:25.494498: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:12:25.494498: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:12:35.741966: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:12:35.743029: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:12:51.250778: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:12:51.431690: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:12:51.431690: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:12:52.836691: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:12:53.010800: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:12:53.010800: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:13:05.868186: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:13:05.946089: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:13:30.346647: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:13:32.951236: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:13:46.677623: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:13:47.169647: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:13:47.320295: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:13:51.100864: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:13:51.143689: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:13:51.144198: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:13:51.574901: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:13:51.597741: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:14:01.811376: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:14:02.418076: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:14:02.543750: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:14:18.886010: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:14:19.231357: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:14:35.418201: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:14:40.793134: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:14:46.245985: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:14:48.729502: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:14:52.192890: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:14:52.225917: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:14:52.225917: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:14:56.967564: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:14:57.461727: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:14:57.520002: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:14:57.520002: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:15:02.748687: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:15:09.979001: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:15:17.653951: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:15:18.049176: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:15:18.814448: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:15:24.827394: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:15:30.368239: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:15:32.254308: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:15:41.936162: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:15:41.973443: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:15:48.921051: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:15:51.841973: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:15:51.963096: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:15:52.051564: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:15:52.088974: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:15:52.088974: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:15:53.054358: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:16:02.376264: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:16:07.944963: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:16:09.428291: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:16:09.556788: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:16:09.556788: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:16:28.750215: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:16:28.905864: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:16:28.956198: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:16:32.523750: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:16:37.720096: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:16:37.837878: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:16:48.673778: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:16:53.213722: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:16:53.482670: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:16:53.482670: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:16:54.333245: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:17:04.447584: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:17:05.474673: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:17:05.886348: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:17:08.099714: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:17:18.674108: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:17:20.106545: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:17:32.452506: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:17:32.668141: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:17:34.238859: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:17:51.500075: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:17:52.311230: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:17:52.347728: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:17:52.347728: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:18:04.565856: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:18:19.671100: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:18:32.381744: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:18:34.189240: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:18:35.716456: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:18:35.748882: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:18:35.748882: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 17:18:35.834858: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:18:35.871397: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:18:45.961348: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:18:46.181353: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:18:54.263053: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:18:54.304216: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:18:54.304216: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:18:56.672448: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:19:04.471282: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:19:19.572313: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:19:32.723668: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:19:34.331862: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:20:04.700347: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:20:19.734647: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:20:34.401346: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:20:54.497955: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:20:54.536658: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:20:54.536658: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:20:56.454254: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:20:56.485579: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:21:06.613075: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:21:06.675390: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:21:19.918766: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:21:36.555356: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:21:36.681116: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:22:06.602498: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:22:06.730477: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:22:20.061551: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:22:34.808975: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:22:54.858337: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:22:54.894560: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:22:54.894560: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:22:56.650527: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:22:56.687714: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:22:56.687714: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:23:06.703129: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:23:20.304676: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:23:35.037757: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:24:05.203038: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:24:20.343002: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:24:35.231054: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:24:55.288245: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:24:55.325246: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:24:55.325246: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:24:56.969839: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:24:57.004306: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:24:57.004306: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:25:07.040060: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:25:09.897732: [TUN] [SCJ] peer(YEM2?4hlk) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 17:25:20.637465: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:25:35.454546: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:26:05.796951: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:26:20.944547: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:26:35.690929: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:26:55.764907: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:26:55.794395: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:26:55.794395: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:26:57.290792: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:26:57.327637: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:26:57.327637: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:27:07.377662: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:27:21.231565: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:27:35.922557: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:27:36.421954: [TUN] [SCJ] peer(heWL?uHXY) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 17:27:36.548033: [TUN] [SCJ] peer(8muY?GdG8) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 17:28:06.084701: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:28:21.184583: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:28:36.029678: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:28:56.037913: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:28:56.074318: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:28:56.074318: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:28:57.442542: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:28:57.484740: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:28:57.484740: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:29:07.520613: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:29:21.344070: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:29:36.100888: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:30:06.400442: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:30:21.504284: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:30:36.188109: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:30:56.209624: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:30:56.247405: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:30:56.247405: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:30:57.485071: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:30:57.521924: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:30:57.521924: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:31:07.652205: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:31:07.840676: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:31:21.406824: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:31:37.575343: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:31:37.589920: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:31:55.080962: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 17:31:56.089661: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:31:58.233091: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 17:31:59.255791: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:32:00.057307: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 17:32:01.061584: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:32:01.122650: [MGR] Unexpected size of WTSSESSION_NOTIFICATION: 6029401 2021-08-06 17:32:01.212321: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:32:01.270413: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:32:07.640919: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:32:07.753187: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:32:13.003022: [TUN] [SCJ] peer(heWL?uHXY) - Receiving keepalive packet 2021-08-06 17:32:17.570641: [TUN] [SCJ] Device closing 2021-08-06 17:32:17.648765: [TUN] [SCJ] Routine: TUN reader - stopped 2021-08-06 17:32:18.742428: [TUN] [SCJ] Routine: event worker - stopped 2021-08-06 17:32:18.853216: [TUN] [SCJ] Routine: receive incoming v4 - stopped 2021-08-06 17:32:18.853216: [TUN] [SCJ] Routine: receive incoming v6 - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(WBaN?k8hA) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(c9ys?npmo) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(1hMF?tqBw) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(heWL?uHXY) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YnSj?521U) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(8muY?GdG8) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YEM2?4hlk) - Stopping... 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Device closed 2021-08-06 17:32:18.957701: [TUN] [SCJ] Shutting down 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:32:18.957701: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:32:19.078642: [MGR] [SCJ] Tunnel service tracker finished 2021-08-06 17:33:45.742627: [MGR] Starting WireGuard/0.3.11 (Windows 10.0.19043; amd64) 2021-08-06 17:33:46.962592: [TUN] [SCJ] Starting WireGuard/0.3.11 (Windows 10.0.19043; amd64) 2021-08-06 17:33:47.017753: [TUN] [SCJ] SCM locked for 1m0s by .\NT Service Control Manager, marking service as started 2021-08-06 17:33:47.089201: [TUN] [SCJ] Watching network interfaces 2021-08-06 17:33:47.692783: [TUN] [SCJ] Resolving DNS names 2021-08-06 17:33:47.692783: [TUN] [SCJ] Creating Wintun interface 2021-08-06 17:33:59.100601: [MGR] An update is available 2021-08-06 17:34:04.168409: [TUN] [SCJ] [Wintun] CreateAdapter: Creating adapter 2021-08-06 17:34:04.297771: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 17:34:04.297771: [MGR] [Wintun] IsPoolMember: Reading pool devpkey failed, falling back: Element not found. (Code 0x00000490) 2021-08-06 17:34:10.311518: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.10 2021-08-06 17:34:18.245745: [TUN] [SCJ] Using Wintun/0.10 2021-08-06 17:34:18.245745: [TUN] [SCJ] Enabling firewall rules 2021-08-06 17:34:18.902306: [TUN] [SCJ] Dropping privileges 2021-08-06 17:34:18.966465: [TUN] [SCJ] Creating interface instance 2021-08-06 17:34:20.155080: [TUN] [SCJ] Setting interface configuration 2021-08-06 17:34:20.209395: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 17:34:20.209395: [TUN] [SCJ] UAPI: Updating private key 2021-08-06 17:34:20.209395: [TUN] [SCJ] UAPI: Removing all peers 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: handshake worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: encryption worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: decryption worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: event worker - started 2021-08-06 17:34:20.303115: [TUN] [SCJ] Routine: TUN reader - started 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Created 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating endpoint 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating persistent keepalive interval 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Removing all allowedips 2021-08-06 17:34:20.639441: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Adding allowedip 2021-08-06 17:34:20.639441: [TUN] [SCJ] Bringing peers up 2021-08-06 17:34:20.799390: [TUN] [SCJ] UDP bind has been updated 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(1hMF?tqBw) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(heWL?uHXY) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(YnSj?521U) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(8muY?GdG8) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(YEM2?4hlk) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(WBaN?k8hA) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] peer(c9ys?npmo) - Starting... 2021-08-06 17:34:20.799390: [TUN] [SCJ] Interface state was Down, requested Up, now Up 2021-08-06 17:34:20.799390: [TUN] [SCJ] Monitoring default v6 routes 2021-08-06 17:34:20.815014: [TUN] [SCJ] Binding v6 socket to interface 11 (blackhole=false) 2021-08-06 17:34:20.847623: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - started 2021-08-06 17:34:20.884469: [TUN] [SCJ] Routine: receive incoming v4 - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - started 2021-08-06 17:34:20.900108: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - started 2021-08-06 17:34:20.948736: [TUN] [SCJ] Setting device v6 addresses 2021-08-06 17:34:20.964407: [TUN] [SCJ] Routine: receive incoming v6 - started 2021-08-06 17:34:21.219933: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - started 2021-08-06 17:34:21.219933: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - started 2021-08-06 17:34:21.219933: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - started 2021-08-06 17:34:21.219933: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - started 2021-08-06 17:34:21.219933: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - started 2021-08-06 17:34:21.597101: [TUN] [SCJ] Monitoring default v4 routes 2021-08-06 17:34:21.597101: [TUN] [SCJ] Binding v4 socket to interface 11 (blackhole=false) 2021-08-06 17:34:21.597101: [TUN] [SCJ] Setting device v4 addresses 2021-08-06 17:34:21.990478: [TUN] [SCJ] Listening for UAPI requests 2021-08-06 17:34:22.025271: [TUN] [SCJ] Startup complete 2021-08-06 17:34:27.307537: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:34:27.372589: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:34:29.387353: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:34:29.529907: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:34:29.811061: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:34:29.980855: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:34:42.851118: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:34:42.884159: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:34:52.961420: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:35:08.960615: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:35:28.314893: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:35:28.399899: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:35:38.377799: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:35:53.560793: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:36:03.244120: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:36:04.734092: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:36:14.858126: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:36:27.578467: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:36:27.707937: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:36:27.707937: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:36:29.843314: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:36:30.118424: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:36:30.118424: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:36:38.004004: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:36:38.536815: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:36:41.777395: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:36:42.038924: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:36:42.038924: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:36:52.725882: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:36:52.944066: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:37:12.181207: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:37:12.224499: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:37:12.224499: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:37:32.067255: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:37:43.416586: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:37:59.275387: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:38:07.174346: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:38:27.536631: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:38:28.655094: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:38:28.707288: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:38:28.707288: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:38:30.156710: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:38:30.224549: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:38:30.224549: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:38:37.236648: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:38:40.359831: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:39:07.466248: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:39:25.080750: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:39:25.137222: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:39:25.137222: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:39:25.595955: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:39:25.638261: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:39:25.638261: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:39:44.456492: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:39:44.848386: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:39:57.433352: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:40:07.267582: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:40:11.677685: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:40:30.264680: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:40:30.413041: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:40:30.413041: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:40:33.129226: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:40:33.289654: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:40:33.289654: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:40:44.035872: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:41:13.471422: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:41:16.297165: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:41:35.923688: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:41:36.066179: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:41:36.066179: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:41:44.463605: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:42:14.206027: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:42:16.289228: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:42:27.529993: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:42:30.343868: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:42:30.447436: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:42:30.447436: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:42:34.381323: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:42:34.447374: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:42:34.447374: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:42:45.019335: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:42:47.687306: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:43:02.222308: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:43:02.366388: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:43:05.661147: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:43:05.689299: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:43:14.795300: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:43:15.754041: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:43:32.352093: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:43:40.580443: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:43:45.169082: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:43:47.689605: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:43:47.734066: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:43:47.734066: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:44:02.153130: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:44:04.712137: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:44:15.650597: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:44:15.839143: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:44:30.248218: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:44:30.496903: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:44:30.531797: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:44:30.531797: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:44:35.275157: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:44:35.341190: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:44:35.341190: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:45:01.157642: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:45:13.088956: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:45:21.138271: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:45:27.776665: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:45:47.968855: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:45:48.017450: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:45:48.017450: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:45:51.375130: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:46:05.427300: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:46:11.247250: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:46:11.332042: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:46:21.433620: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:46:21.586344: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:46:30.581762: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:46:30.618144: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:46:30.618144: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:46:36.422515: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:46:36.453628: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:46:36.453628: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:46:47.202453: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:46:51.712802: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:46:59.728664: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:47:10.754782: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:47:16.604998: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:47:27.145430: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:47:37.934191: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:48:07.569226: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:48:07.942183: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:48:07.945205: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:48:11.377147: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:48:11.409012: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:48:11.409012: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:48:21.419714: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:48:32.663559: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:48:35.072242: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:48:35.138988: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:48:35.138988: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:48:36.462582: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:48:36.535231: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:48:36.535231: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:49:16.904290: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:49:31.780180: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:49:40.519444: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:49:53.516816: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:50:08.578631: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:50:08.720434: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:50:08.720434: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:50:13.195121: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:50:13.245004: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:50:13.245004: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:50:35.599530: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:50:35.622560: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:50:35.622560: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:50:36.555228: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:50:36.581776: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:50:36.581776: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:50:53.402407: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:50:57.267439: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:51:23.568243: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:51:26.715943: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:51:32.110205: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:51:44.172501: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:51:46.677407: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 17:51:53.764059: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:52:13.786887: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:52:13.816068: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 17:52:13.816068: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 17:52:27.608810: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:52:38.292782: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:52:38.342910: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:52:38.342910: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:52:38.375307: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 17:52:51.798309: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:52:51.869952: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:52:51.869952: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:53:02.378626: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:53:32.137482: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:54:02.449102: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:54:37.631512: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:54:38.514279: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:54:38.551995: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:54:38.551995: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:54:49.921597: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:54:52.061035: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:54:52.099548: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:54:52.099548: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 17:55:04.808387: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:55:19.612018: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:55:50.110908: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:56:05.183286: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:56:09.498432: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:56:09.526784: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:56:19.825870: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:56:20.093853: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:56:34.679736: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 17:56:38.588301: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:56:38.614125: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:56:38.614125: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:57:02.331727: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 17:57:05.343572: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:57:19.936812: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:57:50.402472: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:58:05.245471: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:58:20.038880: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:58:38.620497: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:58:38.644252: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:58:38.644252: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 17:58:52.205039: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake initiation 2021-08-06 17:58:52.205039: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake response 2021-08-06 17:58:52.351996: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 17:58:54.773758: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 1 2021-08-06 17:58:56.323816: [TUN] [SCJ] Device closing 2021-08-06 17:58:56.528990: [TUN] [SCJ] Routine: TUN reader - stopped 2021-08-06 17:58:58.185197: [TUN] [SCJ] Routine: event worker - stopped 2021-08-06 17:58:58.204371: [TUN] [SCJ] Routine: receive incoming v4 - stopped 2021-08-06 17:58:58.204371: [TUN] [SCJ] Routine: receive incoming v6 - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(1hMF?tqBw) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(heWL?uHXY) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YnSj?521U) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(8muY?GdG8) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YEM2?4hlk) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(WBaN?k8hA) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(c9ys?npmo) - Stopping... 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - stopped 2021-08-06 17:58:58.212017: [TUN] [SCJ] Device closed 2021-08-06 17:58:58.212017: [TUN] [SCJ] Shutting down 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: decryption worker - stopped 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: handshake worker - stopped 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:58:58.212990: [TUN] [SCJ] Routine: encryption worker - stopped 2021-08-06 17:59:08.473213: [MGR] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 17:59:08.738119: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 17:59:08.819380: [TUN] [SCJ] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 17:59:08.821379: [TUN] [SCJ] Watching network interfaces 2021-08-06 17:59:09.089849: [TUN] [SCJ] Resolving DNS names 2021-08-06 17:59:09.089849: [TUN] [SCJ] Creating network adapter 2021-08-06 17:59:09.375336: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Creating adapter 2021-08-06 17:59:12.539620: [TUN] [SCJ] [Wintun] DisableAllOurAdapters: Force closing all adapter 3 open handles 2021-08-06 17:59:13.305867: [TUN] [SCJ] [Wintun] DisableAllOurAdapters: Disabling adapter 3 2021-08-06 17:59:14.447176: [TUN] [SCJ] [Wintun] DisableAllOurAdapters: Force closing all adapter 4 open handles 2021-08-06 17:59:16.403227: [TUN] [SCJ] [Wintun] DisableAllOurAdapters: Disabling adapter 4 2021-08-06 17:59:17.432421: [TUN] [SCJ] [Wintun] SelectDriver: Waiting for existing driver to unload from kernel 2021-08-06 17:59:17.434422: [TUN] [SCJ] [Wintun] SelectDriver: Removing existing driver 0.10 2021-08-06 17:59:33.308027: [TUN] [SCJ] [Wintun] SelectDriver: Installing driver 0.13 2021-08-06 17:59:33.426966: [TUN] [SCJ] [Wintun] SelectDriver: Extracting driver 2021-08-06 17:59:33.724944: [TUN] [SCJ] [Wintun] SelectDriver: Installing driver 2021-08-06 17:59:45.960827: [TUN] [SCJ] [Wintun] EnableAllOurAdapters: Enabling adapter 4 2021-08-06 17:59:46.181752: [TUN] [SCJ] [Wintun] EnableAllOurAdapters: Enabling adapter 3 2021-08-06 17:59:47.229389: [TUN] [SCJ] Using Wintun/0.13 2021-08-06 17:59:47.229389: [TUN] [SCJ] Enabling firewall rules 2021-08-06 17:59:48.151479: [TUN] [SCJ] Dropping privileges 2021-08-06 17:59:48.330635: [TUN] [SCJ] Creating interface instance 2021-08-06 17:59:48.451210: [TUN] [SCJ] Setting interface configuration 2021-08-06 17:59:48.452210: [TUN] [SCJ] UAPI: Updating private key 2021-08-06 17:59:48.452210: [TUN] [SCJ] UAPI: Removing all peers 2021-08-06 17:59:48.452210: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Created 2021-08-06 17:59:48.452210: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating endpoint 2021-08-06 17:59:48.452210: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.452210: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Removing all allowedips 2021-08-06 17:59:48.452210: [TUN] [SCJ] peer(WBaN?k8hA) - UAPI: Adding allowedip 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Created 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating endpoint 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Removing all allowedips 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YEM2?4hlk) - UAPI: Adding allowedip 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Created 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating endpoint 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Removing all allowedips 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(YnSj?521U) - UAPI: Adding allowedip 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Created 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating endpoint 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Removing all allowedips 2021-08-06 17:59:48.453207: [TUN] [SCJ] peer(c9ys?npmo) - UAPI: Adding allowedip 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Created 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating endpoint 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Removing all allowedips 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(heWL?uHXY) - UAPI: Adding allowedip 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Created 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating endpoint 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Removing all allowedips 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(1hMF?tqBw) - UAPI: Adding allowedip 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Created 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating endpoint 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Updating persistent keepalive interval 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Removing all allowedips 2021-08-06 17:59:48.454204: [TUN] [SCJ] peer(8muY?GdG8) - UAPI: Adding allowedip 2021-08-06 17:59:48.454204: [TUN] [SCJ] Bringing peers up 2021-08-06 17:59:48.466206: [TUN] [SCJ] UDP bind has been updated 2021-08-06 17:59:48.466206: [TUN] [SCJ] peer(WBaN?k8hA) - Starting 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: encryption worker 2 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: encryption worker 1 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: decryption worker 1 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: handshake worker 1 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: event worker - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: decryption worker 2 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: handshake worker 2 - started 2021-08-06 17:59:48.501210: [TUN] [SCJ] Routine: TUN reader - started 2021-08-06 17:59:48.546185: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - started 2021-08-06 17:59:48.546185: [TUN] [SCJ] Routine: receive incoming v4 - started 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(YEM2?4hlk) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(YnSj?521U) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(c9ys?npmo) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(heWL?uHXY) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(1hMF?tqBw) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] peer(8muY?GdG8) - Starting 2021-08-06 17:59:48.655197: [TUN] [SCJ] Interface state was Down, requested Up, now Up 2021-08-06 17:59:48.655197: [TUN] [SCJ] Monitoring default v6 routes 2021-08-06 17:59:48.656195: [TUN] [SCJ] Binding v6 socket to interface 11 (blackhole=false) 2021-08-06 17:59:48.657196: [TUN] [SCJ] Routine: receive incoming v6 - started 2021-08-06 17:59:48.742064: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - started 2021-08-06 17:59:48.843877: [TUN] [SCJ] Setting device v6 addresses 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - started 2021-08-06 17:59:48.872847: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - started 2021-08-06 17:59:49.745830: [TUN] [SCJ] Monitoring default v4 routes 2021-08-06 17:59:49.746834: [TUN] [SCJ] Binding v4 socket to interface 11 (blackhole=false) 2021-08-06 17:59:49.746834: [TUN] [SCJ] Setting device v4 addresses 2021-08-06 17:59:50.544081: [TUN] [SCJ] Listening for UAPI requests 2021-08-06 17:59:50.544081: [TUN] [SCJ] Startup complete 2021-08-06 17:59:57.174032: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 17:59:57.178006: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 17:59:57.387115: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 17:59:57.389090: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 17:59:57.470404: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 17:59:57.747660: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 17:59:57.892934: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 17:59:58.078278: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 17:59:58.149696: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 17:59:58.228032: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 18:00:08.230938: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 18:00:08.230938: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 18:00:09.146962: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 18:00:09.752791: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:00:16.420446: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:00:26.360629: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:00:27.369733: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:00:29.632207: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 18:00:32.039310: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 18:00:38.587417: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:00:48.689160: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:00:58.746228: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:01:02.331688: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 18:01:10.329737: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:01:12.350807: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 18:01:22.380465: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 18:01:25.435177: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:01:40.067631: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:01:43.511913: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:02:00.102301: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:02:00.199322: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:02:00.199322: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:02:10.768510: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:02:25.903427: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:02:40.954544: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:03:11.280367: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:03:26.277978: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:03:40.962852: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:04:01.118743: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:04:01.150412: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:04:01.150412: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:04:11.318806: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:04:26.426068: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:04:41.229580: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:05:11.476610: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:05:26.580546: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:05:41.333538: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:06:01.376392: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:06:01.397463: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:06:01.397463: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:06:11.637439: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:06:20.414329: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:06:20.439227: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:06:26.740880: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:06:30.883900: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:06:41.465578: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:06:45.474327: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:07:05.444375: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:07:11.795569: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:07:26.906064: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:07:41.568773: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:08:01.905747: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:08:01.947179: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:08:01.947179: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:08:12.263411: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:08:27.316048: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:08:42.008580: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:08:57.397514: [TUN] [SCJ] peer(heWL?uHXY) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 18:08:57.760774: [TUN] [SCJ] peer(WBaN?k8hA) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 18:08:58.237583: [TUN] [SCJ] peer(8muY?GdG8) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 18:09:12.626589: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:09:27.731834: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:09:42.436679: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:10:02.463868: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:10:02.502080: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:10:02.502080: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:10:12.787424: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:10:27.890027: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:10:42.539833: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:11:12.952532: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:11:27.794089: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:11:42.685913: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:12:02.738715: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:12:02.760400: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:12:02.760400: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:12:13.103796: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:12:28.208706: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:12:42.826734: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:13:13.264713: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:13:28.369327: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:13:43.026869: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:14:03.069953: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:14:03.133839: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:14:03.133839: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:14:13.431952: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:14:28.528283: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:14:43.145630: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:15:01.748486: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:15:01.769056: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:15:12.097056: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:15:13.583493: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:15:22.862298: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:15:28.691326: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:15:43.358235: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:16:03.380114: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:16:03.433878: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:16:03.433878: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:16:11.276936: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:16:13.742407: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:16:28.881919: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:16:43.478097: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:17:09.515465: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:17:09.545480: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:17:09.545480: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:17:29.362298: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:17:43.835177: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:18:03.897434: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:18:03.926756: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:18:03.926756: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:18:14.320495: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:18:29.170443: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:18:44.006858: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:19:14.498220: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:19:29.332881: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:19:44.177655: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:20:04.244899: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:20:04.308795: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:20:04.309417: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:20:14.679768: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:20:29.756290: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:20:44.354330: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:21:14.552948: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:21:29.657739: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:21:44.477041: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:22:04.508663: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:22:04.556615: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:22:04.556615: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:22:14.729200: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:22:29.818639: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:22:44.691265: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:23:14.886336: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:23:29.979494: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:23:44.723941: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:24:04.760663: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:24:04.781357: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:24:04.781357: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:24:15.033248: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:24:30.137061: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:24:44.845475: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:25:15.227274: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:25:30.295223: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:25:45.101666: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:26:05.026292: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:26:05.083596: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:26:05.083596: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:26:09.567289: [TUN] [SCJ] peer(YEM2?4hlk) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 18:26:15.366536: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:26:30.456386: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:26:45.111752: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:27:15.403083: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:27:30.614262: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:27:45.226372: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:28:05.234482: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:28:05.283378: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:28:05.283378: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:28:15.442619: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:28:30.519272: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:28:45.310039: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:29:15.862741: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:29:30.677063: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:29:45.431678: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:30:02.062686: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:30:02.085800: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:30:05.440100: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:30:05.472003: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:30:05.472003: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:30:12.456159: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:30:15.735442: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:30:23.206180: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:30:30.839170: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:30:45.507684: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:31:15.899367: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:31:30.996738: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:31:45.806473: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:31:48.378950: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 18:31:48.412796: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 18:31:58.616979: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 18:31:59.206188: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:32:05.845487: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:32:05.886464: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:32:05.887064: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:32:16.053115: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:32:31.157445: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:32:45.935360: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:33:16.215797: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:33:31.316178: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:33:46.008666: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:34:06.215731: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:34:06.252283: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:34:06.252283: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:34:13.528851: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:34:13.551263: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:34:16.650042: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:34:23.591102: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:34:31.481061: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:34:46.326253: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:35:16.797911: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:35:31.913966: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:35:46.479944: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:36:06.527651: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:36:06.549886: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:36:06.550491: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:36:16.947074: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:36:23.307250: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:36:23.344642: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:36:23.344642: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:36:31.798616: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:36:33.891152: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:36:46.634570: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:37:08.493804: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:37:17.381701: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:37:32.221223: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:37:46.956727: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:38:07.043930: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:38:07.091219: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:38:07.091219: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:38:17.553740: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:38:32.639077: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:38:47.218864: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:39:17.703671: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:39:32.790581: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:39:47.482246: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:40:07.509718: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:40:07.550862: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:40:07.550862: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:40:17.845093: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:40:32.943871: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:40:47.607091: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:40:48.418508: [TUN] [SCJ] peer(WBaN?k8hA) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 18:41:18.008057: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:41:33.111913: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:41:47.737524: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:42:07.767693: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:42:07.797070: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:42:07.797070: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:42:18.160767: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:42:33.007420: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:42:47.855297: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:43:18.333127: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:43:33.168845: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:43:48.047686: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:44:08.093134: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:44:08.135826: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:44:08.135826: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:44:18.737023: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:44:33.885901: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:44:48.324528: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:45:02.556526: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:45:02.591608: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:45:13.337163: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:45:19.178171: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:45:23.843408: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 18:45:34.295626: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:45:49.175816: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:46:09.338988: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:46:09.373597: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:46:09.373597: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:46:19.902104: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:46:34.939087: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:46:49.621290: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:47:19.755084: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:47:34.850998: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:47:49.766768: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:48:09.655048: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:48:09.815980: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:48:09.815980: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:48:20.667195: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:48:35.798498: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:48:50.143926: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:49:20.812154: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:49:35.949514: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:49:50.528714: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:50:10.542712: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:50:10.573135: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:50:10.573738: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:50:21.020539: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:50:36.102913: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:50:50.683283: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:51:17.538754: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 18:51:17.563042: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 18:51:21.143733: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:51:27.624206: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 18:51:36.240350: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:51:50.959375: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:52:11.025895: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:52:11.134417: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:52:11.134417: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:52:21.558356: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:52:36.671601: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:52:51.246911: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:53:21.978581: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:53:36.829699: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:53:53.534284: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:54:11.735679: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:54:11.770897: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:54:11.770897: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:54:22.329510: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:54:37.300686: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:54:51.972097: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:55:22.879104: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:55:37.953931: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:55:52.554711: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:56:12.640468: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:56:12.746500: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:56:12.746500: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:56:23.496297: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:56:38.588089: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:56:52.864455: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:57:23.382790: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:57:38.490159: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:57:53.172528: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:58:13.185974: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 18:58:13.256935: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 18:58:13.256935: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:58:23.549945: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:58:38.492768: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:58:53.312126: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 18:59:23.708456: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:59:38.553710: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 18:59:53.420286: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:00:03.234026: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:00:03.254655: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:00:13.600802: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:00:13.623056: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:00:13.623056: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:00:13.677737: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:00:23.864067: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:00:24.170112: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:00:38.968592: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:00:53.698221: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:01:24.027017: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:01:39.131554: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:01:53.951622: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:02:14.164899: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:02:14.244313: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:02:14.244313: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:02:24.714340: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:02:41.452951: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:02:54.349142: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:03:25.115047: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:03:40.222214: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:03:54.670616: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:04:14.745996: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:04:14.808685: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:04:14.808685: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:04:25.017759: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:04:40.126357: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:04:54.860161: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:05:25.176541: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:05:40.282115: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:05:54.953948: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:06:14.973109: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:06:15.028481: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:06:15.029113: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:06:25.338086: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:06:28.634121: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:06:28.657714: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:06:39.747424: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:06:40.186155: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:06:53.803796: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:06:55.055512: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:07:13.770769: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:07:25.497139: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:07:40.605096: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:07:55.181507: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:08:15.196531: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:08:15.227006: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:08:15.227006: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:08:25.401242: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:08:31.640381: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:08:31.640381: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:08:31.666328: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:08:31.666837: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:08:40.611548: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:08:55.444170: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:09:25.558766: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:09:40.662896: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:09:55.373032: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:10:15.419484: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:10:15.476908: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:10:15.476908: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:10:25.718145: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:10:40.822557: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:10:55.504279: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:11:25.902954: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:11:40.980140: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:11:55.623918: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:12:15.935024: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:12:15.961952: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:12:15.961952: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:12:26.291953: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:12:41.139543: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:12:56.014011: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:13:26.456871: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:13:41.552902: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:13:56.148429: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:14:16.219247: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:14:16.288936: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:14:16.288936: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:14:26.612444: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:14:56.332033: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:15:03.532894: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:15:03.555093: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:15:13.762399: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:15:24.514257: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:15:26.513311: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:15:41.616241: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:15:56.424529: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:16:16.453527: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:16:16.481767: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:16:16.481767: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:16:26.671933: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:16:41.774887: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:16:56.535121: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:17:26.828616: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:17:41.933748: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:17:56.606778: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:18:16.621626: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:18:16.655284: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:18:16.655284: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:18:26.735098: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:18:41.837823: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:18:56.695070: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:19:26.892191: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:19:41.996482: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:19:56.774662: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:20:16.777114: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:20:16.818940: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:20:16.818940: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:20:27.051870: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:20:42.157967: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:20:56.857059: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:21:30.028691: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:21:45.130500: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:21:59.957024: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:22:19.958594: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:22:19.983070: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:22:19.983070: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:22:30.190174: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:22:45.293310: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:23:00.077195: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:23:30.346574: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:23:45.450769: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:24:00.102567: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:24:03.568401: [TUN] [SCJ] peer(YEM2?4hlk) - Removing all keys, since we haven't received a new one in 540 seconds 2021-08-06 19:24:20.107350: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:24:20.126164: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:24:20.126712: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:24:30.248139: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:24:45.356386: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:25:00.176794: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:25:25.583045: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:25:25.606473: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:25:30.409829: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:25:35.636493: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:25:45.516266: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:26:00.282749: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:26:20.297046: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:26:20.324339: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:26:20.324339: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:26:30.570532: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:26:45.676587: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:27:00.370133: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:27:30.735192: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:27:45.584681: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:28:00.465134: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:28:20.489550: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:28:20.524197: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:28:20.524197: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:28:30.640936: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:28:45.746261: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:29:00.558402: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:29:30.805862: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:29:45.912661: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:30:00.759845: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:30:03.874751: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:30:03.899386: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:30:14.124491: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:30:20.778742: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:30:20.801292: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:30:20.801292: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:30:24.873595: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:30:30.970590: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:30:46.072908: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:31:00.844463: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:31:31.129469: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:31:46.236302: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:31:59.597359: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:32:00.954015: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:32:16.406071: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:32:16.427467: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:32:16.428036: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:32:16.507269: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 19:32:16.541880: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 19:32:20.968328: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:32:20.988580: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:32:20.988580: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:32:28.226317: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 19:32:31.290793: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:32:46.394609: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:32:51.175375: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 19:32:51.211096: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 19:33:05.648687: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:33:05.659283: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 19:33:10.970308: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:33:16.914459: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:33:16.926469: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 19:33:27.661789: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:33:31.246265: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:33:40.704511: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:33:46.301114: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:33:46.699923: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:33:54.541476: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:34:01.116131: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:34:16.728985: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:34:21.145967: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:34:21.178918: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:34:21.178918: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:34:24.424934: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:34:24.424934: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:34:24.454006: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:34:24.454576: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:34:31.358134: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:34:46.460844: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:34:46.770587: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:34:54.456646: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:35:01.220814: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:35:06.732269: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 19:35:06.758944: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 19:35:06.759512: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:35:16.801511: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:35:31.518257: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:35:46.621636: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:35:53.585720: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:36:01.431079: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:36:04.082179: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:36:21.464164: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:36:21.488133: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:36:21.488133: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:36:24.468563: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:36:24.492704: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:36:24.492704: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:36:31.678580: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:36:46.779751: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:37:01.542237: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:37:31.903605: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:37:46.942800: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:37:51.695908: [TUN] [SCJ] peer(WBaN?k8hA) - Sending handshake initiation 2021-08-06 19:37:51.734111: [TUN] [SCJ] peer(WBaN?k8hA) - Received handshake response 2021-08-06 19:37:52.115982: [TUN] [SCJ] peer(8muY?GdG8) - Sending handshake initiation 2021-08-06 19:37:52.145323: [TUN] [SCJ] peer(8muY?GdG8) - Received handshake response 2021-08-06 19:37:52.145323: [TUN] [SCJ] peer(8muY?GdG8) - Sending keepalive packet 2021-08-06 19:38:02.319389: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 19:38:02.611179: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:38:03.075648: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:38:13.871654: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:38:13.873559: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:38:13.890956: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 19:38:21.635445: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:38:21.674812: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:38:21.674812: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:38:30.392210: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:38:30.417955: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:38:30.417955: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:38:47.409198: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:38:55.616742: [TUN] [SCJ] peer(WBaN?k8hA) - Receiving keepalive packet 2021-08-06 19:38:58.418502: [TUN] [SCJ] peer(8muY?GdG8) - Receiving keepalive packet 2021-08-06 19:39:10.658717: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:39:11.141544: [TUN] [SCJ] peer(WBaN?k8hA) - Sending keepalive packet 2021-08-06 19:39:47.007865: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:40:10.484012: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:40:18.145595: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:40:21.825969: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:40:21.859612: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:40:21.859612: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:40:40.305219: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:40:40.731118: [TUN] [SCJ] peer(YEM2?4hlk) - Sending handshake initiation 2021-08-06 19:40:40.755767: [TUN] [SCJ] peer(YEM2?4hlk) - Received handshake response 2021-08-06 19:40:40.755767: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:41:01.897416: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:41:04.073312: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 19:41:05.099176: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 19:41:07.199273: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:41:09.630345: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 19:41:10.635553: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 19:41:11.739993: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 19:41:12.769096: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 19:41:13.638792: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-06 19:41:14.662639: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-06 19:41:14.662639: [MGR] Unable to start manager UI process for user 'username.redacted at SCJ' for session 1: Session has logged out 2021-08-06 19:41:25.608850: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:41:39.040891: [TUN] [SCJ] peer(heWL?uHXY) - Sending handshake initiation 2021-08-06 19:41:39.093054: [TUN] [SCJ] peer(heWL?uHXY) - Received handshake response 2021-08-06 19:41:39.184531: [TUN] [SCJ] peer(YEM2?4hlk) - Receiving keepalive packet 2021-08-06 19:41:49.315054: [TUN] [SCJ] peer(heWL?uHXY) - Sending keepalive packet 2021-08-06 19:42:04.992175: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:42:15.850976: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:42:22.026175: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:42:22.052475: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:42:22.052475: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:42:32.384040: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:42:39.623685: [TUN] [SCJ] peer(YEM2?4hlk) - Sending keepalive packet 2021-08-06 19:42:47.488759: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:43:02.113265: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:43:32.542757: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:43:47.662060: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:44:02.213255: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:44:22.446303: [TUN] [SCJ] peer(1hMF?tqBw) - Sending handshake initiation 2021-08-06 19:44:22.476664: [TUN] [SCJ] peer(1hMF?tqBw) - Received handshake response 2021-08-06 19:44:22.476664: [TUN] [SCJ] peer(1hMF?tqBw) - Sending keepalive packet 2021-08-06 19:44:32.714319: [TUN] [SCJ] peer(1hMF?tqBw) - Receiving keepalive packet 2021-08-06 19:44:40.676163: [TUN] [SCJ] Device closing 2021-08-06 19:44:40.752115: [TUN] [SCJ] Routine: TUN reader - stopped 2021-08-06 19:44:43.637469: [TUN] [SCJ] Routine: event worker - stopped 2021-08-06 19:44:43.714271: [TUN] [SCJ] Routine: receive incoming v4 - stopped 2021-08-06 19:44:43.714271: [TUN] [SCJ] Routine: receive incoming v6 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(1hMF?tqBw) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(1hMF?tqBw) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(8muY?GdG8) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(8muY?GdG8) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(WBaN?k8hA) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(WBaN?k8hA) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YEM2?4hlk) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YEM2?4hlk) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YnSj?521U) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(YnSj?521U) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(c9ys?npmo) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(c9ys?npmo) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(heWL?uHXY) - Stopping 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential sender - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] peer(heWL?uHXY) - Routine: sequential receiver - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Device closed 2021-08-06 19:44:43.714911: [TUN] [SCJ] Shutting down 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: decryption worker 1 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: handshake worker 2 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: decryption worker 2 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: handshake worker 1 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: encryption worker 1 - stopped 2021-08-06 19:44:43.714911: [TUN] [SCJ] Routine: encryption worker 2 - stopped 2021-08-06 19:44:43.786651: [MGR] [SCJ] Tunnel service tracker finished 2021-08-06 19:46:15.039160: [MGR] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 19:46:18.899902: [TUN] [SCJ] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 19:46:19.249315: [TUN] [SCJ] Watching network interfaces 2021-08-06 19:46:22.608757: [TUN] [SCJ] Resolving DNS names 2021-08-06 19:46:22.608757: [TUN] [SCJ] Creating network adapter 2021-08-06 19:46:32.157022: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Creating adapter 2021-08-06 19:46:41.129852: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.13 2021-08-06 19:46:41.237299: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Failed to register adapter 17 device: The device instance does not exist in the hardware tree. (Code 0xE000020B) 2021-08-06 19:46:42.457251: [TUN] [SCJ] Retrying adapter creation after failure because system just booted (T+1m39.109s): Error creating interface: winapi error #3758096907 2021-08-06 19:46:42.457251: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Creating adapter 2021-08-06 19:46:44.047474: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.13 2021-08-06 19:51:51.408322: [TUN] [SCJ] [Wintun] WintunSetAdapterName: Failed to set adapter name: There are no more endpoints available from the endpoint mapper. (Code 0x000006D9) 2021-08-06 19:51:51.408322: [TUN] [SCJ] [Wintun] WintunCreateAdapter: Failed to set adapter name SCJ 2021-08-06 19:51:52.392522: [TUN] [SCJ] Unable to create network adapter: Error creating interface: There are no more endpoints available from the endpoint mapper. 2021-08-06 19:51:52.442380: [TUN] [SCJ] Shutting down 2021-08-06 19:51:52.540997: [MGR] [SCJ] Tunnel service tracker finished 2021-08-06 20:00:37.564066: [MGR] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-06 20:53:58.598555: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:15:11.618046: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-07 07:15:12.628022: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:15:14.905381: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-07 07:15:15.916778: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:15:15.983728: [MGR] Unable to start manager UI process for user 'username.redacted at SCJ' for session 1: Session has logged out 2021-08-07 07:16:54.425294: [MGR] Starting WireGuard/0.4.2 (Windows 10.0.19043; amd64) 2021-08-07 07:17:49.011942: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:22:19.054821: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-07 07:22:20.069324: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:22:22.386893: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-07 07:22:23.440348: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:22:28.860012: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 40010004 2021-08-07 07:22:29.873132: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:22:30.581326: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status c000013a 2021-08-07 07:22:31.605182: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 1 2021-08-07 07:22:33.617942: [MGR] Exited UI process for user 'username.redacted at SCJ' for session 1 with status 1 2021-08-07 07:24:10.227108: [MGR] Starting UI process for user ?username.redacted at SCJ? for session 2 From Jason at zx2c4.com Sun Aug 8 00:28:35 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 02:28:35 +0200 Subject: WireGuard for Windows 0.4.2 failed to start due to WintunSetAdapterName failure (Code 0x000006D9) In-Reply-To: References: Message-ID: Hi Joshua, One interesting part of your log is the timestamps: 2021-08-06 19:46:44.047474: [TUN] [SCJ] [Wintun] SelectDriver: Using existing driver 0.13 2021-08-06 19:51:51.408322: [TUN] [SCJ] [Wintun] WintunSetAdapterName: Failed to set adapter name: There are no more endpoints available from the endpoint mapper. (Code 0x000006D9) Apparently it hung for almost exactly 5 minutes, before moving onto the next step, which then died with the mysterious EPT_S_NOT_REGISTERED error, presumably caused by nci.dll->netsetupapi.dll->rpcrt4.dll. One strategy would be to put yet-another-sleep-retry loop over SetAdapterName, but I imagine that it'd still fail anyway, with the previous step somehow failing silently after a 5 minute timeout, and not actually setting up the interface, perhaps during registration. That's unfortunate. Ultimately, after the 5 minute pause, it was no longer within 4 minutes of system boot, so it didn't try again. I could increase that heuristic to be a bit larger than 4 minutes -- perhaps I should make it 10? But ultimately that's just a heuristic. Better would be to find the proper set of services that wireguard should start after. Right now we pick "Nsi" and "TcpIp". We need another one in there, perhaps, but I'm not yet sure what. "netprofm" maybe? I'm open to suggestions here if you have any intuition on Windows boot processes. Jason From Jason at zx2c4.com Sun Aug 8 13:28:17 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 15:28:17 +0200 Subject: WireGuard for Windows 0.4.2 failed to start due to WintunSetAdapterName failure (Code 0x000006D9) In-Reply-To: References: Message-ID: Hi Joshua, I've increased the heuristic's timing a bit: https://git.zx2c4.com/wireguard-windows/commit/?id=a3e6316aa7b1d80098ad49732a05aec1c9b62849 I still would like to find a better set of _real_ bootup dependencies, however. Jason From someguy at effective-light.com Fri Aug 6 04:43:14 2021 From: someguy at effective-light.com (Hamza Mahfooz) Date: Fri, 6 Aug 2021 00:43:14 -0400 Subject: [PATCH] wireguard: convert index_hashtable and pubkey_hashtable into rhashtables Message-ID: <20210806044315.169657-1-someguy@effective-light.com> 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 --- 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 -#include +#include #include 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 fawazahmed0 at hotmail.com Sun Aug 8 18:07:59 2021 From: fawazahmed0 at hotmail.com (fawaz ahmed0) Date: Sun, 8 Aug 2021 18:07:59 +0000 Subject: Wireguard client v0.4.2 doesn't work on windows 7 In-Reply-To: References: Message-ID: Went back to v0.3.15, just had to disable driver signature enforcement to make things working again in v0.3.15 Thanks, Fawaz Ahmed From Jason at zx2c4.com Sun Aug 8 20:22:42 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 22:22:42 +0200 Subject: [PATCH 6/6 v2] wireguard: main: rename 'mod_init' & 'mod_exit' functions to be module-specific In-Reply-To: <20210711223148.5250-7-rdunlap@infradead.org> References: <20210711223148.5250-1-rdunlap@infradead.org> <20210711223148.5250-7-rdunlap@infradead.org> Message-ID: Hi Randy, Thanks, I've applied this to the wireguard stable tree, and it'll be sent off to netdev during the next push there. Regards, Jason From Jason at zx2c4.com Sun Aug 8 20:36:14 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 22:36:14 +0200 Subject: Wireguard client v0.4.2 doesn't work on windows 7 In-Reply-To: References: Message-ID: Hi Fawaz, Could you send a complete log from 0.4.2? Otherwise I won't be able to fix the problem. Thanks, Jason From Jason at zx2c4.com Sun Aug 8 20:53:18 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sun, 8 Aug 2021 22:53:18 +0200 Subject: [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches In-Reply-To: <20210706132714.8220-1-minipli@grsecurity.net> References: <20210706132714.8220-1-minipli@grsecurity.net> Message-ID: Hi Mathias, Sorry for the delay in reviewing these. Thanks for that. I've merged them with a trivial change. The constraint one is interesting; it looks like with your change and those extra constraints it winds up spilling rdi to the stack? Jason From Jason at zx2c4.com Sun Aug 8 22:33:13 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Aug 2021 00:33:13 +0200 Subject: another thread on montonic counter alternatives Message-ID: Hi folks, We've had this discussion a few times in various forms, but it's come up again recently, with Karolin Varner (CC'd) emailing me with some fresh enthusiasm about the problem space, so I thought this might be something worth discussing again, perhaps this time with some input from the Noise mailing list. NoiseIK is 1-RTT, so WireGuard sticks a timestamp in the first message to prevent replay attacks. Responders reject packets with timestamps that are larger than the last one received. If a responder reboots, there's subsequently no session to disrupt with a replay anyway, so it's not an issue. Generally this works well, provided initiators have a reliable monotonic counter. Generally timestamps are considered reliable-enough monotonic counters. Issues with this begin from two angles: Angle 1) Embedded devices without a battery powered RTC that want to use WireGuard to bootstrap have a chicken & egg problem. Angle 2) Initiators that are using the old, crusty, and insecure NTP protocol can have their time hijacked. Angle 2 presents some interesting possibilities. An adversary who sets somebody's time backwards can prevent them from connecting until their time is set right again. Adversaries who set somebody's time forward, say, to the maximum TAI64N value, and then subsequently have an initiator send an initiation message, can then render that initiator's static private key forever useless, since that future timestamp can always be replayed, and will always set the responder's greatest-yet value to that maximum. So, if your NTP is hijacked, your key is forever DoS'd. We've talked about a few solutions before to this. They all have various pitfalls. Idea 0) Insist people don't use NTP but rather some authenticated alternative. Insist people have battery-powered RTCs. Idea 1) Store a monotonic counter on disk, and just increment it by 1, or even some random value bounded far below the limit, on each handshake. The downside is this relies on storage that doesn't wear out and is always available. Idea 2) For a given system boot, store in memory the time of the first handshake, and then increment that timestamp by 1 on each handshake. The problem is figuring out when to sample that initial golden timestamp. And it doesn't actually solve Angle 2, because that initial golden timestamp still might wind up NTP sync'd at some point. Idea 3) Insist people who must use NTP disable large jumps. This has the same issue as Idea 2, in that the bootstrapping timestamp is still an issue. Idea 4) Require the responder to also have a synchronized clock and reject handshakes that are too far into the future. This might alleviate Angle 2 to a large degree but it causes big issues for Angle 1, potentially. Other clever ideas? Jason From Jason at zx2c4.com Sun Aug 8 23:08:00 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Aug 2021 01:08:00 +0200 Subject: wireguard-windows: client forgets after restart that there was a activated tunnel before and won't activate said tunnel anymore In-Reply-To: References: Message-ID: Hi Denis, That's a weird issue. Generally the WireGuardTunnel service should stay installed unless explicitly uninstalled. The UninstallTunnel() function is called from three places: 1) if you execute wireguard.exe /uninstalltunnelservice [name]. 2) If the user presses "deactivate". 3) If the manager quits with "stoponquit", which happens only when the user right clicks on the tray and presses "exit". Are you sure that (3) isn't being hit unexpectedly? Jason From phillip.mcmahon at gmail.com Sun Aug 8 23:37:58 2021 From: phillip.mcmahon at gmail.com (Phillip McMahon) Date: Mon, 9 Aug 2021 01:37:58 +0200 Subject: ERX wireguard assistance please In-Reply-To: <7388816e-1f87-fa5e-f509-7276a6d3b80d@gmail.com> References: <7388816e-1f87-fa5e-f509-7276a6d3b80d@gmail.com> Message-ID: Hi Simon, I think that query is more for the ubiquity support forum, as you're almost certainly going to have to supply your config.boot file etc. which is somewhat outside of the pure wg. Regards, Phill On Mon, 9 Aug 2021 at 01:06, Simon McNair wrote: > > Hi, > I've searched to try and find the solution to my issue but I'm no expert > and I'm not entirely sure what to search for. I would appreciate your > help please. > > In summary, If I connect to my LAN via local WiFi I successfully connect > to wireguard: > interface: wg0 > public key: > private key: (hidden) > listening port: 12345 > > peer: > endpoint: 192.168.100.102:50084 > allowed ips: 10.250.250.5/32 > latest handshake: Now > transfer: 157.33 KiB received, 536.33 KiB sent > persistent keepalive: every 25 seconds > > However if I try and connect via a remote network it fails. My DDNS is > resolving correctly to the correct IP so I can only think that firewall > rules or NAT is somehow causing the issue. Has anyone come across this > before please ? > I don't know how to monitor my WAN port 12345 for activity, I tried > tcpdump -n -v -i wg0 to no real benefit. > > > The ERX is running v2.0.9-hotfix.2 and > e50-v2-v1.0.20210606-v1.0.20210424.deb > > > High level the infrastructure is: > > LAN: 192.168.100.0/24 > wg ip : 10.250.250.1/24 > listen port:12345 > route-allowed-ips:true > peer allowed ip is : 10.250.250.5/32 > Firewall policy WAN_LOCAL default action drop, rule 2 wireguard > destination port 12345, protocol udp, action accept > > > I would appreciate any help you can provide. The aim is to be able to > access resources in the 192.168.100.0/24 subnet using routed ip from the > 10.250.250.0/24 transit network. > > My apologies if my syntax or understanding is flawed. > > Regards > > Simon > > -- Phillip McMahon https://flowcrypt.com/me/phillipmcmahon https://keys.openpgp.org/vks/v1/by-fingerprint/EA0483D4C864AA7C10994BE6A11E70ADFDA60CF9 From karo at cupdev.net Sun Aug 8 23:18:59 2021 From: karo at cupdev.net (Karolin Varner) Date: Mon, 9 Aug 2021 01:18:59 +0200 Subject: another thread on montonic counter alternatives In-Reply-To: References: Message-ID: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Good evening, I can see this has been copiously discussed? On 8/9/21 12:33 AM, Jason A. Donenfeld wrote: > Angle 2 presents some interesting possibilities. An adversary who sets > somebody's time backwards can prevent them from connecting until their > time is set right again. Adversaries who set somebody's time forward, > say, to the maximum TAI64N value, and then subsequently have an > initiator send an initiation message, can then render that initiator's > static private key forever useless, since that future timestamp can > always be replayed, and will always set the responder's greatest-yet > value to that maximum. So, if your NTP is hijacked, your key is > forever DoS'd. In my view this presents a major problem. I don't have data on this, but I think this is a common setup. Mine was vulnerable and if you didn't take care to prevent this yours is probably too. At the very least there should be a bold, red warning on the webpage "do not use WG with NTP". > Other clever ideas? 0) Just send the value of tsmax to the peer? This basically surmounts to falling back to fully interactive but is a minimal change? 1) Pick a random time stamp/a time stamp based on the peers `MAC(cookie_secret, IP | Port)` and accept that for a single time only. This also basically surmounts to an interactive handshake with minimal changes. Is changing the protocol an option? Two options for that: 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. 3) Use a stateless responder; forego the timestamp entirely. Instead of storing the handshake state (ck, h, eskr) locally, they could be encrypted with a random key and included in the second message. This way, there is no responder state an attacker could interrupt. 2) is 1-RTT in the normal case and 2-RTT with the attack agains the counter. 3) is always 1-RTT and always interactive but requires a response for replayed old handshakes. Jason pointed out, that it would be preferable to use a Noise-XK handshake which is a standard fully-interactive handshake but 1.5-RTT. I was assuming 1-RTT-ness was a necessity. Of course, coming up with a new handshake is?generally foolish and even though both my proposal technially fit into the noise-IK pattern, noise-XK certainly is more trustworthy. Noise XK could also be used as a fallback only, but this would considerably increase complexity. As far as mitigations go: a) Do not drop handshake state after three minutes, just ratchet the key `MixKey(empty)` so the attack can not disrupt active sessions. b) Jason's angle 4 but with a flag. A command line switch "interpret counter as timestamp and reject timestamps off by more than 20m". Best, Karolin From Jason at zx2c4.com Mon Aug 9 00:21:42 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Mon, 9 Aug 2021 02:21:42 +0200 Subject: Windows Client - Issue with Tray Icon In-Reply-To: <7587bd77-a81c-0488-90b5-eac7ed98a3db@ut1.org> References: <437b77e7-7e63-74c4-4447-713eccd42b59@ut-capitole.fr> <7587bd77-a81c-0488-90b5-eac7ed98a3db@ut1.org> Message-ID: Hi Bruno, Thanks for the suggestion. Implemented here: https://git.zx2c4.com/wireguard-windows/commit/?id=9c230818231d6395c1d4211d78b2f3ea2ed93943 Jason From minipli at grsecurity.net Mon Aug 9 10:13:54 2021 From: minipli at grsecurity.net (Mathias Krause) Date: Mon, 9 Aug 2021 12:13:54 +0200 Subject: [PATCH 0/2] wireguard-linux-compat: grsecurity compat patches In-Reply-To: References: <20210706132714.8220-1-minipli@grsecurity.net> Message-ID: Hi Jason, Am 08.08.21 um 22:53 schrieb Jason A. Donenfeld: > Hi Mathias, > > Sorry for the delay in reviewing these. Thanks for that. I've merged > them with a trivial change. thanks! > The constraint one is interesting; it > looks like with your change and those extra constraints it winds up > spilling rdi to the stack? Indeed, looking, for example, at fsquare_times() (!RAP, FRAMEPOINTER=y), it looks like gcc prefers to choose the constraint with a memory output argument even if it could fulfill the register allocation request, i.e. it could allocate (all remaining) 3 registers instead of only 2 but chooses to do the latter nonetheless. However, for me it's %rsi that's put on the stack. Also it's not spilled, but used as a variable -- the stack frame increases by 8 bytes and the stack slot where %rsi is written to is used as-is for operations in the end. But, again, this differs from the original code that used to allocate three registers for the inline assembly. The old code has two memory loads at the end and one compare while the new one has only one -- directly encode into the compare instruction. So, memory-wise, a net win? Below is the diff of the disassembly of fsquare_times(), spare of addresses to reduce clutter with comments below each hunk: --- old.dis 2021-08-09 11:46:53.050680456 +0200 +++ new.dis 2021-08-09 11:48:18.816851059 +0200 @@ -6,10 +6,10 @@ push %r13 push %r12 push %rbx - sub $0x18,%rsp - mov %rdi,-0x38(%rbp) - mov %rdx,-0x40(%rbp) - mov %ecx,-0x2c(%rbp) + sub $0x20,%rsp + mov %rdi,-0x40(%rbp) + mov %rdx,-0x48(%rbp) + mov %ecx,-0x30(%rbp) mov %rdx,%r12 mov (%rsi),%rdx mulx 0x8(%rsi),%r8,%r14 This first hunk is really only the increased stack frame and resulting offset changes. @@ -92,15 +92,14 @@ cmovb %rdx,%rax add %rax,%r8 mov %r8,(%r12) - mov -0x2c(%rbp),%eax + mov -0x30(%rbp),%eax sub $0x1,%eax - mov %eax,-0x30(%rbp) - je 1f42 + mov %eax,-0x34(%rbp) + je 1f3c xor %r12d,%r12d - mov %r12d,-0x2c(%rbp) <-- no longer needed in new code - mov -0x38(%rbp),%rsi - mov -0x40(%rbp),%rdi - mov %rsi,%r12 <-- see below + mov -0x40(%rbp),%rsi + mov -0x48(%rbp),%rdi + mov %rsi,-0x30(%rbp) <-- reg -> mem operand constraint mov (%rsi),%rdx mulx 0x8(%rsi),%r8,%r14 xor %r15,%r15 Offset changes again. Beside the one dropped instruction there's only one real change ("mov %rsi,%r12" -> "mov %rsi,-0x30(%rbp)"), induced by the memory constraint of the inline assembly, switching a register operand to a memory location. @@ -154,7 +153,7 @@ adcx %rcx,%r14 mov %r14,0x38(%rdi) mov %rdi,%rsi - mov %r12,%rdi + mov -0x30(%rbp),%rdi mov $0x26,%rdx mulx 0x20(%rsi),%r8,%r13 xor %rcx,%rcx Load of the stack slot which used to be a register operation before. @@ -182,12 +181,10 @@ cmovb %rdx,%rax add %rax,%r8 mov %r8,(%rdi) - addl $0x1,-0x2c(%rbp) <-- mem operation - mov -0x30(%rbp),%ebx <-- mem load - mov -0x2c(%rbp),%eax <-- mem load - cmp %ebx,%eax <-- reg compare - jne 1d83 - add $0x18,%rsp + add $0x1,%r12d <-- reg operation + cmp -0x34(%rbp),%r12d <-- mem compare + jne 1d7f + add $0x20,%rsp pop %rbx pop %r12 pop %r13 We switch one memory operation (addl) to a register one and spare the memory loads for the compare by directly encoding one of the memory operands into the compare instruction. IMHO a net win, as gcc now can use a register for the loop condition variable, making the conditional jump depend only on one memory operand, not two. But only a benchmark can tell if it's really faster or even slower. Thanks, Mathias From nico.schottelius at ungleich.ch Mon Aug 9 12:34:43 2021 From: nico.schottelius at ungleich.ch (Nico Schottelius) Date: Mon, 09 Aug 2021 14:34:43 +0200 Subject: Wireguard as a Kubernetes Service Message-ID: <87sfzire3g.fsf@ungleich.ch> Hello dear WG mailing list, I am interested in running wireguard servers (as in endpoints) inside a kubernetes cluster. I have two different approaches and was wondering what makes more sense: 1) Wireguard in kernel on every participating node Assuming that the kernel module is loaded on the host and that a k8s pod just sets the VPN configuration, every node that hosts the wireguard service would need to be configured. Given that a pod is privileged, this might work with a single instance service that is only terminated on one node. I assume the usual roaming problems apply so that only 1 node could host that service. One problem I see here is that the host will have fragments left, even if the pod is moved to another node. This might be able to catch using finalizers. The biggest "problem" I see is that the actual node becomes the VPN endpoint and not really the pod. 2) User space client Is there still any Linux user space client that could be used instead? Performance is not the most critical point of running wireguard as a service inside k8s, but more the ease of maintenance. I see these two options, does anyone have a better idea on how to move the vpn endpoints into a k8s cluster? Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch From trevp at trevp.net Tue Aug 10 00:09:58 2021 From: trevp at trevp.net (Trevor Perrin) Date: Mon, 9 Aug 2021 17:09:58 -0700 Subject: another thread on montonic counter alternatives In-Reply-To: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> References: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Message-ID: On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner wrote: > > 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. That could be deployed in a backwards-compatible way, I think? If the client's V1 handshake is rejected due to an old timestamp, the client is given the cookie which enables it to do the V2 handshake? > Jason pointed out, that it would be preferable to use a Noise-XK handshake which is a standard fully-interactive handshake but 1.5-RTT. I was assuming 1-RTT-ness was a necessity. > Of course, coming up with a new handshake is?generally foolish and even though both my proposal technially fit into the noise-IK pattern, noise-XK certainly is more trustworthy. I thought the goal of IK here was: server only stores state if client is authenticated. And the goal of timestamp was: replayed messages can't invalidate an existing session state. If those are still the requirements I'm not sure that XK meets them. XK has better identity hiding (only reveals the client's identity after forward-secrecy is negotiated), but that trades off against the requirement that unauthenticated clients can't cause servers to store state. (Unless you put the state in a cookie, I suppose - which you also suggested...) Trevor From stephen at slarew.net Mon Aug 9 16:12:05 2021 From: stephen at slarew.net (Stephen Larew) Date: Mon, 9 Aug 2021 09:12:05 -0700 Subject: Mac APP DNS Search Domain In-Reply-To: <20210717100909.lzi5mwsv5hb57w3w@svensmacbookair.sven.lan> References: <20210717100909.lzi5mwsv5hb57w3w@svensmacbookair.sven.lan> Message-ID: On Jul 17, 2021, at 03:09, Sven Auhagen wrote: > > Hi, > > the DNS search domain in the Wireguard Mac APP does not seem to work properly. > The search domain is added properly and I can see it in the DNS configuration > for the scoped query: > > resolver #2 > search domain[0] : mytestdomain.com > nameserver[0] : 192.168.6.1 > if_index : 17 (utun4) > flags : Scoped, Request A records > reach : 0x00000002 (Reachable) > > but the global resolver is using a mix of my LAN and Wireguard DNS resolver: > > resolver #1 > search domain[0] : sven.lan > nameserver[0] : 192.168.6.1 > if_index : 17 (utun4) > flags : Supplemental, Request A records > reach : 0x00000002 (Reachable) > order : 102200 > > I found a discussion on Github about the issue here: > https://github.com/tailscale/tailscale/issues/101#issuecomment-639286398 > > suggesting that the following will fix it: > > --- a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift > +++ b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift > @@ -88,7 +88,7 @@ class PacketTunnelSettingsGenerator { > let dnsSettings = NEDNSSettings(servers: dnsServerStrings) > dnsSettings.searchDomains = tunnelConfiguration.interface.dnsSearch > if !tunnelConfiguration.interface.dns.isEmpty { > - dnsSettings.matchDomains = [""] // All DNS queries must first go through the tunnel's DNS > + dnsSettings.matchDomains = [""] + dnsSettings.searchDomains // All DNS queries must first go through the tunnel's DNS > } > networkSettings.dnsSettings = dnsSettings > } > > I do not have an Apple Developer Account so I am not able to compile the code and test it. > Can anyone take a look as this would be a great help. > > Best > Sven Sven, I have a patch for Wireguard Mac app that enables proper split DNS support. It works well in my usage. I should properly submit the patch for review by Wireguard folks. Until then, you can get the patch here: https://github.com/slarew/wireguard-apple/commit/6ebc356d9e11ab91443e06de5e89f1af57fcdff8 > Enable "split DNS" configurations for an interface > > By adding a tilde prefix to a domain name entry in the DNS= line, the > domain is interpreted as a "matching domain" for DNS routing instead of > a "search domain." This corresponds to setting a non-empty > NEDNSSettings.matchDomains property for the network tunnel. Using tilde > as a prefix is borrowed from systemd-resolved's equivalent usage. > > If one or more match domains are specified, then the specified DNS > resolvers are only used for those matching domains instead of acting as > the first resolver before the system's primary DNS resolvers. -Stephen From sven.auhagen at voleatech.de Tue Aug 10 07:42:32 2021 From: sven.auhagen at voleatech.de (Sven Auhagen) Date: Tue, 10 Aug 2021 08:42:32 +0100 Subject: Mac APP DNS Search Domain In-Reply-To: References: <20210717100909.lzi5mwsv5hb57w3w@svensmacbookair.sven.lan> Message-ID: <20210810074232.aah5ktq5yzysaaey@SvensMacBookAir-2.local> On Mon, Aug 09, 2021 at 09:12:05AM -0700, Stephen Larew wrote: > On Jul 17, 2021, at 03:09, Sven Auhagen wrote: > > > > Hi, > > > > the DNS search domain in the Wireguard Mac APP does not seem to work properly. > > The search domain is added properly and I can see it in the DNS configuration > > for the scoped query: > > > > resolver #2 > > search domain[0] : mytestdomain.com > > nameserver[0] : 192.168.6.1 > > if_index : 17 (utun4) > > flags : Scoped, Request A records > > reach : 0x00000002 (Reachable) > > > > but the global resolver is using a mix of my LAN and Wireguard DNS resolver: > > > > resolver #1 > > search domain[0] : sven.lan > > nameserver[0] : 192.168.6.1 > > if_index : 17 (utun4) > > flags : Supplemental, Request A records > > reach : 0x00000002 (Reachable) > > order : 102200 > > > > I found a discussion on Github about the issue here: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftailscale%2Ftailscale%2Fissues%2F101%23issuecomment-639286398&data=04%7C01%7Csven.auhagen%40voleatech.de%7Cc036b74b5f804c3ae41708d95b50700e%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637641223312894873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=m59kt6gpqykdVvvyUX4%2BEbF14sCZWfmrZNWEKNzXj3E%3D&reserved=0 > > > > suggesting that the following will fix it: > > > > --- a/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift > > +++ b/Sources/WireGuardKit/PacketTunnelSettingsGenerator.swift > > @@ -88,7 +88,7 @@ class PacketTunnelSettingsGenerator { > > let dnsSettings = NEDNSSettings(servers: dnsServerStrings) > > dnsSettings.searchDomains = tunnelConfiguration.interface.dnsSearch > > if !tunnelConfiguration.interface.dns.isEmpty { > > - dnsSettings.matchDomains = [""] // All DNS queries must first go through the tunnel's DNS > > + dnsSettings.matchDomains = [""] + dnsSettings.searchDomains // All DNS queries must first go through the tunnel's DNS > > } > > networkSettings.dnsSettings = dnsSettings > > } > > > > I do not have an Apple Developer Account so I am not able to compile the code and test it. > > Can anyone take a look as this would be a great help. > > > > Best > > Sven > > Sven, > > I have a patch for Wireguard Mac app that enables proper split DNS support. It works well in my usage. I should properly submit the patch for review by Wireguard folks. Until then, you can get the patch here: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fslarew%2Fwireguard-apple%2Fcommit%2F6ebc356d9e11ab91443e06de5e89f1af57fcdff8&data=04%7C01%7Csven.auhagen%40voleatech.de%7Cc036b74b5f804c3ae41708d95b50700e%7Cb82a99f679814a7295344d35298f847b%7C0%7C1%7C637641223312894873%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=dd9MYi3CkgveF%2BcBAU1sk857lDeLmX2SpMcRy7tL9nM%3D&reserved=0 > > > Enable "split DNS" configurations for an interface > > > > By adding a tilde prefix to a domain name entry in the DNS= line, the > > domain is interpreted as a "matching domain" for DNS routing instead of > > a "search domain." This corresponds to setting a non-empty > > NEDNSSettings.matchDomains property for the network tunnel. Using tilde > > as a prefix is borrowed from systemd-resolved's equivalent usage. > > > > If one or more match domains are specified, then the specified DNS > > resolvers are only used for those matching domains instead of acting as > > the first resolver before the system's primary DNS resolvers. Thanks Stephen. It would be great if you can upstream the patch. The current behaviour is a problem for non technical users that rely on the short dns names. Best Sven > > -Stephen Beste Gr??e/Best regards Sven Auhagen Dipl. Math. oec., M.Sc. Voleatech GmbH HRB: B 754643 USTID: DE303643180 Grathwohlstr. 5 72762 Reutlingen Tel: +49 7121539550 Fax: +49 71215395599 E-Mail: sven.auhagen at voleatech.de www.voleatech.de [https://www.voleatech.de/wp-content/uploads/2021/03/vtair-emailbanner-enterprise.jpg] Diese Information ist ausschlie?lich f?r den Adressaten bestimmt und kann vertraulich oder gesetzlich gesch?tzte Informationen enthalten. Wenn Sie nicht der bestimmungsgem??e Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgem??en Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. F?r den Adressaten sind die Informationen in dieser Mail nur zum pers?nlichen Gebrauch. Eine Weiterleitung darf nur nach R?cksprache mit dem Absender erfolgen. Wir verwenden aktuelle Virenschutzprogramme. F?r Sch?den, die dem Empf?nger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schlie?en wir jede Haftung aus. From karo at cupdev.net Tue Aug 10 07:53:40 2021 From: karo at cupdev.net (Karolin Varner) Date: Tue, 10 Aug 2021 09:53:40 +0200 Subject: another thread on montonic counter alternatives In-Reply-To: References: <6cd87006-902a-3411-4928-67ec5d1f77e2@cupdev.net> Message-ID: <4aea0fd6-a37e-3cf5-8df8-79ef119adff6@cupdev.net> On 8/10/21 2:09 AM, Trevor Perrin wrote: > On Sun, Aug 8, 2021 at 5:04 PM Karolin Varner wrote: >> >> 2) Fall back to an interactive handshake using cookies. Define a protocol version two, mandate that in V2 the cookie must be mixed into the handshake hash. Assign a cookie in case of timestamp failure. > > That could be deployed in a backwards-compatible way, I think? If the > client's V1 handshake is rejected due to an old timestamp, the client > is given the cookie which enables it to do the V2 handshake? Yes! I was thinking InitHello with a flag set in the reserved bytes, peer responds with cookie and a compatibility flag set as well. The flag would be ignored by legacy responders, these would also respond with the flag set to zero in cookie replies so the initiator knows not to use V2 when resending InitHello with a cookie. Peers generating messages without a cookie should skip the cookie mixing step (not mix {0}^n) so the message can be processed by legacy peers and modern ones alike. There may be non-standard implementations which assert the reserved bytes to be {0}^3, so sending a one-time-counter using an entirely new packet type might be even more compatible. Such a message would be entirely ignored by all but the worst implementations. Karolin From dotneutron at protonmail.ch Tue Aug 10 20:29:52 2021 From: dotneutron at protonmail.ch (dotneutron) Date: Tue, 10 Aug 2021 20:29:52 +0000 Subject: [PATCH] embeddable-dll-service: add ability to derive public key from private key Message-ID: <20210810202936.1537-1-dotneutron@protonmail.ch> Developers using the embeddable service might find it useful to be able to derive the public key from a given private key. There was no apparent explanation for the bit setting/unsetting when generating a private key. The reading material should help developers understand the reasoning. Signed-off-by: Neutron --- embeddable-dll-service/main.go | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/embeddable-dll-service/main.go b/embeddable-dll-service/main.go index b2e02fa4..a9b9dacd 100644 --- a/embeddable-dll-service/main.go +++ b/embeddable-dll-service/main.go @@ -53,10 +53,20 @@ func WireGuardGenerateKeypair(publicKey *byte, privateKey *byte) { if err != nil || n != len(privateKeyArray) { panic("Unable to generate random bytes") } + + // See https://www.jcraige.com/an-explainer-on-ed25519-clamping. privateKeyArray[0] &= 248 privateKeyArray[31] = (privateKeyArray[31] & 127) | 64 curve25519.ScalarBaseMult(publicKeyArray, privateKeyArray) } +//export WireGuardDerivePublicKeyFromPrivateKey +func WireGuardDerivePublicKeyFromPrivateKey(publicKey *byte, privateKey *byte) { + publicKeyArray := (*[32]byte)(unsafe.Pointer(publicKey)) + privateKeyArray := (*[32]byte)(unsafe.Pointer(privateKey)) + + curve25519.ScalarBaseMult(publicKeyArray, privateKeyArray) +} + func main() {} -- 2.32.0.windows.2 From Jason at zx2c4.com Tue Aug 10 20:38:19 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 10 Aug 2021 22:38:19 +0200 Subject: [PATCH] embeddable-dll-service: add ability to derive public key from private key In-Reply-To: <20210810202936.1537-1-dotneutron@protonmail.ch> References: <20210810202936.1537-1-dotneutron@protonmail.ch> Message-ID: Hi, Why do you want this functionality in the tunnel.dll? What are you doing that would require it? Jason From dotneutron at protonmail.ch Tue Aug 10 21:13:06 2021 From: dotneutron at protonmail.ch (Neutron) Date: Tue, 10 Aug 2021 21:13:06 +0000 Subject: [PATCH] embeddable-dll-service: add ability to derive public key from private key In-Reply-To: References: <20210810202936.1537-1-dotneutron@protonmail.ch> Message-ID: <7-v7jwwWMXai6l5Uqxgo8UjeuKNOvY2FDx4rsGB1yrAHkfDqrGGfoLOIHQuJuTBJ0HIpmxlqTTFJgWqbGDn5eFT-7bLT8D60enB3pVrc-2o=@protonmail.ch> Hey, I started working on a C# WPF client based on the reference implementation you provided. I made it so the tunnel configurations can be added or edited via a custom form much alike the one of wg-android. Since I'm only storing the private key in the interface section of a config file, I need to be able to derive the public key and display it to the user. As a personal example, I'm using Mullvad's wg configurations to test it. I'm able to export all configurations for their servers, for a given private key. I'm left with the typical wg conf files. When I fill in the details for a tunnel configuration in the client I created, I want to be able to write in the private key and have it generate the public key automatically. This is the behavior of wg-android. Adding that method, rebuilding the dll and invoking it from C# worked like a charm, so I thought it might help other people as well. It is a convenience method for anyone who wants to create a client of their own. Neutron From wireguard at ka-fi.de Thu Aug 12 12:23:24 2021 From: wireguard at ka-fi.de (Kai Fischer) Date: Thu, 12 Aug 2021 12:23:24 +0000 Subject: Wireguard Android is not working since Android 12 Beta 4 (Pixel 5) Message-ID: I'm not sure if this is a issue on the system side or on the apllication side. Since the newest Android 12 Beta 4 Wireguard is establishing a connection but not data transfer is possible. A ping to the host is also not possible. There's an offical issue here at the Google Issuetracker: https://issuetracker.google.com/issues/196271165 This seems to be an issue with a lot of VPN apps . I don't know if it can be fixed on the application side. From Jason at zx2c4.com Fri Aug 13 11:52:39 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 13 Aug 2021 13:52:39 +0200 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: Hi everyone, On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld 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. Jason From hendrik at friedels.name Fri Aug 13 15:58:18 2021 From: hendrik at friedels.name (Hendrik Friedel) Date: Fri, 13 Aug 2021 15:58:18 +0000 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: Hello Jason, thanks for your work on Wireguard. I have just updated and activated the experimental driver. The fact that I do not need to activate it in the registry was decisive for me ;-) I cannot report any issue so far. Best regards, Hendrik ------ Originalnachricht ------ Von: "Jason A. Donenfeld" An: "WireGuard mailing list" Gesendet: 13.08.2021 13:52:39 Betreff: Re: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel >Hi everyone, > >On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld 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. > >Jason From peter.whisker at gmail.com Fri Aug 13 16:09:06 2021 From: peter.whisker at gmail.com (Peter Whisker) Date: Fri, 13 Aug 2021 17:09:06 +0100 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: <1b9f3d3f-e630-a640-af85-47bf732cbe0b@gmail.com> Hi I've been using it daily since 0.4.0 on a laptop and two servers in a mixed Linux/WNT/FreeBSD (pfsense) environment. Since 0.4.1 it has worked perfectly for me. Thanks for the effort. The tunnel is subjectively snappier than the pure Go implementation. Best wishes Peter Whisker On 13/08/2021 12:52, Jason A. Donenfeld wrote: > Hi everyone, > > On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld 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. > > Jason From lukasluedke at web.de Fri Aug 13 22:02:44 2021 From: lukasluedke at web.de (=?UTF-8?Q?Lukas_L=c3=bcdke?=) Date: Sat, 14 Aug 2021 00:02:44 +0200 Subject: Problem using "WireGuardSetConfiguration" for Wireguard-NT with heap allocated configuration Message-ID: Hello, I am trying to implement a custom wireguard client using the provided wireguard.dll/wireguard.h in c++. I tried to modify the example from here: https://git.zx2c4.com/wireguard-nt/tree/example/example.c It works, when I specify a struct with one interface (WIREGUARD_INTERFACE) and one or more peers + allowed ips (WIREGUARD_PEER, WIREGUARD_ALLOWED_IP) and then use "WireGuardSetConfiguration" to the the configuration on the adapter, like it the example. But when I try to use a buffer allocated on the heap, containing the interface and the peers + allowed_ips, I always get error 0x57 from "WireGuardSetConfiguration". It seems to work, when I only create the buffer and memcpy a WIREGUARD_INTERFACE object into the buffer, but if I create a larger buffer and also memcpy the WIREGUARD_PEER object into it, set the Flags and set the PeersCount, I get the error. like in the following example it does not work: unsigned char* buffer = (unsigned char *)malloc(sizeof(WIREGUARD_INTERFACE) + sizeof(WIREGUARD_PEER)); /*new_interface is the interface from the example.c file*/ new_interface.PeersCount = 1; memcpy(buffer, &new_interface, sizeof(WIREGUARD_INTERFACE)); unsigned char* buffer2 = (buffer + sizeof(WIREGUARD_INTERFACE)); /*peer is a created peer, which does work, if I use it in a struct*/ memcpy(buffer2, &peer, sizeof(WIREGUARD_PEER)); if (!WireGuardSetConfiguration(Adapter, (WIREGUARD_INTERFACE *)&(buffer), sizeof(struct t))) { ??? LastError = LogError(L"Failed to set configuration", GetLastError()); ??? return cleanupAdapter(Adapter, WireGuard, LastError); } Does anyone has an idea, how I can implement this correctly, so that I can dynamically add/remove the peers and I am not forced to create a struct with fixed peer count? Best Regards, Lukas From Jason at zx2c4.com Fri Aug 13 22:19:55 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 14 Aug 2021 00:19:55 +0200 Subject: Problem using "WireGuardSetConfiguration" for Wireguard-NT with heap allocated configuration In-Reply-To: References: Message-ID: Hi Lukas, This appears to be a C pointer snafu, with this line in the code you sent: > if (!WireGuardSetConfiguration(Adapter, (WIREGUARD_INTERFACE*)&(buffer), sizeof(struct t))) { The issue is that `buffer` is already a pointer to the malloc'd memory, so passing &buffer is actually the address of the pointer that points to the memory you want. The reason why the example.c code passes "&thing" and not "thing" is because thing is on the stack. But in your case, `buffer` is on the heap, so it's already a pointer. The second thing that stands out is `sizeof(struct t)` might not be what you want. Instead try providing as length the same length that you passed to the malloc call -- sizeof(iface)+sizeof(peer). Hope that helps. Jason From dotneutron at protonmail.ch Sat Aug 14 05:13:54 2021 From: dotneutron at protonmail.ch (dotneutron) Date: Sat, 14 Aug 2021 05:13:54 +0000 Subject: [PATCH] embeddable-dll-service: csharp: fix peer endpoint bug Message-ID: <20210814051340.485-1-dotneutron@protonmail.ch> ADDRESS_FAMILY is a typedef for USHORT. ioctlPeer->Endpoint.si_family evaluates to 1882324994 instead of AF_INET when enum ADDRESS_FAMILY inherits from UInt32 instead of ushort/UInt16. IPAddress#NetworkToHostOrder does not have an overload for ushort and int is chosen instead. This does not play well - e.g., NetworkToHostOrder(28722) evaluates to 846200832. An extension method is proposed to solve this issue. Signed-off-by: Neutron --- .../csharp/Extensions/NumberExtensions.cs | 14 ++++++++++++++ embeddable-dll-service/csharp/TunnelDll/Driver.cs | 9 +++++---- embeddable-dll-service/csharp/TunnelDll/Win32.cs | 2 +- 3 files changed, 20 insertions(+), 5 deletions(-) create mode 100644 embeddable-dll-service/csharp/Extensions/NumberExtensions.cs diff --git a/embeddable-dll-service/csharp/Extensions/NumberExtensions.cs b/embeddable-dll-service/csharp/Extensions/NumberExtensions.cs new file mode 100644 index 00000000..dfa2f981 --- /dev/null +++ b/embeddable-dll-service/csharp/Extensions/NumberExtensions.cs @@ -0,0 +1,14 @@ +?using System; + +namespace DemoUI.Extensions +{ + public static class NumberExtensions + { + public static ushort ConvertFromNetworkToHostOrder(this ushort value) + { + var bytes = BitConverter.GetBytes(value); + Array.Reverse(bytes); + return BitConverter.ToUInt16(bytes); + } + } +} diff --git a/embeddable-dll-service/csharp/TunnelDll/Driver.cs b/embeddable-dll-service/csharp/TunnelDll/Driver.cs index 857d6a63..d630c6df 100644 --- a/embeddable-dll-service/csharp/TunnelDll/Driver.cs +++ b/embeddable-dll-service/csharp/TunnelDll/Driver.cs @@ -7,6 +7,7 @@ using System; using System.ComponentModel; using System.Net; using System.Runtime.InteropServices; +using DemoUI.Extensions; namespace Tunnel { @@ -73,14 +74,14 @@ namespace Tunnel if (ioctlPeer->Endpoint.si_family == Win32.ADDRESS_FAMILY.AF_INET) { var ip = new byte[4]; - Marshal.Copy((IntPtr)ioctlPeer->Endpoint.Ipv4.sin_addr.bytes, ip, 0, 4); - peer.Endpoint = new IPEndPoint(new IPAddress(ip), IPAddress.NetworkToHostOrder(ioctlPeer->Endpoint.Ipv4.sin_port)); + Marshal.Copy((IntPtr)ioctlPeer->Endpoint.Ipv4.sin_addr.bytes, ip, 0, ip.Length); + peer.Endpoint = new IPEndPoint(new IPAddress(ip), ioctlPeer->Endpoint.Ipv4.sin_port.ConvertFromNetworkToHostOrder()); } else if (ioctlPeer->Endpoint.si_family == Win32.ADDRESS_FAMILY.AF_INET6) { var ip = new byte[16]; - Marshal.Copy((IntPtr)ioctlPeer->Endpoint.Ipv6.sin6_addr.bytes, ip, 0, 16); - peer.Endpoint = new IPEndPoint(new IPAddress(ip), IPAddress.NetworkToHostOrder(ioctlPeer->Endpoint.Ipv6.sin6_port)); + Marshal.Copy((IntPtr)ioctlPeer->Endpoint.Ipv6.sin6_addr.bytes, ip, 0, ip.Length); + peer.Endpoint = new IPEndPoint(new IPAddress(ip), ioctlPeer->Endpoint.Ipv6.sin6_port.ConvertFromNetworkToHostOrder()); } } peer.TxBytes = ioctlPeer->TxBytes; diff --git a/embeddable-dll-service/csharp/TunnelDll/Win32.cs b/embeddable-dll-service/csharp/TunnelDll/Win32.cs index 4987fe8f..b4084ccf 100644 --- a/embeddable-dll-service/csharp/TunnelDll/Win32.cs +++ b/embeddable-dll-service/csharp/TunnelDll/Win32.cs @@ -180,7 +180,7 @@ namespace Tunnel public ADDRESS_FAMILY si_family; } - public enum ADDRESS_FAMILY : UInt32 + public enum ADDRESS_FAMILY : UInt16 { AF_UNSPEC = 0, AF_INET = 2, -- 2.32.0.windows.2 From Jason at zx2c4.com Sat Aug 14 10:18:21 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Sat, 14 Aug 2021 12:18:21 +0200 Subject: [PATCH] embeddable-dll-service: csharp: fix peer endpoint bug In-Reply-To: <20210814051340.485-1-dotneutron@protonmail.ch> References: <20210814051340.485-1-dotneutron@protonmail.ch> Message-ID: Hi Neutron, Thanks for the report. I fixed this slightly differently here: https://git.zx2c4.com/wireguard-windows/commit/?id=0ab19b6a457b672bdb613b4c92d9786a48edd605 Note that I would have given a review to your patch instead of fixing myself, but I can't actually accept patches from you because your Signed-off-by doesn't specify your name, per the notes here https://www.kernel.org/doc/html/v4.11/process/submitting-patches.html#developer-s-certificate-of-origin-1-1 . WireGuard tries to stay decently close to Linux kernel guidelines. Jason From phillip.mcmahon at gmail.com Sat Aug 14 11:03:28 2021 From: phillip.mcmahon at gmail.com (Phillip McMahon) Date: Sat, 14 Aug 2021 13:03:28 +0200 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: I've been testing the experimental driver since the first announcement but no issues to date. On Fri, 13 Aug 2021 at 13:57, Jason A. Donenfeld wrote: > > Hi everyone, > > On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld 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. > > Jason -- Phillip McMahon https://flowcrypt.com/me/phillipmcmahon OpenPGP: EA04 83D4 C864 AA7C 1099 4BE6 A11E 70AD FDA6 0CF9 From mc at mc.cx Sat Aug 14 21:37:15 2021 From: mc at mc.cx (Morten Christensen) Date: Sat, 14 Aug 2021 23:37:15 +0200 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: <3e525055-4170-e893-795f-1c5ec51cdb52@g.mc.cx> Den 13-08-2021 kl. 13:52 skrev Jason A. Donenfeld: I have used it since first announcement. Not experienced any problems. -- Morten Christensen > Hi everyone, > > On Mon, Aug 2, 2021 at 7:28 PM Jason A. Donenfeld 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. > > Jason From nomad at null.net Mon Aug 16 08:15:49 2021 From: nomad at null.net (nomad at null.net) Date: Mon, 16 Aug 2021 10:15:49 +0200 Subject: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel In-Reply-To: References: Message-ID: <20210816081549.GA17757@b.rekudos.net> On Fri Aug 13, 2021 at 01:52:39PM +0200, Jason A. Donenfeld wrote: >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. No issues on Windows 8.1 so far, using the NT kernel version from 0.4.5. -- Mark Lawrence From kasper93 at gmail.com Mon Aug 16 18:59:46 2021 From: kasper93 at gmail.com (Kacper Michajlow) Date: Mon, 16 Aug 2021 20:59:46 +0200 Subject: [wireguard-windows] Microsoft Store doesn't work when killswitch is enabled. Message-ID: Hi, I noticed an issue with Microsoft Store when Wiregaurd tunnel is connected. When "killswitch" is enabled, MS Store doesn't work, it says that "page could not be loaded". After some troubleshooting it looks like the connection is dropped by the firewall (I see it in logs). Source is my wg ip, destination is some akamai server, looks legit, but it is dropped (both IPv4 and IPv6). Do you have any idea why? Everything else works correctly. Is it some UWP app quirk? If I disable "killswitch", traffic goes through the wg tunnel and MS Store works, so it looks like the firewall shouldn't drop this connection, when killswitch is enabled. I searched for similar issues and only found this one https://github.com/mullvad/mullvadvpn-app/issues/2845 looks like the same symptoms and the guy reported that it works in Windows 11. Regardless I would like to understand what is happening, maybe you guys have more insight. Best Regards, Kacper From waishon009 at gmail.com Mon Aug 16 22:19:31 2021 From: waishon009 at gmail.com (Waishon) Date: Tue, 17 Aug 2021 00:19:31 +0200 Subject: Domain as endpoint when using wireguard with network namespaces Message-ID: Hey there, I'm currently trying to setup a wireguard-tunnel inside a network-namespace as descriped in the documentation, which fails when using a domain as endpoint: https://www.wireguard.com/netns/ First I've created the wireguard interface inside the birth-namespace of the host using "ip link add wg0 type wireguard". Then I moved the wg0 interface to the newly created network namespace, which doesn't have any network interfaces and network connections beside the loopback interface. Then I configured the wg0 interface inside the network namespace using wg set "INTERFACE_NAME" \ private-key References: Message-ID: <03667268-5415-4FB0-9D4B-1E51466A3F5C@tomcsanyi.net> I am sorry, but I need to ask: if your namespace does not have an internet connection how would you connect to your remote endpoint after the DNS lookup issue is solved and you received the IP behind vpn.example.com? Kind regards, Domi > 17.08.2021 d?tummal, 23:06 id?pontban Waishon ?rta: > > ?Hey there, > > I'm currently trying to setup a wireguard-tunnel inside a > network-namespace as descriped in the documentation, which fails when > using a domain as endpoint: > https://www.wireguard.com/netns/ > > First I've created the wireguard interface inside the birth-namespace > of the host using "ip link add wg0 type wireguard". Then I moved the > wg0 interface to the newly created network namespace, which doesn't > have any network interfaces and network connections beside the > loopback interface. > > Then I configured the wg0 interface inside the network namespace using > wg set "INTERFACE_NAME" \ > private-key peer "PEER" \ > endpoint vpn.example.com:51820 \ > persistent-keepalive 25 \ > allowed-ips ::/0 > > This however results in a "Temporary failure in name resolution: > `vpn.example.com:51820'. Trying again in 1.00 seconds..." error > message, which makes sense, because the wireguard-tool tries to call > getaddrinfo inside the network namespace. The namespace doesn't have > an internet connection and the lookup fails. > https://github.com/WireGuard/wireguard-tools/blob/96e42feb3f41e2161141d4958e2637d9dee6f90a/src/config.c#L242 > > As a user I would expect that the wg-tool does the lookup in the > birth-namespace of the interface and not inside the newly created > network namespace. > > What is the recommended solution to resolve an domain endpoint when > using network namespaces and wireguard? Just manually lookup the > domain in the birth-namespace and use the ip as endpoint? The > implementation however would be quiete hacky to make it properly work > with IPv4 and IPv6. From keescook at chromium.org Wed Aug 18 06:04:37 2021 From: keescook at chromium.org (Kees Cook) Date: Tue, 17 Aug 2021 23:04:37 -0700 Subject: [PATCH v2 07/63] skbuff: Switch structure bounds to struct_group() In-Reply-To: <20210818060533.3569517-1-keescook@chromium.org> References: <20210818060533.3569517-1-keescook@chromium.org> Message-ID: <20210818060533.3569517-8-keescook@chromium.org> In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memcpy(), memmove(), and memset(), avoid intentionally writing across neighboring fields. Replace the existing empty member position markers "headers_start" and "headers_end" with a struct_group(). This will allow memcpy() and sizeof() to more easily reason about sizes, and improve readability. "pahole" shows no size nor member offset changes to struct sk_buff. "objdump -d" shows no object code changes (outside of WARNs affected by source line number changes). Cc: "Jason A. Donenfeld" Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Jonathan Lemon Cc: Alexander Lobakin Cc: Jakub Sitnicki Cc: Marco Elver Cc: Willem de Bruijn Cc: wireguard at lists.zx2c4.com Cc: netdev at vger.kernel.org Signed-off-by: Kees Cook Reviewed-by: Gustavo A. R. Silva Link: https://lore.kernel.org/lkml/20210728035006.GD35706 at embeddedor --- drivers/net/wireguard/queueing.h | 4 +--- include/linux/skbuff.h | 9 ++++----- net/core/skbuff.c | 14 +++++--------- 3 files changed, 10 insertions(+), 17 deletions(-) diff --git a/drivers/net/wireguard/queueing.h b/drivers/net/wireguard/queueing.h index 4ef2944a68bc..52da5e963003 100644 --- a/drivers/net/wireguard/queueing.h +++ b/drivers/net/wireguard/queueing.h @@ -79,9 +79,7 @@ static inline void wg_reset_packet(struct sk_buff *skb, bool encapsulating) u8 sw_hash = skb->sw_hash; u32 hash = skb->hash; skb_scrub_packet(skb, true); - memset(&skb->headers_start, 0, - offsetof(struct sk_buff, headers_end) - - offsetof(struct sk_buff, headers_start)); + memset(&skb->headers, 0, sizeof(skb->headers)); if (encapsulating) { skb->l4_hash = l4_hash; skb->sw_hash = sw_hash; diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h index 6bdb0db3e825..fee9041aa402 100644 --- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -801,11 +801,10 @@ struct sk_buff { __u8 active_extensions; #endif - /* fields enclosed in headers_start/headers_end are copied + /* Fields enclosed in headers group are copied * using a single memcpy() in __copy_skb_header() */ - /* private: */ - __u32 headers_start[0]; + struct_group(headers, /* public: */ /* if you move pkt_type around you also must adapt those constants */ @@ -922,8 +921,8 @@ struct sk_buff { u64 kcov_handle; #endif - /* private: */ - __u32 headers_end[0]; + ); /* end headers group */ + /* public: */ /* These elements must be at the end, see alloc_skb() for details. */ diff --git a/net/core/skbuff.c b/net/core/skbuff.c index f9311762cc47..fd5ce57ccce6 100644 --- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -991,12 +991,10 @@ void napi_consume_skb(struct sk_buff *skb, int budget) } EXPORT_SYMBOL(napi_consume_skb); -/* Make sure a field is enclosed inside headers_start/headers_end section */ +/* Make sure a field is contained by headers group */ #define CHECK_SKB_FIELD(field) \ - BUILD_BUG_ON(offsetof(struct sk_buff, field) < \ - offsetof(struct sk_buff, headers_start)); \ - BUILD_BUG_ON(offsetof(struct sk_buff, field) > \ - offsetof(struct sk_buff, headers_end)); \ + BUILD_BUG_ON(offsetof(struct sk_buff, field) != \ + offsetof(struct sk_buff, headers.field)); \ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old) { @@ -1008,14 +1006,12 @@ static void __copy_skb_header(struct sk_buff *new, const struct sk_buff *old) __skb_ext_copy(new, old); __nf_copy(new, old, false); - /* Note : this field could be in headers_start/headers_end section + /* Note : this field could be in the headers group. * It is not yet because we do not want to have a 16 bit hole */ new->queue_mapping = old->queue_mapping; - memcpy(&new->headers_start, &old->headers_start, - offsetof(struct sk_buff, headers_end) - - offsetof(struct sk_buff, headers_start)); + memcpy(&new->headers, &old->headers, sizeof(new->headers)); CHECK_SKB_FIELD(protocol); CHECK_SKB_FIELD(csum); CHECK_SKB_FIELD(hash); -- 2.30.2 From domi at tomcsanyi.net Wed Aug 18 21:27:54 2021 From: domi at tomcsanyi.net (=?utf-8?Q?=22Tomcs=C3=A1nyi=2C_Domonkos=22?=) Date: Wed, 18 Aug 2021 23:27:54 +0200 Subject: Domain as endpoint when using wireguard with network namespaces In-Reply-To: References: <03667268-5415-4FB0-9D4B-1E51466A3F5C@tomcsanyi.net> <781a68d1-6a85-4bb7-9911-003ba722c504@Spark> Message-ID: <57EC9A43-F6C1-4583-8059-CF6161853B83@tomcsanyi.net> Hi, Thanks for the kid and detailed answer, this is quite fascinating, I never looked deep into wireguard and namespaces, only dealt with a couple of simple IPsec + namespaces scenario before. To me your issue seems to be valid, I hope you will get an answer from Jason sooner or later. Cheers, Domi > >> 2021. aug. 18. d?tummal, 23:19 id?pontban Waishon ?rta: >> >> Hey there, >> >> thanks for your reply: >> >> The reason why it works when using an IP instead of a domain is the "birth namespace" concept of wiregurard. You're creating the WireGuard interface inside your init-namespace (birth-namespace) which does have an internet connection. The UDP socket for sending and receiving the encrypted packets is also created here. >> >> Afterwards you move your WireGuard interface into a newly created network namespace. The UDP socket is still inside the birth-namespace. When you now call "wg set" with an IP-Address from inside the network namespace, it "tells" the UDP socket inside the birth-namespace to connect to this endpoint over the internet connection of the birth-namespace. >> >> When the UDP socket receives encrypted packets, WireGuard decrypts them and puts the network packets in the device queue of the WireGuard interface, which is inside the network namespace (I hope I understood the source code correctly). So you don't need an internet connection inside the network namespace to create a wireguard tunnel, when using an ip-address. I've tested it and it works fine, as described in the documentation https://www.wireguard.com/netns/. >> >> However when using a domain, "wg set" tries to lookup the domain inside the network namespace (which doesn't have an internet connection until the tunnel is created) and not inside the birth-namespace. >> >> I think that the wg-tool should determine the namespace of the udp socket and do the DNS lookup there. However I don't know if this is even possible to implement. >> >> Kind regards >> Am 18. Aug. 2021, 07:54 +0200 schrieb Tomcsanyi, Domonkos : >> I am sorry, but I need to ask: if your namespace does not have an internet connection how would you connect to your remote endpoint after the DNS lookup issue is solved and you received the IP behind vpn.example.com? >> >> Kind regards, >> Domi >> >> 17.08.2021 d?tummal, 23:06 id?pontban Waishon ?rta: >> >> ?Hey there, >> >> I'm currently trying to setup a wireguard-tunnel inside a >> network-namespace as descriped in the documentation, which fails when >> using a domain as endpoint: >> https://www.wireguard.com/netns/ >> >> First I've created the wireguard interface inside the birth-namespace >> of the host using "ip link add wg0 type wireguard". Then I moved the >> wg0 interface to the newly created network namespace, which doesn't >> have any network interfaces and network connections beside the >> loopback interface. >> >> Then I configured the wg0 interface inside the network namespace using >> wg set "INTERFACE_NAME" \ >> private-key > peer "PEER" \ >> endpoint vpn.example.com:51820 \ >> persistent-keepalive 25 \ >> allowed-ips ::/0 >> >> This however results in a "Temporary failure in name resolution: >> `vpn.example.com:51820'. Trying again in 1.00 seconds..." error >> message, which makes sense, because the wireguard-tool tries to call >> getaddrinfo inside the network namespace. The namespace doesn't have >> an internet connection and the lookup fails. >> https://github.com/WireGuard/wireguard-tools/blob/96e42feb3f41e2161141d4958e2637d9dee6f90a/src/config.c#L242 >> >> As a user I would expect that the wg-tool does the lookup in the >> birth-namespace of the interface and not inside the newly created >> network namespace. >> >> What is the recommended solution to resolve an domain endpoint when >> using network namespaces and wireguard? Just manually lookup the >> domain in the birth-namespace and use the ip as endpoint? The >> implementation however would be quiete hacky to make it properly work >> with IPv4 and IPv6. > From waishon009 at gmail.com Wed Aug 18 21:30:12 2021 From: waishon009 at gmail.com (Waishon) Date: Wed, 18 Aug 2021 23:30:12 +0200 Subject: Domain as endpoint when using wireguard with network namespaces In-Reply-To: <03667268-5415-4FB0-9D4B-1E51466A3F5C@tomcsanyi.net> References: <03667268-5415-4FB0-9D4B-1E51466A3F5C@tomcsanyi.net> Message-ID: Hey there, thanks for your reply: The reason why it works when using an IP instead of a domain is the "birth namespace" concept of wiregurard. You're creating the WireGuard interface inside your init-namespace (birth-namespace) which does have an internet connection. The UDP socket for sending and receiving the encrypted packets is also created here. Afterwards you move your WireGuard interface into a newly created network namespace. The UDP socket is still inside the birth-namespace. When you now call "wg set" with an IP-Address from inside the network namespace, it "tells" the UDP socket inside the birth-namespace to connect to this endpoint over the internet connection of the birth-namespace. When the UDP socket receives encrypted packets, WireGuard decrypts them and puts the network packets in the device queue of the WireGuard interface, which is inside the network namespace (I hope I understood the source code correctly). So you don't need an internet connection inside the network namespace to create a wireguard tunnel, when using an ip-address. I've tested it and it works fine, as described in the documentation https://www.wireguard.com/netns/. However when using a domain, "wg set" tries to lookup the domain inside the network namespace (which doesn't have an internet connection until the tunnel is created) and not inside the birth-namespace. I think that the wg-tool should determine the namespace of the udp socket and do the DNS lookup there. However I don't know if this is even possible to implement. Kind regards (P.S. I think I didn't send the first reply as Text only mail. I hope the thread doesn't end in chaos ;)). Am 18. Aug. 2021, 07:54 +0200 schrieb Tomcsanyi, Domonkos : I am sorry, but I need to ask: if your namespace does not have an internet connection how would you connect to your remote endpoint after the DNS lookup issue is solved and you received the IP behind vpn.example.com? Kind regards, Domi 17.08.2021 d?tummal, 23:06 id?pontban Waishon ?rta: ?Hey there, I'm currently trying to setup a wireguard-tunnel inside a network-namespace as descriped in the documentation, which fails when using a domain as endpoint: https://www.wireguard.com/netns/ First I've created the wireguard interface inside the birth-namespace of the host using "ip link add wg0 type wireguard". Then I moved the wg0 interface to the newly created network namespace, which doesn't have any network interfaces and network connections beside the loopback interface. Then I configured the wg0 interface inside the network namespace using wg set "INTERFACE_NAME" \ private-key References: Message-ID: Yes I did, as described this isn't the problem. How should WireGuard resolve the domain using the DNS server set inside the container, when it doesn't have an internet connection? Kind regards Am Sa., 21. Aug. 2021 um 22:05 Uhr schrieb Marios Makassikis : > > On Tue, Aug 17, 2021 at 11:11 PM Waishon wrote: > > > > Hey there, > > > > I'm currently trying to setup a wireguard-tunnel inside a > > network-namespace as descriped in the documentation, which fails when > > using a domain as endpoint: > > https://www.wireguard.com/netns/ > > > > First I've created the wireguard interface inside the birth-namespace > > of the host using "ip link add wg0 type wireguard". Then I moved the > > wg0 interface to the newly created network namespace, which doesn't > > have any network interfaces and network connections beside the > > loopback interface. > > > > Then I configured the wg0 interface inside the network namespace using > > wg set "INTERFACE_NAME" \ > > private-key > peer "PEER" \ > > endpoint vpn.example.com:51820 \ > > persistent-keepalive 25 \ > > allowed-ips ::/0 > > > > This however results in a "Temporary failure in name resolution: > > `vpn.example.com:51820'. Trying again in 1.00 seconds..." error > > message, which makes sense, because the wireguard-tool tries to call > > getaddrinfo inside the network namespace. The namespace doesn't have > > an internet connection and the lookup fails. > > https://github.com/WireGuard/wireguard-tools/blob/96e42feb3f41e2161141d4958e2637d9dee6f90a/src/config.c#L242 > > > > As a user I would expect that the wg-tool does the lookup in the > > birth-namespace of the interface and not inside the newly created > > network namespace. > > > > What is the recommended solution to resolve an domain endpoint when > > using network namespaces and wireguard? Just manually lookup the > > domain in the birth-namespace and use the ip as endpoint? The > > implementation however would be quiete hacky to make it properly work > > with IPv4 and IPv6. > > Have you configured a nameserver for your network namespace ? > > Normally, that would be /etc/netns//resolv.conf (you may > need to create the subdirectory first). From sanderbauer at gmail.com Fri Aug 20 11:16:34 2021 From: sanderbauer at gmail.com (S Bauer) Date: Fri, 20 Aug 2021 13:16:34 +0200 Subject: enabling WG0 allows telegram but impedes browsing Message-ID: Hello team, Hoping you could help me out with a foggy situation. The past week I have been struggling to get the Wireguard VPN working smoothly. Everything seems to work on paper, except in a specific way it doesn't. I am using Pop!_OS 21.04 (Ubuntu Hirsute). SitRep; I work as a freelance consultant and want to be careful about the local networks' peeping tom when accessing sensitive work documents from 'out of office', e.g. at a friend's place or at a hotel. So my objective is to access my home network via PiHole and then continue onward to access my work-related documents on a fileserver. I was hoping this could be easily achieved with Wireguard. Using the Wireguard VPN wg0 with wg-quick worked perfectly when I connected to my brother's phone hotspot (4G). I could access our home via VPN as expected and could work on my documents without any problems. The trouble is that I am now at a different location, working with a fixed router from Ziggo NL. For some reason the WG0 still connects perfectly, but after that a small mystery occurs. I did not make any modifications to WG0.conf, so I remain stumped. With WG active, I am no longer able to access any webpage. So no access to protonmail\gmail, reddit or anything else. Telegram, however, is still working fine. Internal machines on the home's local network (IP-camera) can also be accessed directly. Disabling the WG gives me full access to any webpage as usual. So something is amiss that affects my browser only (Firefox 91.0). I already did some troubleshooting. Starting with Uncomplicated Firewall (UFW). I tried disabling UFW and rebooting, but this did not change anything. I still lacked browser access when connected with WG0, but Telegram still worked fine. The output from sudo wg is; interface: wg0 public key: (hidden) private key: (hidden) listening port: fwmark: 0xca6c peer: (hidden) preshared key: (hidden) endpoint: >our_endpoint_name<.ddns.net:51820 allowed ips: 0.0.0.0/0, ::/0 latest handshake: 3 seconds ago transfer: 92 B received, 4.77 KiB sent To be on the safe side, I added several rules to UFW (and reloaded UFW each time) per advice from https://jianjye.medium.com/how-to-fix-no-internet-issues-in-wireguard-ed8f4bdd0bd1 , leaving me with the following output from ufw status verbose. (But like I said, the problem occurs even with UFW disabled.) Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), deny (routed) New profiles: skip To Action From -- ------ ---- Anywhere/udp on wg0 ALLOW IN Anywhere/udp /udp ALLOW IN Anywhere /udp ALLOW IN Anywhere /udp on wlp0s20f3 ALLOW IN Anywhere Anywhere/udp on wlp0s20f3 ALLOW IN Anywhere/udp on wlp0s20f3 ALLOW IN Anywhere Anywhere/udp (v6) on wg0 ALLOW IN Anywhere/udp (v6) /udp (v6) ALLOW IN Anywhere (v6) /udp (v6) ALLOW IN Anywhere (v6) /udp (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) Anywhere/udp (v6) on wlp0s20f3 ALLOW IN Anywhere/udp (v6) (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) Anywhere on eth0 ALLOW FWD Anywhere on wg0 Anywhere on wg0 ALLOW FWD Anywhere on eth0 Anywhere on wg0 ALLOW FWD Anywhere on enp40s0 Anywhere on enp40s0 ALLOW FWD Anywhere on wg0 Anywhere on wlp0s20f3 ALLOW FWD Anywhere on wg0 Anywhere on wg0 ALLOW FWD Anywhere on wlp0s20f3 Anywhere (v6) on eth0 ALLOW FWD Anywhere (v6) on wg0 Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on eth0 Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on enp40s0 Anywhere (v6) on enp40s0 ALLOW FWD Anywhere (v6) on wg0 Anywhere (v6) on wlp0s20f3 ALLOW FWD Anywhere (v6) on wg0 Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on wlp0s20f3 Now all these rules may be barbaric overkill, and yes I will admit that I have a limited understanding of what everything means and how it affects my security. Though I am a linux newcomer and employ duckduckgo to the best of my abilities the learning curve is still pretty much in effect. That being said, do feel free to point out any serious flaws I may have unwittingly introduced or simply push me towards some longreads ;) Any hints on solving this issue are appreciated. Additional notes; * the DDNS in wg0.conf is properly translated to an IP address each time. So that seems to be no issue. * I am currently using the Dutch Ziggo network, which already seems to have a reputation concerning the use of VPN applications. Maybe the issue lies herein? * Should I consider this relevant? > https://github.com/pop-os/pop/issues/773 I am a bit cautious about doing more random stuff before actually understanding what is going on. Regards, Sander From mmakassikis at freebox.fr Sat Aug 21 20:05:19 2021 From: mmakassikis at freebox.fr (Marios Makassikis) Date: Sat, 21 Aug 2021 22:05:19 +0200 Subject: Domain as endpoint when using wireguard with network namespaces In-Reply-To: References: Message-ID: On Tue, Aug 17, 2021 at 11:11 PM Waishon wrote: > > Hey there, > > I'm currently trying to setup a wireguard-tunnel inside a > network-namespace as descriped in the documentation, which fails when > using a domain as endpoint: > https://www.wireguard.com/netns/ > > First I've created the wireguard interface inside the birth-namespace > of the host using "ip link add wg0 type wireguard". Then I moved the > wg0 interface to the newly created network namespace, which doesn't > have any network interfaces and network connections beside the > loopback interface. > > Then I configured the wg0 interface inside the network namespace using > wg set "INTERFACE_NAME" \ > private-key peer "PEER" \ > endpoint vpn.example.com:51820 \ > persistent-keepalive 25 \ > allowed-ips ::/0 > > This however results in a "Temporary failure in name resolution: > `vpn.example.com:51820'. Trying again in 1.00 seconds..." error > message, which makes sense, because the wireguard-tool tries to call > getaddrinfo inside the network namespace. The namespace doesn't have > an internet connection and the lookup fails. > https://github.com/WireGuard/wireguard-tools/blob/96e42feb3f41e2161141d4958e2637d9dee6f90a/src/config.c#L242 > > As a user I would expect that the wg-tool does the lookup in the > birth-namespace of the interface and not inside the newly created > network namespace. > > What is the recommended solution to resolve an domain endpoint when > using network namespaces and wireguard? Just manually lookup the > domain in the birth-namespace and use the ip as endpoint? The > implementation however would be quiete hacky to make it properly work > with IPv4 and IPv6. Have you configured a nameserver for your network namespace ? Normally, that would be /etc/netns//resolv.conf (you may need to create the subdirectory first). From rm at romanrm.net Sat Aug 21 20:27:53 2021 From: rm at romanrm.net (Roman Mamedov) Date: Sun, 22 Aug 2021 01:27:53 +0500 Subject: enabling WG0 allows telegram but impedes browsing In-Reply-To: References: Message-ID: <20210822012753.27447e9f@natsu> On Fri, 20 Aug 2021 13:16:34 +0200 S Bauer wrote: > Hello team, > > Hoping you could help me out with a foggy situation. > The past week I have been struggling to get the Wireguard VPN working > smoothly. Everything seems to work on paper, except in a specific way > it doesn't. I am using Pop!_OS 21.04 (Ubuntu Hirsute). > > SitRep; > I work as a freelance consultant and want to be careful about the > local networks' peeping tom when accessing sensitive work documents > from 'out of office', e.g. at a friend's place or at a hotel. So my > objective is to access my home network via PiHole and then continue > onward to access my work-related documents on a fileserver. > I was hoping this could be easily achieved with Wireguard. > > Using the Wireguard VPN wg0 with wg-quick worked perfectly when I > connected to my brother's phone hotspot (4G). I could access our home > via VPN as expected and could work on my documents without any > problems. > The trouble is that I am now at a different location, working with a > fixed router from Ziggo NL. For some reason the WG0 still connects > perfectly, but after that a small mystery occurs. I did not make any > modifications to WG0.conf, so I remain stumped. > With WG active, I am no longer able to access any webpage. So no > access to protonmail\gmail, reddit or anything else. Telegram, > however, is still working fine. Internal machines on the home's local > network (IP-camera) can also be accessed directly. > Disabling the WG gives me full access to any webpage as usual. So > something is amiss that affects my browser only (Firefox 91.0). What's your MTU on the wg0 interface? Try reducing that to 1400, or if that doesn't help, to 1280. -- With respect, Roman From wireguard at spam-free.eu Mon Aug 23 17:38:37 2021 From: wireguard at spam-free.eu (Chris) Date: Mon, 23 Aug 2021 19:38:37 +0200 Subject: enabling WG0 allows telegram but impedes browsing In-Reply-To: References: Message-ID: If I understand it right, everything seems fine BUT once wg is up you cannot reach e.g. other websites. Therefore you you try to track the route to say reddit. Command line: mtr -n reddit.com and then you will see at what point the data transport to reddit gets stuck. Also check (command line) host -v reddit.com to check on the correct DNS working. Chris On 20/08/2021 13:16, S Bauer wrote: > Hello team, > > Hoping you could help me out with a foggy situation. > The past week I have been struggling to get the Wireguard VPN working > smoothly. Everything seems to work on paper, except in a specific way > it doesn't. I am using Pop!_OS 21.04 (Ubuntu Hirsute). > > SitRep; > I work as a freelance consultant and want to be careful about the > local networks' peeping tom when accessing sensitive work documents > from 'out of office', e.g. at a friend's place or at a hotel. So my > objective is to access my home network via PiHole and then continue > onward to access my work-related documents on a fileserver. > I was hoping this could be easily achieved with Wireguard. > > Using the Wireguard VPN wg0 with wg-quick worked perfectly when I > connected to my brother's phone hotspot (4G). I could access our home > via VPN as expected and could work on my documents without any > problems. > The trouble is that I am now at a different location, working with a > fixed router from Ziggo NL. For some reason the WG0 still connects > perfectly, but after that a small mystery occurs. I did not make any > modifications to WG0.conf, so I remain stumped. > With WG active, I am no longer able to access any webpage. So no > access to protonmail\gmail, reddit or anything else. Telegram, > however, is still working fine. Internal machines on the home's local > network (IP-camera) can also be accessed directly. > Disabling the WG gives me full access to any webpage as usual. So > something is amiss that affects my browser only (Firefox 91.0). > > I already did some troubleshooting. Starting with Uncomplicated > Firewall (UFW). I tried disabling UFW and rebooting, but this did not > change anything. I still lacked browser access when connected with > WG0, but Telegram still worked fine. > The output from sudo wg is; > interface: wg0 > public key: (hidden) > private key: (hidden) > listening port: > fwmark: 0xca6c > > peer: (hidden) > preshared key: (hidden) > endpoint: >our_endpoint_name<.ddns.net:51820 > allowed ips: 0.0.0.0/0, ::/0 > latest handshake: 3 seconds ago > transfer: 92 B received, 4.77 KiB sent > > To be on the safe side, I added several rules to UFW (and reloaded UFW > each time) per advice from > https://jianjye.medium.com/how-to-fix-no-internet-issues-in-wireguard-ed8f4bdd0bd1 > , leaving me with the following output from ufw status verbose. (But > like I said, the problem occurs even with UFW disabled.) > Status: active > Logging: on (low) > Default: deny (incoming), allow (outgoing), deny (routed) > New profiles: skip > > To Action From > -- ------ ---- > Anywhere/udp on wg0 ALLOW IN Anywhere/udp > /udp ALLOW IN Anywhere > /udp ALLOW IN Anywhere > /udp on wlp0s20f3 ALLOW IN Anywhere > Anywhere/udp on wlp0s20f3 ALLOW IN Anywhere/udp > on wlp0s20f3 ALLOW IN Anywhere > Anywhere/udp (v6) on wg0 ALLOW IN Anywhere/udp (v6) > /udp (v6) ALLOW IN Anywhere (v6) > /udp (v6) ALLOW IN Anywhere (v6) > /udp (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) > Anywhere/udp (v6) on wlp0s20f3 ALLOW IN Anywhere/udp (v6) > (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) > > Anywhere on eth0 ALLOW FWD Anywhere on wg0 > Anywhere on wg0 ALLOW FWD Anywhere on eth0 > Anywhere on wg0 ALLOW FWD Anywhere on enp40s0 > Anywhere on enp40s0 ALLOW FWD Anywhere on wg0 > Anywhere on wlp0s20f3 ALLOW FWD Anywhere on wg0 > Anywhere on wg0 ALLOW FWD Anywhere on wlp0s20f3 > Anywhere (v6) on eth0 ALLOW FWD Anywhere (v6) on wg0 > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on eth0 > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on enp40s0 > Anywhere (v6) on enp40s0 ALLOW FWD Anywhere (v6) on wg0 > Anywhere (v6) on wlp0s20f3 ALLOW FWD Anywhere (v6) on wg0 > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on wlp0s20f3 > > Now all these rules may be barbaric overkill, and yes I will admit > that I have a limited understanding of what everything means and how > it affects my security. Though I am a linux newcomer and employ > duckduckgo to the best of my abilities the learning curve is still > pretty much in effect. That being said, do feel free to point out any > serious flaws I may have unwittingly introduced or simply push me > towards some longreads ;) > > Any hints on solving this issue are appreciated. > > > Additional notes; > * the DDNS in wg0.conf is properly translated to an IP address each > time. So that seems to be no issue. > * I am currently using the Dutch Ziggo network, which already seems to > have a reputation concerning the use of VPN applications. Maybe the > issue lies herein? > * Should I consider this relevant? > > https://github.com/pop-os/pop/issues/773 I am a bit cautious about > doing more random stuff before actually understanding what is going > on. > > Regards, > Sander From dv.lnh.d at gmail.com Mon Aug 23 10:21:30 2021 From: dv.lnh.d at gmail.com (=?UTF-8?Q?David_L=C3=B6nnhager?=) Date: Mon, 23 Aug 2021 12:21:30 +0200 Subject: WireGuardNT: Tunnels cannot be "nested" Message-ID: Hello, I'm trying to connect to one peer/endpoint via another peer. Using wireguard-go, or using WireGuard in the Linux kernel, this could be accomplished with a configuration kind of like this one: [Peer] Endpoint = A:51820 AllowedIPs = B/32 [Peer] Endpoint = B:51820 AllowedIPs = 0.0.0.0/0 When I try this setup with WireGuardNT (0.4), it seems as if B is being connected to directly (outside of any tunnel), even if I route "B" through the WireGuard interface. Are routes using the interface being ignored (https://git.zx2c4.com/wireguard-nt/tree/driver/socket.c#n213), and is this the reason why the above no longer seems to work? Is there any chance that this will change? Thank you, David From skhan at linuxfoundation.org Wed Aug 25 19:31:28 2021 From: skhan at linuxfoundation.org (Shuah Khan) Date: Wed, 25 Aug 2021 13:31:28 -0600 Subject: [PATCH] selftests: cleanup config In-Reply-To: <20210825050948.10339-1-lizhijian@cn.fujitsu.com> References: <20210825050948.10339-1-lizhijian@cn.fujitsu.com> Message-ID: <6547d239-56b7-71c0-70c9-20a67bdad1dd@linuxfoundation.org> On 8/24/21 11:09 PM, Li Zhijian wrote: > - DEBUG_PI_LIST was renamed to DEBUG_PLIST since 8e18faeac3 ("lib/plist: rename DEBUG_PI_LIST to DEBUG_PLIST") > - SYNC was removed since aff9da10e21 ("staging/android: make sync_timeline internal to sw_sync") > Please write a complete commit log explaining the change and tell us what happens if we don't do this. > $ for k in $(grep ^CONFIG $(find tools/testing/selftests/ -name config) | awk -F'=' '{print$1}' | awk -F':' '{print $2}' | sort | uniq); do k=${k#CONFIG_}; git grep -qw -e "menuconfig $k" -e "config $k" || echo "$k is missing"; done; > DEBUG_PI_LIST is missing > SYNC is missing > > CC: Philip Li > Reported-by: kernel test robot > Signed-off-by: Li Zhijian > --- > tools/testing/selftests/cpufreq/config | 2 +- > tools/testing/selftests/sync/config | 1 - > tools/testing/selftests/wireguard/qemu/debug.config | 2 +- > 3 files changed, 2 insertions(+), 3 deletions(-) > Please split this into 3 patches thanks, -- Shuah From skhan at linuxfoundation.org Thu Aug 26 21:11:28 2021 From: skhan at linuxfoundation.org (Shuah Khan) Date: Thu, 26 Aug 2021 15:11:28 -0600 Subject: [PATCH v2 3/3] selftests/wireguard: Rename DEBUG_PI_LIST to DEBUG_PLIST In-Reply-To: <20210826015847.7416-4-lizhijian@cn.fujitsu.com> References: <20210826015847.7416-1-lizhijian@cn.fujitsu.com> <20210826015847.7416-4-lizhijian@cn.fujitsu.com> Message-ID: <0df0882e-53e5-e407-ed29-e21da7965bc4@linuxfoundation.org> On 8/25/21 7:58 PM, Li Zhijian wrote: > DEBUG_PI_LIST was renamed to DEBUG_PLIST since 8e18faeac3 ("lib/plist: rename DEBUG_PI_LIST to DEBUG_PLIST") > > CC: "Jason A. Donenfeld" > CC: Nick Desaulniers > CC: Masahiro Yamada > CC: wireguard at lists.zx2c4.com > CC: netdev at vger.kernel.org > > Signed-off-by: Li Zhijian > --- Can you please state what you are fixing and also keep the sentences 75 chars or less. Where is LKP warning? Include the warning and explain why this change is necessary. thanks, -- Shuah From lizhijian at cn.fujitsu.com Wed Aug 25 05:09:48 2021 From: lizhijian at cn.fujitsu.com (Li Zhijian) Date: Wed, 25 Aug 2021 13:09:48 +0800 Subject: [PATCH] selftests: cleanup config Message-ID: <20210825050948.10339-1-lizhijian@cn.fujitsu.com> - DEBUG_PI_LIST was renamed to DEBUG_PLIST since 8e18faeac3 ("lib/plist: rename DEBUG_PI_LIST to DEBUG_PLIST") - SYNC was removed since aff9da10e21 ("staging/android: make sync_timeline internal to sw_sync") $ for k in $(grep ^CONFIG $(find tools/testing/selftests/ -name config) | awk -F'=' '{print$1}' | awk -F':' '{print $2}' | sort | uniq); do k=${k#CONFIG_}; git grep -qw -e "menuconfig $k" -e "config $k" || echo "$k is missing"; done; DEBUG_PI_LIST is missing SYNC is missing CC: Philip Li Reported-by: kernel test robot Signed-off-by: Li Zhijian --- tools/testing/selftests/cpufreq/config | 2 +- tools/testing/selftests/sync/config | 1 - tools/testing/selftests/wireguard/qemu/debug.config | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) diff --git a/tools/testing/selftests/cpufreq/config b/tools/testing/selftests/cpufreq/config index 27ff72ebd0f5..75e900793e8a 100644 --- a/tools/testing/selftests/cpufreq/config +++ b/tools/testing/selftests/cpufreq/config @@ -6,7 +6,7 @@ CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y CONFIG_DEBUG_RT_MUTEXES=y -CONFIG_DEBUG_PI_LIST=y +CONFIG_DEBUG_PLIST=y CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y diff --git a/tools/testing/selftests/sync/config b/tools/testing/selftests/sync/config index 1ab7e8130db2..47ff5afc3727 100644 --- a/tools/testing/selftests/sync/config +++ b/tools/testing/selftests/sync/config @@ -1,4 +1,3 @@ CONFIG_STAGING=y CONFIG_ANDROID=y -CONFIG_SYNC=y CONFIG_SW_SYNC=y diff --git a/tools/testing/selftests/wireguard/qemu/debug.config b/tools/testing/selftests/wireguard/qemu/debug.config index fe07d97df9fa..2b321b8a96cf 100644 --- a/tools/testing/selftests/wireguard/qemu/debug.config +++ b/tools/testing/selftests/wireguard/qemu/debug.config @@ -47,7 +47,7 @@ CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_LIST=y -CONFIG_DEBUG_PI_LIST=y +CONFIG_DEBUG_PLIST=y CONFIG_PROVE_RCU=y CONFIG_SPARSE_RCU_POINTER=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -- 2.31.1 From tech at tootai.net Wed Aug 25 15:25:54 2021 From: tech at tootai.net (Daniel) Date: Wed, 25 Aug 2021 17:25:54 +0200 Subject: ipv6 connexion fail - ipv4 OK Message-ID: Hi list, I setup wireguard on a server running Debian 11 and get it to work with 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on separate networks, one client behind a FW the other direct on Internet, no FW at all (VPS). With this setup and ipv4 connection to the public IP of the server, everything is working as expected, ipv4 as well as ipv6 are passing smoothly. Now I want to connect using the ipv6 address of the wg interface as both clients and server have ULA ipv6. This fail, wg show that connection is established but VPN is not usable. It's not a FW problem as I can ssh to the ipv6 address, as well as a netcat test from/to server IP -from each client- on an UDP port is working properly. Also, net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf All network stuff is done in /etc/network/interfaces which call the config file. The ipv6 address of the server is affected _to the wireguard interface_ (in ipv4 it's another interface who take care of the public address) Server version is wireguard-tools v1.0.20210223. If someone have any hint, thanks to share ;) -- Daniel From gopakumar.c.e at gmail.com Wed Aug 25 19:05:19 2021 From: gopakumar.c.e at gmail.com (Gopakumar Choorakkot Edakkunni) Date: Wed, 25 Aug 2021 15:05:19 -0400 Subject: wireguard-windows: packets dropped in NativeTun Read() Message-ID: Hi, I am experimenting with wintun as the choice of my driver for a vpn client I am writing on windows. I was very quickly able to get bootstrapped using the wireguard-windows repository (thanks!!), I created a tunnel and when I use the Read() api (tun_windows.go), I see that quite often I am missing packets. How do I know this ? - I run a tshark on the tun interface (needs editpcap to convert from ethernet to ip format), and then I compare packets there with what I get, and I see my read missing packets present in wireshark. The traffic rate is very low - just regular browsing to websites, no major traffic. I am reading from the tun interface from a goroutine, I suspected maybe I/O bound reads might be not scheduled enough by go scheduler, so I increased the go threads. I thought maybe the ring size need to increase so I made it 32Mb etc.. - still no good, I still get Rx packets missing. Kind of clueless at this point - any pointers/hints/suggestions will be appreciated a lot !! Rgds, Gopa. From lizhijian at cn.fujitsu.com Thu Aug 26 01:58:44 2021 From: lizhijian at cn.fujitsu.com (Li Zhijian) Date: Thu, 26 Aug 2021 09:58:44 +0800 Subject: [PATCH v2 0/3] kselftests: clean configs Message-ID: <20210826015847.7416-1-lizhijian@cn.fujitsu.com> 0Day will check if all configs listing under selftests are able to be enabled properly. For the missing configs, it will report something like: LKP WARN miss config CONFIG_SYNC= of sync/config CC: kernel test robot CC: "Jason A. Donenfeld" CC: Nick Desaulniers CC: Masahiro Yamada CC: wireguard at lists.zx2c4.com CC: netdev at vger.kernel.org CC: "Rafael J. Wysocki" CC: Viresh Kumar CC: linux-pm at vger.kernel.org Reported-by: kernel test robot Li Zhijian (3): selftests/sync: Remove the deprecated config SYNC selftests/cpufreq: Rename DEBUG_PI_LIST to DEBUG_PLIST selftests/wireguard: Rename DEBUG_PI_LIST to DEBUG_PLIST tools/testing/selftests/cpufreq/config | 2 +- tools/testing/selftests/sync/config | 1 - tools/testing/selftests/wireguard/qemu/debug.config | 2 +- 3 files changed, 2 insertions(+), 3 deletions(-) -- 2.31.1 From lizhijian at cn.fujitsu.com Thu Aug 26 01:58:47 2021 From: lizhijian at cn.fujitsu.com (Li Zhijian) Date: Thu, 26 Aug 2021 09:58:47 +0800 Subject: [PATCH v2 3/3] selftests/wireguard: Rename DEBUG_PI_LIST to DEBUG_PLIST In-Reply-To: <20210826015847.7416-1-lizhijian@cn.fujitsu.com> References: <20210826015847.7416-1-lizhijian@cn.fujitsu.com> Message-ID: <20210826015847.7416-4-lizhijian@cn.fujitsu.com> DEBUG_PI_LIST was renamed to DEBUG_PLIST since 8e18faeac3 ("lib/plist: rename DEBUG_PI_LIST to DEBUG_PLIST") CC: "Jason A. Donenfeld" CC: Nick Desaulniers CC: Masahiro Yamada CC: wireguard at lists.zx2c4.com CC: netdev at vger.kernel.org Signed-off-by: Li Zhijian --- tools/testing/selftests/wireguard/qemu/debug.config | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/wireguard/qemu/debug.config b/tools/testing/selftests/wireguard/qemu/debug.config index fe07d97df9fa..2b321b8a96cf 100644 --- a/tools/testing/selftests/wireguard/qemu/debug.config +++ b/tools/testing/selftests/wireguard/qemu/debug.config @@ -47,7 +47,7 @@ CONFIG_DEBUG_ATOMIC_SLEEP=y CONFIG_TRACE_IRQFLAGS=y CONFIG_DEBUG_BUGVERBOSE=y CONFIG_DEBUG_LIST=y -CONFIG_DEBUG_PI_LIST=y +CONFIG_DEBUG_PLIST=y CONFIG_PROVE_RCU=y CONFIG_SPARSE_RCU_POINTER=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -- 2.31.1 From tech at tootai.net Thu Aug 26 11:14:00 2021 From: tech at tootai.net (Daniel) Date: Thu, 26 Aug 2021 13:14:00 +0200 Subject: ipv6 connexion fail - ipv4 OK In-Reply-To: References: Message-ID: Correction Le 25/08/2021 ? 17:25, Daniel a ?crit?: > Hi list, > > I setup wireguard on a server running Debian 11 and get it to work with > 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on > separate networks, one client behind a FW the other direct on Internet, > no FW at all (VPS). > > With this setup and ipv4 connection to the public IP of the server, > everything is working as expected, ipv4 as well as ipv6 are passing > smoothly. > > Now I want to connect using the ipv6 address of the wg interface as both > clients and server have ULA ipv6. Here is GUA to read. > This fail, wg show that connection is > established but VPN is not usable. It's not a FW problem as I can ssh to > the ipv6 address, as well as a netcat test from/to server IP -from each > client- on an UDP port is working properly. Also, > net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf > > All network stuff is done in /etc/network/interfaces which call the > config file. The ipv6 address of the server is affected _to the > wireguard interface_ (in ipv4 it's another interface who take care of > the public address) > > Server version is wireguard-tools v1.0.20210223. > > If someone have any hint, thanks to share ;) -- Daniel Huhardeaux +33.368460088 at tootai.net sip:820 at sip.tootai.net +41.445532125 at swiss-itech.ch tootaiNET From gopakumar.c.e at gmail.com Thu Aug 26 13:14:13 2021 From: gopakumar.c.e at gmail.com (Gopakumar Choorakkot Edakkunni) Date: Thu, 26 Aug 2021 09:14:13 -0400 Subject: wintun0.13 memmod load fails in windows10 (wintun 0.12 loads fine) Message-ID: In memmod_windows.go, the program exits when calling syscall.Syscall(module.entry, 3, module.codeBase, uintptr(DLL_PROCESS_ATTACH), 0) module.entry = 0x18000a660 module.codebase = 0x180000000 I I just swap out wintun 0.13 with wintun0.12, the load / syscall works just fine, just for reference the entry and codebase for wintun 0.12 are below module.entry = 0x18000b64c module.codebase = 0x180000000 My windows system details are below Edition Windows 10 Pro Version 20H2 Installed on ?4/?3/?2021 OS build 19042.1165 Any suggestions to debug further ? Rgds, Gopa. From Jason at zx2c4.com Fri Aug 27 14:11:17 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 27 Aug 2021 16:11:17 +0200 Subject: wintun0.13 memmod load fails in windows10 (wintun 0.12 loads fine) In-Reply-To: References: Message-ID: Update to the latest wireguard-go commit. https://git.zx2c4.com/wireguard-go/commit/?id=bad6caeb82edd0e22bdbcfa1ca544a5805109e14 From Jason at zx2c4.com Fri Aug 27 14:23:43 2021 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 27 Aug 2021 16:23:43 +0200 Subject: [PATCH v2 3/3] selftests/wireguard: Rename DEBUG_PI_LIST to DEBUG_PLIST In-Reply-To: <20210826015847.7416-4-lizhijian@cn.fujitsu.com> References: <20210826015847.7416-1-lizhijian@cn.fujitsu.com> <20210826015847.7416-4-lizhijian@cn.fujitsu.com> Message-ID: Hi, On Thu, Aug 26, 2021 at 3:54 AM Li Zhijian wrote: > > DEBUG_PI_LIST was renamed to DEBUG_PLIST since 8e18faeac3 ("lib/plist: rename DEBUG_PI_LIST to DEBUG_PLIST") Thanks for the patch. I've queued this up in my wireguard-linux.git tree for some rounds of CI, and I'll send it back out in the next series I send to netdev. Regards, Jason From gopakumar.c.e at gmail.com Fri Aug 27 14:40:36 2021 From: gopakumar.c.e at gmail.com (Gopakumar Choorakkot Edakkunni) Date: Fri, 27 Aug 2021 10:40:36 -0400 Subject: wintun0.13 memmod load fails in windows10 (wintun 0.12 loads fine) In-Reply-To: References: Message-ID: Thanks for the response Jason. My reason for trying 0.13 version was because I "thought" 0.12 had some issue because I was seeing random packet loss (I had another email thread for it) - but then I figured the random loss was because I was doing a device.New()/device.UP AND also reading wintun from my own goroutine, so two of them reading same queue. Now that I fixed it, I am happy with 0.12. I will wait for the next wintun release which has this memod load issue fixed (0.14 ?) and upgrade directly to that Rgds, Gopa. On Fri, Aug 27, 2021 at 10:11 AM Jason A. Donenfeld wrote: > > Update to the latest wireguard-go commit. > https://git.zx2c4.com/wireguard-go/commit/?id=bad6caeb82edd0e22bdbcfa1ca544a5805109e14 From gopakumar.c.e at gmail.com Fri Aug 27 14:42:52 2021 From: gopakumar.c.e at gmail.com (Gopakumar Choorakkot Edakkunni) Date: Fri, 27 Aug 2021 10:42:52 -0400 Subject: wintun0.13 memmod load fails in windows10 (wintun 0.12 loads fine) In-Reply-To: References: Message-ID: oh well I guess I dont need a new wintun, but just the new wireguard go. Sorry I misread it, will try that Rgds, Gopa. On Fri, Aug 27, 2021 at 10:40 AM Gopakumar Choorakkot Edakkunni wrote: > > Thanks for the response Jason. My reason for trying 0.13 version was > because I "thought" 0.12 had some issue because I was seeing random > packet loss (I had another email thread for it) - but then I figured > the random loss was because I was doing a device.New()/device.UP AND > also reading wintun from my own goroutine, so two of them reading same > queue. Now that I fixed it, I am happy with 0.12. I will wait for the > next wintun release which has this memod load issue fixed (0.14 ?) and > upgrade directly to that > > Rgds, > Gopa. > > On Fri, Aug 27, 2021 at 10:11 AM Jason A. Donenfeld wrote: > > > > Update to the latest wireguard-go commit. > > https://git.zx2c4.com/wireguard-go/commit/?id=bad6caeb82edd0e22bdbcfa1ca544a5805109e14 From rm at romanrm.net Fri Aug 27 16:14:12 2021 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 27 Aug 2021 21:14:12 +0500 Subject: ipv6 connexion fail - ipv4 OK In-Reply-To: References: Message-ID: <20210827211412.3ed5f170@natsu> On Thu, 26 Aug 2021 13:14:00 +0200 Daniel wrote: > Correction > > Le 25/08/2021 ? 17:25, Daniel a ?crit?: > > Hi list, > > > > I setup wireguard on a server running Debian 11 and get it to work with > > 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on > > separate networks, one client behind a FW the other direct on Internet, > > no FW at all (VPS). > > > > With this setup and ipv4 connection to the public IP of the server, > > everything is working as expected, ipv4 as well as ipv6 are passing > > smoothly. > > > > Now I want to connect using the ipv6 address of the wg interface as both > > clients and server have ULA ipv6. > > Here is GUA to read. > > > This fail, wg show that connection is > > established but VPN is not usable. It's not a FW problem as I can ssh to > > the ipv6 address, as well as a netcat test from/to server IP -from each > > client- on an UDP port is working properly. Also, > > net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf > > > > All network stuff is done in /etc/network/interfaces which call the > > config file. The ipv6 address of the server is affected _to the > > wireguard interface_ (in ipv4 it's another interface who take care of > > the public address) > > > > Server version is wireguard-tools v1.0.20210223. > > > > If someone have any hint, thanks to share ;) > IPv6 requires the in-WG MTU to be 20 bytes less than when running over IPv4. Try reducing it accordingly. -- With respect, Roman From tech at tootai.net Fri Aug 27 17:16:21 2021 From: tech at tootai.net (Daniel) Date: Fri, 27 Aug 2021 19:16:21 +0200 Subject: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210827211412.3ed5f170@natsu> References: <20210827211412.3ed5f170@natsu> Message-ID: <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> Hi ROman Le 27/08/2021 ? 18:14, Roman Mamedov a ?crit?: > On Thu, 26 Aug 2021 13:14:00 +0200 > Daniel wrote: > >> Correction >> >> Le 25/08/2021 ? 17:25, Daniel a ?crit?: >>> Hi list, >>> >>> I setup wireguard on a server running Debian 11 and get it to work with >>> 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on >>> separate networks, one client behind a FW the other direct on Internet, >>> no FW at all (VPS). >>> >>> With this setup and ipv4 connection to the public IP of the server, >>> everything is working as expected, ipv4 as well as ipv6 are passing >>> smoothly. >>> >>> Now I want to connect using the ipv6 address of the wg interface as both >>> clients and server have ULA ipv6. >> Here is GUA to read. >> >>> This fail, wg show that connection is >>> established but VPN is not usable. It's not a FW problem as I can ssh to >>> the ipv6 address, as well as a netcat test from/to server IP -from each >>> client- on an UDP port is working properly. Also, >>> net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf >>> >>> All network stuff is done in /etc/network/interfaces which call the >>> config file. The ipv6 address of the server is affected _to the >>> wireguard interface_ (in ipv4 it's another interface who take care of >>> the public address) >>> >>> Server version is wireguard-tools v1.0.20210223. >>> >>> If someone have any hint, thanks to share ;) > IPv6 requires the in-WG MTU to be 20 bytes less than when running over IPv4. > Try reducing it accordingly. Tried 1400, 1396 and 1392, problem stay. Thanks for your help -- Daniel From mike at pineview.net Fri Aug 27 21:35:45 2021 From: mike at pineview.net (Mike O'Connor) Date: Sat, 28 Aug 2021 07:05:45 +0930 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> References: <20210827211412.3ed5f170@natsu> <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> Message-ID: <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net> Hi On a 1500 link I'm having to use 1280 to get ipv6 to successfully go over a wireguard link. I really think wireguard should be able to fragment and send via multiply UDP packets. wireguard works very well other than this issue, performance is extremely good. Mike On 28/8/21 2:46 am, Daniel wrote: > Hi ROman > > Le 27/08/2021 ? 18:14, Roman Mamedov a ?crit?: >> On Thu, 26 Aug 2021 13:14:00 +0200 >> Daniel wrote: >> >>> Correction >>> >>> Le 25/08/2021 ? 17:25, Daniel a ?crit?: >>>> Hi list, >>>> >>>> I setup wireguard on a server running Debian 11 and get it to work >>>> with >>>> 2 clients (Debian 11 and Ubuntu 20.04). Clients and server are on >>>> separate networks, one client behind a FW the other direct on >>>> Internet, >>>> no FW at all (VPS). >>>> >>>> With this setup and ipv4 connection to the public IP of the server, >>>> everything is working as expected, ipv4 as well as ipv6 are passing >>>> smoothly. >>>> >>>> Now I want to connect using the ipv6 address of the wg interface as >>>> both >>>> clients and server have ULA ipv6. >>> Here is GUA to read. >>> >>>> This fail, wg show that connection is >>>> established but VPN is not usable. It's not a FW problem as I can >>>> ssh to >>>> the ipv6 address, as well as a netcat test from/to server IP -from >>>> each >>>> client- on an UDP port is working properly. Also, >>>> net.ipv6.conf.all.forwarding=1 is activated in sysctl.conf >>>> >>>> All network stuff is done in /etc/network/interfaces which call the >>>> config file. The ipv6 address of the server is affected _to the >>>> wireguard interface_ (in ipv4 it's another interface who take care of >>>> the public address) >>>> >>>> Server version is wireguard-tools v1.0.20210223. >>>> >>>> If someone have any hint, thanks to share ;) >> IPv6 requires the in-WG MTU to be 20 bytes less than when running >> over IPv4. >> Try reducing it accordingly. > > Tried 1400, 1396 and 1392, problem stay. > > Thanks for your help > From rm at romanrm.net Fri Aug 27 21:44:54 2021 From: rm at romanrm.net (Roman Mamedov) Date: Sat, 28 Aug 2021 02:44:54 +0500 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net> References: <20210827211412.3ed5f170@natsu> <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net> Message-ID: <20210828024454.1766744f@natsu> On Sat, 28 Aug 2021 07:05:45 +0930 Mike O'Connor wrote: > On a 1500 link I'm having to use 1280 to get ipv6 to successfully go > over a wireguard link. Then it is not a true 1500 MTU link, something in-between drops packets at a lower bar. Or maybe not all of them, but just UDP, for example. But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue. As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just fine. > I really think wireguard should be able to fragment and send via > multiply UDP packets. It is able to, as long as the underlying link MTU is set to a correct value (i.e. where largest-sized packets actually go through, and not get silently dropped). -- With respect, Roman From mike at pineview.net Fri Aug 27 21:54:16 2021 From: mike at pineview.net (Mike O'Connor) Date: Sat, 28 Aug 2021 07:24:16 +0930 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210828024454.1766744f@natsu> References: <20210827211412.3ed5f170@natsu> <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net> <20210828024454.1766744f@natsu> Message-ID: <18028d40-be81-f80b-31a2-d9ba15486dff@pineview.net> root at gw:~# ping -M do -s 1472 13.17.1.2 PING 103.127.123.217 (13.17.1.2) 1472(1500) bytes of data. 1480 bytes from 13.17.1.2: icmp_seq=1 ttl=60 time=7.93 ms Link can transmit a max of 1500 bytes as seen above. Pinging a LAN segment has the same limit. ie PC to PC has the same result. Mike On 28/8/21 7:14 am, Roman Mamedov wrote: > On Sat, 28 Aug 2021 07:05:45 +0930 > Mike O'Connor wrote: > >> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go >> over a wireguard link. > Then it is not a true 1500 MTU link, something in-between drops packets at a > lower bar. Or maybe not all of them, but just UDP, for example. > > But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue. > > As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just > fine. > >> I really think wireguard should be able to fragment and send via >> multiply UDP packets. > It is able to, as long as the underlying link MTU is set to a correct value > (i.e. where largest-sized packets actually go through, and not get silently > dropped). > From tech at tootai.net Mon Aug 30 10:24:01 2021 From: tech at tootai.net (Daniel) Date: Mon, 30 Aug 2021 12:24:01 +0200 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210828024454.1766744f@natsu> References: <20210827211412.3ed5f170@natsu> <3ec547c6-c846-e5be-e276-ace7862f5cb7@tootai.net> <34d4341c-98be-b754-af8e-c7097bc21aac@pineview.net> <20210828024454.1766744f@natsu> Message-ID: <7437f3e0-26ba-5e33-a175-0cf233635b3f@tootai.net> Hi Le 27/08/2021 ? 23:44, Roman Mamedov a ?crit?: > On Sat, 28 Aug 2021 07:05:45 +0930 > Mike O'Connor wrote: > >> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go >> over a wireguard link. > Then it is not a true 1500 MTU link, something in-between drops packets at a > lower bar. Or maybe not all of them, but just UDP, for example. > > But yeah, 1280 is worth trying as well, maybe Daniel has a similar issue. > > As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying link just > fine. After lot of few testings, I think the problem is elsewhere. Setup of the server: . eth0 with one public ipv4 IP and ipv6 /64 . 2 tunnels (one gre, one sit), each of them having one ipv4 and one ipv6 /64. They take care on trafic from/to our /48 ipv6 range . 2 tun openvpn interfaces for customers with ipv6 address from our /48 range . wireguard interface with ipv6 address from our /48 range Using tcpdump -i any I see the trafic coming to the gre interface and that's all. But netstat show udp6?????? 0????? 0 :::12345 :::*??????????????????????????????? 0????????? 125391???? - and ps aux output is dh at peech:~$ ps ax|grep wg ?? 6969 ???????? I References: <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> Message-ID: On 8/30/21 1:24 PM, Daniel wrote: > Hi > > Le 27/08/2021 ? 23:44, Roman Mamedov a ?crit?: >> On Sat, 28 Aug 2021 07:05:45 +0930 >> Mike O'Connor wrote: >> >>> On a 1500 link I'm having to use 1280 to get ipv6 to successfully go >>> over a wireguard link. >> Then it is not a true 1500 MTU link, something in-between drops >> packets at a >> lower bar. Or maybe not all of them, but just UDP, for example. >> >> But yeah, 1280 is worth trying as well, maybe Daniel has a similar >> issue. >> >> As for me I am using MTU 1412 WG over IPv6 on a 1492 MTU underlying >> link just >> fine. > > After lot of few testings, I think the problem is elsewhere. Setup of > the server: > > . eth0 with one public ipv4 IP and ipv6 /64 > > . 2 tunnels (one gre, one sit), each of them having one ipv4 and one > ipv6 /64. They take care on trafic from/to our /48 ipv6 range > > . 2 tun openvpn interfaces for customers with ipv6 address from our > /48 range > > . wireguard interface with ipv6 address from our /48 range > > Using tcpdump -i any I see the trafic coming to the gre interface and > that's all. But netstat show > > udp6?????? 0????? 0 :::12345 :::* 0????????? 125391???? - > > and ps aux output is > > dh at peech:~$ ps ax|grep wg > ?? 6969 ???????? I ?? 7026 ???????? I????? 0:00 [kworker/1:2-wg-kex-wig4tootai] > > Question: is wireguard really listening on all ipv6 addresses ? If > not, how is the address choosen ? > > [...] > > Thanks for your help > Hi, I'm having to use MSS 1380 for IPv4 and MSS 1360 for IPv6 with Wireguard, and it works great. However I'm not entirely sure what the underlying link MTU actually is because WAN says 1500, but pinging with `-m DO` sometimes doesn't work like it is in fact MTU 1500 all the way. From rm at romanrm.net Mon Aug 30 16:43:12 2021 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 30 Aug 2021 21:43:12 +0500 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <7437f3e0-26ba-5e33-a175-0cf233635b3f@tootai.net> References: <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> Message-ID: <20210830214312.6a332333@natsu> On Mon, 30 Aug 2021 12:24:01 +0200 Daniel wrote: > Using tcpdump -i any I see the trafic coming to the gre interface and > that's all. But netstat show > > udp6?????? 0????? 0 :::12345 :::*??????????????????????????????? > 0????????? 125391???? - > > and ps aux output is > > dh at peech:~$ ps ax|grep wg > ?? 6969 ???????? I ?? 7026 ???????? I????? 0:00 [kworker/1:2-wg-kex-wig4tootai] > > Question: is wireguard really listening on all ipv6 addresses ? If not, > how is the address choosen ? Yes it does. You seem to have some very complex setup, I suggest to look into whether you send replies from the interface you expect them to. If you use wg-quick, maybe switch to just wg and set up manually and with careful intent of each action, as wg-quick might not have in mind some aspect of your setup. -- With respect, Roman From tech at tootai.net Mon Aug 30 17:28:11 2021 From: tech at tootai.net (Daniel) Date: Mon, 30 Aug 2021 19:28:11 +0200 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210830214312.6a332333@natsu> References: <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> Message-ID: Le 30/08/2021 ? 18:43, Roman Mamedov a ?crit?: > On Mon, 30 Aug 2021 12:24:01 +0200 > Daniel wrote: > >> Using tcpdump -i any I see the trafic coming to the gre interface and >> that's all. But netstat show >> >> udp6?????? 0????? 0 :::12345 :::* >> 0????????? 125391???? - >> >> and ps aux output is >> >> dh at peech:~$ ps ax|grep wg >> ?? 6969 ???????? I> ?? 7026 ???????? I????? 0:00 [kworker/1:2-wg-kex-wig4tootai] >> >> Question: is wireguard really listening on all ipv6 addresses ? If not, >> how is the address choosen ? > Yes it does. > > > You seem to have some very complex setup, I suggest to look into whether you > send replies from the interface you expect them to. If you use wg-quick, maybe > switch to just wg and set up manually and with careful intent of each action, > as wg-quick might not have in mind some aspect of your setup. I don't use wg-quick: interface setup is done in interfaces file and reading conf file from there. To be sure (and I think it is as I have no problem with ipv4): . my interfaces are named wig4tootai our wigserver Nothing wrong here ? . conf file are not named .conf but server.conf or anyname.conf Nothing wrong here too ? Conserning the setup, I made another one using one VPS (one public ipv4 and one ipv6 /64 range) but get the same result. No FW involved at all :( -- Daniel From rm at romanrm.net Mon Aug 30 17:38:36 2021 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 30 Aug 2021 22:38:36 +0500 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: References: <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> Message-ID: <20210830223836.5384badd@natsu> On Mon, 30 Aug 2021 19:28:11 +0200 Daniel wrote: > To be sure (and I think it is as I have no problem with ipv4): > > . my interfaces are named wig4tootai our wigserver Nothing wrong here ? > > . conf file are not named .conf but server.conf or > anyname.conf Nothing wrong here too ? Interface names are arbitrary. As for proper .conf filenames on your system, I am not sure, but you can simply check whether everything looks fine by running the "wg" tool. > Conserning the setup, I made another one using one VPS (one public ipv4 and > one ipv6 /64 range) but get the same result. No FW involved at all :( Do you get WG working at all, between some other two hosts (not involving this particular server for now)? -- With respect, Roman From tech at tootai.net Mon Aug 30 17:44:21 2021 From: tech at tootai.net (Daniel) Date: Mon, 30 Aug 2021 19:44:21 +0200 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210830223836.5384badd@natsu> References: <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> <20210830223836.5384badd@natsu> Message-ID: Le 30/08/2021 ? 19:38, Roman Mamedov a ?crit?: > On Mon, 30 Aug 2021 19:28:11 +0200 > Daniel wrote: > >> To be sure (and I think it is as I have no problem with ipv4): >> >> . my interfaces are named wig4tootai our wigserver Nothing wrong here ? >> >> . conf file are not named .conf but server.conf or >> anyname.conf Nothing wrong here too ? > Interface names are arbitrary. As for proper .conf filenames on your system, I > am not sure, but you can simply check whether everything looks fine by running > the "wg" tool. > >> Conserning the setup, I made another one using one VPS (one public ipv4 and >> one ipv6 /64 range) but get the same result. No FW involved at all :( > 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. -- Daniel From rm at romanrm.net Mon Aug 30 17:59:27 2021 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 30 Aug 2021 22:59:27 +0500 Subject: [Warning: DMARC Fail Email] Re: ipv6 connexion fail - ipv4 OK In-Reply-To: References: <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> <20210830223836.5384badd@natsu> Message-ID: <20210830225927.6df90edb@natsu> On Mon, 30 Aug 2021 19:44:21 +0200 Daniel 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. -- With respect, Roman From mdt at emdete.de Mon Aug 30 18:43:03 2021 From: mdt at emdete.de (M. Dietrich) Date: Mon, 30 Aug 2021 20:43:03 +0200 Subject: Behaviour on MTU problem Message-ID: <1630347517.szy5mrrs16.astroid@morple.none> Hi friends of Wireguard, i am neither a network guru nor a kernel hacker and after all i had no time to fully investigate the case. so please read with a grain of salt. i had my notebook in a wifi network lately that seemed to have some MTU size problems. download worked fine while uploads blocked for bigger packages. when i set the MTU down to 1200 on the wg interface the same upload worked fine. this was obviously a problem of that very wifi network and is not related to wg at all, the dhcp answer did not even contain any MTU hints, so 1500 was assumed. anyway the kernel locked up. commands like `ip` or `wg-quick down ...` get stuck and ^C oder even a `kill -9 ...` did not end the processes. any access to the wg interface blocked. my question is if that scenario (misconfigured MTU size in the "outer network") is tested and works fine. i know that MTU size problem lead to lockups (that's why i immediatly came to that conclusion) but never saw such a hard lockup related to commands like `ip`. if my assumption is just stupid let me know. if not i would further investigate the case, setup a test scenario and burn some time. what do you think? best regards, michael From sanderbauer at gmail.com Tue Aug 31 14:46:33 2021 From: sanderbauer at gmail.com (S Bauer) Date: Tue, 31 Aug 2021 16:46:33 +0200 Subject: enabling WG0 allows telegram but impedes browsing In-Reply-To: References: Message-ID: Hi all, I found some time to troubleshoot properly. Below I posted my outputs, responding to the different hints I received from several of the mailinglist subscribers. (thanks for helping) The following is with WG0 disabled. Sending a ping to google and a route to Reddit. ...:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=14.3 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=13.3 ms .......seq=3 to seq=18.... 64 bytes from 8.8.8.8: icmp_seq=19 ttl=117 time=10.1 ms 64 bytes from 8.8.8.8: icmp_seq=20 ttl=117 time=10.7 ms ^C --- 8.8.8.8 ping statistics --- 20 packets transmitted, 20 received, 0% packet loss, time 19029ms rtt min/avg/max/mdev = 9.892/15.839/90.310/17.462 ms ...:~$ host -v reddit.com Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46050 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN A ;; ANSWER SECTION: reddit.com. 161 IN A 151.101.65.140 reddit.com. 161 IN A 151.101.193.140 reddit.com. 161 IN A 151.101.129.140 reddit.com. 161 IN A 151.101.1.140 Received 92 bytes from 127.0.0.53#53 in 15 ms Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43918 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN AAAA Received 28 bytes from 127.0.0.53#53 in 23 ms Trying "reddit.com" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32760 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;reddit.com. IN MX ;; ANSWER SECTION: reddit.com. 300 IN MX 10 aspmx2.googlemail.com. reddit.com. 300 IN MX 10 aspmx3.googlemail.com. reddit.com. 300 IN MX 5 alt2.aspmx.l.google.com. reddit.com. 300 IN MX 5 alt1.aspmx.l.google.com. reddit.com. 300 IN MX 1 aspmx.l.google.com. Received 158 bytes from 127.0.0.53#53 in 15 ms ...:~$ mtr -n reddit.com My traceroute [v0.94] ... (>my_IP<) -> reddit.com 2021-08-31T14:27:10+0200 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.160.243.129 0.0% 3 11.1 8.4 4.4 11.1 3.5 >my_ip< 2. 10.160.243.129 0.0% 3 11.8 11.4 11.1 11.8 0.4 3. 212.142.52.193 0.0% 2 14.7 12.9 11.1 14.7 2.6 4. 213.51.7.90 0.0% 2 12.3 10.9 9.5 12.3 2.0 5. 213.51.64.58 0.0% 2 31.0 27.6 24.1 31.0 4.9 6. 213.46.191.170 0.0% 2 12.8 11.4 10.1 12.8 1.9 7. 151.101.1.140 0.0% 2 10.8 10.6 10.4 10.8 0.2 ...:~$ ip route show default via >my_ip< dev wlp0s20f3 proto dhcp metric 600 >my_ipmy_ipmy_ip< metric 600 The following is with WG0 enabled, let's see where things mess up. ..:~$ sudo wg-quick up wg0 [#] ip link add wg0 type wireguard [#] wg setconf wg0 /dev/fd/63 [#] ip -4 address add (hidden)/.. dev wg0 [#] ip link set mtu 1420 up dev wg0 [#] ip -6 route add ::/0 dev wg0 table 51820 [#] ip -6 rule add not fwmark 51820 table 51820 [#] ip -6 rule add table main suppress_prefixlength 0 [#] ip6tables-restore -n [#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820 [#] ip -4 rule add not fwmark 51820 table 51820 [#] ip -4 rule add table main suppress_prefixlength 0 [#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 [#] iptables-restore -n ...:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 11 packets transmitted, 0 received, 100% packet loss, time 10244ms ...:~$ host -v reddit.com Trying "reddit.com" ;; connection timed out; no servers could be reached ...:~$ mtr -n reddit.com no output ...:~$ ip route show default via >my_ip< dev wlp0s20f3 proto dhcp metric 600 >my_ipmy_ip< >my_ipmy_ipmy_ip< metric 600 So, apparently all fails when WG0 is enabled without any changes to the MTU. Per advice from Roman I reduced the MTU to 1400. ...:~$ sudo ifconfig wg0 mtu 1400 up Double checking by performing ...:~$ ip a ...... 5: wg0: mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet .../.. scope global wg0 valid_lft forever preferred_lft forever But even with the MTU lowered I get the following output. ...:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 17 packets transmitted, 0 received, 100% packet loss, time 16370ms Trying even lower MTU. ...:~$ sudo ifconfig wg0 mtu 1200 up (I also performed this step with ...:~$ sudo ip link set mtu 1200 up dev wg0 and confirmed with ip a But this method did not produce a different result) ...:~$ ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. ^C --- 8.8.8.8 ping statistics --- 23 packets transmitted, 0 received, 100% packet loss, time 22521ms ...:~$ mtr -n reddit.com no output Am I missing something here? Sander Op do 26 aug. 2021 om 09:40 schreef S Bauer : > > Thank you all for the insights about MTU settings, DNS and routing. > I am a bit caught up in work with important deadlines but will test all your advice soon as possible and inform everyone on the outcomes. > > Regards > Sander > > Chris ccc: >> >> If I understand it right, everything seems fine BUT once wg is up you cannot >> reach e.g. other websites. >> Therefore you you try to track the route to say reddit. Command line: >> >> mtr -n reddit.com >> >> and then you will see at what point the data transport to reddit gets stuck. >> >> Also check (command line) >> >> host -v reddit.com >> >> to check on the correct DNS working. >> >> Chris >> >> >> On 20/08/2021 13:16, S Bauer wrote: >> > Hello team, >> > >> > Hoping you could help me out with a foggy situation. >> > The past week I have been struggling to get the Wireguard VPN working >> > smoothly. Everything seems to work on paper, except in a specific way >> > it doesn't. I am using Pop!_OS 21.04 (Ubuntu Hirsute). >> > >> > SitRep; >> > I work as a freelance consultant and want to be careful about the >> > local networks' peeping tom when accessing sensitive work documents >> > from 'out of office', e.g. at a friend's place or at a hotel. So my >> > objective is to access my home network via PiHole and then continue >> > onward to access my work-related documents on a fileserver. >> > I was hoping this could be easily achieved with Wireguard. >> > >> > Using the Wireguard VPN wg0 with wg-quick worked perfectly when I >> > connected to my brother's phone hotspot (4G). I could access our home >> > via VPN as expected and could work on my documents without any >> > problems. >> > The trouble is that I am now at a different location, working with a >> > fixed router from Ziggo NL. For some reason the WG0 still connects >> > perfectly, but after that a small mystery occurs. I did not make any >> > modifications to WG0.conf, so I remain stumped. >> > With WG active, I am no longer able to access any webpage. So no >> > access to protonmail\gmail, reddit or anything else. Telegram, >> > however, is still working fine. Internal machines on the home's local >> > network (IP-camera) can also be accessed directly. >> > Disabling the WG gives me full access to any webpage as usual. So >> > something is amiss that affects my browser only (Firefox 91.0). >> > >> > I already did some troubleshooting. Starting with Uncomplicated >> > Firewall (UFW). I tried disabling UFW and rebooting, but this did not >> > change anything. I still lacked browser access when connected with >> > WG0, but Telegram still worked fine. >> > The output from sudo wg is; >> > interface: wg0 >> > public key: (hidden) >> > private key: (hidden) >> > listening port: >> > fwmark: 0xca6c >> > >> > peer: (hidden) >> > preshared key: (hidden) >> > endpoint: >our_endpoint_name<.ddns.net:51820 >> > allowed ips: 0.0.0.0/0, ::/0 >> > latest handshake: 3 seconds ago >> > transfer: 92 B received, 4.77 KiB sent >> > >> > To be on the safe side, I added several rules to UFW (and reloaded UFW >> > each time) per advice from >> > https://jianjye.medium.com/how-to-fix-no-internet-issues-in-wireguard-ed8f4bdd0bd1 >> > , leaving me with the following output from ufw status verbose. (But >> > like I said, the problem occurs even with UFW disabled.) >> > Status: active >> > Logging: on (low) >> > Default: deny (incoming), allow (outgoing), deny (routed) >> > New profiles: skip >> > >> > To Action From >> > -- ------ ---- >> > Anywhere/udp on wg0 ALLOW IN Anywhere/udp >> > /udp ALLOW IN Anywhere >> > /udp ALLOW IN Anywhere >> > /udp on wlp0s20f3 ALLOW IN Anywhere >> > Anywhere/udp on wlp0s20f3 ALLOW IN Anywhere/udp >> > on wlp0s20f3 ALLOW IN Anywhere >> > Anywhere/udp (v6) on wg0 ALLOW IN Anywhere/udp (v6) >> > /udp (v6) ALLOW IN Anywhere (v6) >> > /udp (v6) ALLOW IN Anywhere (v6) >> > /udp (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) >> > Anywhere/udp (v6) on wlp0s20f3 ALLOW IN Anywhere/udp (v6) >> > (v6) on wlp0s20f3 ALLOW IN Anywhere (v6) >> > >> > Anywhere on eth0 ALLOW FWD Anywhere on wg0 >> > Anywhere on wg0 ALLOW FWD Anywhere on eth0 >> > Anywhere on wg0 ALLOW FWD Anywhere on enp40s0 >> > Anywhere on enp40s0 ALLOW FWD Anywhere on wg0 >> > Anywhere on wlp0s20f3 ALLOW FWD Anywhere on wg0 >> > Anywhere on wg0 ALLOW FWD Anywhere on wlp0s20f3 >> > Anywhere (v6) on eth0 ALLOW FWD Anywhere (v6) on wg0 >> > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on eth0 >> > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on enp40s0 >> > Anywhere (v6) on enp40s0 ALLOW FWD Anywhere (v6) on wg0 >> > Anywhere (v6) on wlp0s20f3 ALLOW FWD Anywhere (v6) on wg0 >> > Anywhere (v6) on wg0 ALLOW FWD Anywhere (v6) on wlp0s20f3 >> > >> > Now all these rules may be barbaric overkill, and yes I will admit >> > that I have a limited understanding of what everything means and how >> > it affects my security. Though I am a linux newcomer and employ >> > duckduckgo to the best of my abilities the learning curve is still >> > pretty much in effect. That being said, do feel free to point out any >> > serious flaws I may have unwittingly introduced or simply push me >> > towards some longreads ;) >> > >> > Any hints on solving this issue are appreciated. >> > >> > >> > Additional notes; >> > * the DDNS in wg0.conf is properly translated to an IP address each >> > time. So that seems to be no issue. >> > * I am currently using the Dutch Ziggo network, which already seems to >> > have a reputation concerning the use of VPN applications. Maybe the >> > issue lies herein? >> > * Should I consider this relevant? > >> > https://github.com/pop-os/pop/issues/773 I am a bit cautious about >> > doing more random stuff before actually understanding what is going >> > on. >> > >> > Regards, >> > Sander >> >> From tech at tootai.net Tue Aug 31 17:50:16 2021 From: tech at tootai.net (Daniel) Date: Tue, 31 Aug 2021 19:50:16 +0200 Subject: ipv6 connexion fail - ipv4 OK In-Reply-To: <20210830225927.6df90edb@natsu> References: <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> <20210830223836.5384badd@natsu> <20210830225927.6df90edb@natsu> Message-ID: Hi Le 30/08/2021 ? 19:59, Roman Mamedov a ?crit?: > On Mon, 30 Aug 2021 19:44:21 +0200 > Daniel 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 ;) -- Daniel From kassemomega at gmail.com Mon Aug 30 13:19:46 2021 From: kassemomega at gmail.com (Kassem Omega) Date: Mon, 30 Aug 2021 09:19:46 -0400 Subject: Suggestion for WireGuard Message-ID: 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 art at botterell.net Mon Aug 30 19:55:26 2021 From: art at botterell.net (Art Botterell) Date: Mon, 30 Aug 2021 12:55:26 -0700 Subject: Behaviour on MTU problem In-Reply-To: <1630347517.szy5mrrs16.astroid@morple.none> References: <1630347517.szy5mrrs16.astroid@morple.none> Message-ID: <08C6DA98-A534-451D-9007-FF8627C48065@gmail.com> Hi Michael, One reads about fragmentation-induced failures and about various MTU values that did or didn't work in a particular situation. We can infer a certain amount from the stories, but I haven?t seen any sort of systematic characterization of the phenomenon. Seems like it might be a good research project for somebody. Please note, however, that I?m glad to be schooled if there?s a resource on the topic that I?ve overlooked. Personally I?d be very interested in understanding what we could look out for in order automatically to detect MTU issues and adapt to the particular demands of a remote installation on complex host networks that may have fragmentation-inducing devices (or protocols, e.g., PPPoS) on the route to the Internet that we don?t control or even know about. My inference from what I?ve read is that for any particular network route there is some maximum MTU value that will work without fragmentation. (I think there may be some practical lower limit on the MTU setting, down around 1200 somewhere, but I?m not sure what that is or what it stems from.) My experience has been that the maximum MTU value looking toward the WG host can vary from host-network to host-network and even from time to time (e.g., one organization made some network changes related to COVID that incidentally reduced the critical MTU and knocked me off the air.) Is there some sort of a ?fragtest? network utility out there? An inelegant approach might be to have each client iterate downward over a range of MTU values and test the connection to the server each time. But I hope a deeper understanding may reveal a more efficient approach for deployment. Regards, Art > On Aug 30, 2021, at 11:43, M. Dietrich wrote: > > Hi friends of Wireguard, > > i am neither a network guru nor a kernel hacker and after all > i had no time to fully investigate the case. so please read > with a grain of salt. > > i had my notebook in a wifi network lately that seemed to have > some MTU size problems. download worked fine while uploads > blocked for bigger packages. when i set the MTU down to 1200 > on the wg interface the same upload worked fine. > > this was obviously a problem of that very wifi network and is > not related to wg at all, the dhcp answer did not even contain > any MTU hints, so 1500 was assumed. > > anyway the kernel locked up. commands like `ip` or `wg-quick > down ...` get stuck and ^C oder even a `kill -9 ...` did not > end the processes. any access to the wg interface blocked. > > my question is if that scenario (misconfigured MTU size in the > "outer network") is tested and works fine. i know that MTU > size problem lead to lockups (that's why i immediatly came to > that conclusion) but never saw such a hard lockup related to > commands like `ip`. > > if my assumption is just stupid let me know. if not i would > further investigate the case, setup a test scenario and burn > some time. what do you think? > > best regards, michael From john at sys.casa Tue Aug 31 17:41:30 2021 From: john at sys.casa (john at sys.casa) Date: Tue, 31 Aug 2021 17:41:30 +0000 Subject: Invoking sendmmsg from Go. Message-ID: <03143d09-112a-d28c-f79e-d97c01f7b1d2@sys.casa> Hey folks; While reading through some of the wireguard-go source I saw there is a TODO to implement: ??? ??? // https://git.zx2c4.com/wireguard-go/tree/tun/tun_linux.go?id=3957e9b9dd19#n359 ??? ??? func (tun *NativeTun) Flush() error The note suggests using sendmmsg, which, does not seem to be implemented by the syscall package in Go. (https://github.com/golang/go/issues/9402) Given that, I was wondering if anybody knows a way to interface with sendmmsg from Go? -- Regards, John S -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - john at sys.casa - 5550f851.asc Type: application/pgp-keys Size: 3179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: