algo icon indicating copy to clipboard operation
algo copied to clipboard

Published 20 hours ago • verified publisher icon trailofbits

macOS Catalina: Connection with wireguard works flawlessly and then intermittently retrying handshake and no route to host

Open Ezzahhh opened this issue 5 years ago • 24 comments

I didn't go with the a bug report because I do not believe this to be a bug with the actual configuration of Algo or Wireguard. The reason I come to this conclusion is because my setup for wireguard works perfectly on other devices (such as my Android phone). However, on my macbook pro it appears that something weird is happening, presumably related to routing, which causes my wireguard on-demand connection to intermittently "no route to host" about once everyday.

My symptoms or what happens

I generally find that it occurs after I play some sort of media like youtube or some sort of stream. Before I had algo, I had my own openvpn setup from the angristan script and it also worked fine and then would frequently no route to host after a while (but also wouldn't happen on my phone). I then moved away from openvpn thinking my configuration was broken or something and tried Algo with Wireguard. However, then the issue began reappearing. I had adjusted my tun-mtu thinking maybe that was the issue when I had openvpn but that still didn't prevent drop outs. I always appear to be connected to the internet and wireguard on my laptop will still say 'active' and airport still thinks it is connected. However, if I ping anything or traceroute there is no DNS resolution. I cannot ping ips on the internet, but I can ping my router.

This is the logs on wireguard when the drop out occurs

2019-10-31 17:13:41.399 [NET] peer(JC5l…vKik) - Sending keepalive packet
2019-10-31 17:15:12.056 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:15:12.056 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:17.366 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:17.366 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:22.598 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 3)
2019-10-31 17:15:22.598 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:27.332 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:15:27.851 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:27.851 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:32.972 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 3)
2019-10-31 17:15:32.973 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:38.307 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 4)
2019-10-31 17:15:38.307 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:42.618 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:15:43.383 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:43.383 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:48.396 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:48.396 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:53.434 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:53.434 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:15:57.982 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:15:58.532 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:15:58.533 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:03.857 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:03.857 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:08.932 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:13.222 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:16:13.989 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:13.989 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:19.222 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:19.223 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:24.318 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:24.318 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:28.656 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:16:29.522 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:29.522 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:34.599 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:39.603 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:39.627 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.755 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.770 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.776 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.846 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.876 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.898 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.930 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:39.947 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.006 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.269 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.376 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.414 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.428 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.504 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.577 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.608 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.631 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.850 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.879 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:40.950 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:41.264 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:41.374 [NET] peer(JC5l…vKik) - Failed to send data packet write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:41.417 [NET] peer(JC5l…vKik) - Awaiting keypair
2019-10-31 17:16:44.125 [NET] peer(JC5l…vKik) - Retrying handshake because we stopped hearing back after 15 seconds
2019-10-31 17:16:44.642 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:44.642 [NET] peer(JC5l…vKik) - Failed to send handshake initiation write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:49.712 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:49.713 [NET] peer(JC5l…vKik) - Failed to send handshake initiation write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:54.751 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:16:54.752 [NET] peer(JC5l…vKik) - Failed to send handshake initiation write udp4 0.0.0.0:52840->serverip:51820: sendto: no route to host
2019-10-31 17:16:59.952 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:16:59.952 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:17:05.071 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:17:10.374 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)

The weird thing is I can fix this problem immediately by turning airport on and off or forcefully deactivating the wireguard connection to reforce or try again; this leaves me to believe it has nothing to do with my actual server algovpn configuration. When this issue occurs I also try my phone which is also connected to the same Wireguard server and it will work flawlessly. These are the logs after I reactivate:

2019-10-31 17:28:15.589 [APP] startDeactivation: Tunnel: laptop-full
2019-10-31 17:28:15.592 [APP] Tunnel 'laptop-full' connection status changed to 'disconnecting'
2019-10-31 17:28:15.808 [NET] Network change detected with satisfied route and interface order [en0]
2019-10-31 17:28:15.808 [NET] Routine: receive incoming IPv6 - stopped
2019-10-31 17:28:15.808 [NET] Routine: receive incoming IPv4 - stopped
2019-10-31 17:28:15.808 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:28:15.808 [NET] Routine: receive incoming IPv4 - started
2019-10-31 17:28:15.808 [NET] Routine: receive incoming IPv6 - started
2019-10-31 17:28:15.809 [NET] UDP bind has been updated
2019-10-31 17:28:15.896 [NET] Stopping tunnel
2019-10-31 17:28:15.896 [NET] Device closing
2019-10-31 17:28:15.896 [NET] Routine: event worker - stopped
2019-10-31 17:28:20.856 [NET] peer(JC5l…vKik) - Handshake did not complete after 5 seconds, retrying (try 2)
2019-10-31 17:28:20.856 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:28:35.588 [APP] Tunnel 'laptop-full' connection status changed to 'disconnected'
2019-10-31 17:28:35.597 [APP] Tunnel 'laptop-full' connection status changed to 'connecting'
2019-10-31 17:28:35.717 [NET] App version: 0.0.20191012 (14); Go backend version: 0.0.20190909
2019-10-31 17:28:35.717 [NET] Starting tunnel from the OS directly, rather than the app
2019-10-31 17:28:35.794 [NET] Tunnel interface is utun2
2019-10-31 17:28:35.795 [NET] Attaching to interface
2019-10-31 17:28:35.795 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.795 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.795 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.795 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.795 [NET] Routine: TUN reader - started
2019-10-31 17:28:35.796 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.796 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.796 [NET] Routine: event worker - started
2019-10-31 17:28:35.796 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.796 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.797 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.798 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.798 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.798 [NET] Routine: encryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: decryption worker - started
2019-10-31 17:28:35.798 [NET] Routine: handshake worker - started
2019-10-31 17:28:35.798 [NET] UAPI: Updating private key
2019-10-31 17:28:35.798 [NET] UAPI: Removing all peers
2019-10-31 17:28:35.798 [NET] UAPI: Transition to peer configuration
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Created
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Updating preshared key
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Updating endpoint
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Updating persistent keepalive interval
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Removing all allowedips
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - UAPI: Adding allowedip
2019-10-31 17:28:35.799 [NET] Routine: receive incoming IPv6 - started
2019-10-31 17:28:35.799 [NET] Routine: receive incoming IPv4 - started
2019-10-31 17:28:35.799 [NET] UDP bind has been updated
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - Starting...
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - Routine: nonce worker - started
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - Routine: sequential receiver - started
2019-10-31 17:28:35.799 [NET] peer(JC5l…vKik) - Routine: sequential sender - started
2019-10-31 17:28:35.800 [NET] Device started
2019-10-31 17:28:35.801 [APP] Tunnel 'laptop-full' connection status changed to 'connected'
2019-10-31 17:28:36.074 [NET] peer(JC5l…vKik) - Sending handshake initiation
2019-10-31 17:28:36.075 [NET] peer(JC5l…vKik) - Awaiting keypair
2019-10-31 17:28:36.088 [NET] peer(JC5l…vKik) - Received handshake response
2019-10-31 17:28:36.088 [NET] peer(JC5l…vKik) - Obtained awaited keypair

Please let me know if there's anything else I should provide. When it happens again I can try do a netstat or whatever that may show the issue, but it's driving me crazy that it happened both on Openvpn and now Wireguard so it is clear something is clearly wrong with my network configuration on this computer. I'm thinking there also might be a connection between putting my laptop to sleep with on-demand vpn still on because the issue occurs always sometime after I close the lid and then resume use later; however, it may also be unrelated -- I have also disable power nap during sleep.

Ezzahhh avatar Nov 01 '19 11:11 Ezzahhh

There seems to be an issue with Catalina deleting tunnels arbitrarily, at least for WireGuard, with workaround in development.

TC1977 avatar Nov 01 '19 19:11 TC1977

Ah I see that would make sense. Good to know it's not something wrong with my OS specifically.

Ezzahhh avatar Nov 02 '19 04:11 Ezzahhh

Just fyi that the wireguard macos app on the app store has been updated with a fix; let's see if this fixes things.

Ezzahhh avatar Nov 06 '19 12:11 Ezzahhh

Just would like to update this issue. I am on macOS Catalina 10.15.1 and on the Wireguard macOS app version 0.0.20191105. I still get issues where the handshake just dies and it cannot be resolved without running ifconfig en0 down and up (or resetting the adapter). Same error as described in the OP with no route to host. I believe my issue is unrelated to the bug that was fixed in the latest app regarding Catalina deleting profiles. I cannot identify why no route to host will suddenly appear; it is unlikely to be a server issue because all other devices (Android and iPhone) will work at the same time as the no route to host issue occurs. This leads me to believe that there is some other issue with macOS in general or my particular installation of macOS. Due to the erratic nature of the problem, I do not deem it necessary to reinstall Catalina completely to see if it is in fact my particular installation.

Ezzahhh avatar Nov 20 '19 08:11 Ezzahhh

Another update. I am on latest Wireguard macOS app 0.0.20191105 and macOS Catalina 10.15.3. As far as I know, the issue still persists and has not been fixed.

Ezzahhh avatar Feb 22 '20 08:02 Ezzahhh

I personally suspect some issue with Wireguard working on NAT'd networks with macOS and iOS in general. Not exactly the same thing, but on a recent trip my iPhone repeatedly dropped the VPN connection when transitioning to public Wi-Fi while connected using the "Connect on Demand" feature. The fix was to connect to Wi-Fi first, then start up the WG connection manually (which is basically the same fix as you mentioned in the OP). No real rhyme or reason, as other times it would transition painlessly to the same Wi-Fi network.

TC1977 avatar Feb 22 '20 17:02 TC1977

Hmm perhaps there is a Wireguard issue, but I also feel like there is something about macOS specifically that handles the routing with tunnels badly. I had this no route to host issue with OpenVPN as well and tried multiple different clients. I also ruled out the problem being on the server-end, because Windows clients and Android didn't have the problem either.

Ezzahhh avatar Feb 23 '20 03:02 Ezzahhh

I've been experiencing something similar with Wireguard on macOS. The odd thing is that it seems to dependent on the ISP I'm on. It seems to only seems to happen when on a connection over 3G/4G. @Ezzahhh is that by chance your case too?

mentalstring avatar Apr 08 '20 14:04 mentalstring

I don't think so. The issue for me has occurred at least on two different ISPs so I doubt my issue is related. Maybe your issue is the same but just coincidence that it happens when you change your connection?

Ezzahhh avatar Apr 12 '20 01:04 Ezzahhh

@Ezzahhh For a couple of days now I am now trying a different router on the same 3G/4G connection and, so far, have not experienced any more connection freezes like I was having. Starting to suspect it may have have to do with my TPLink router (NAT implementation?), as it seems to be the only difference now.

mentalstring avatar Apr 12 '20 12:04 mentalstring

Quick reply just to add that after no freezes for days with the temporary 4g router, once returning to the old router, freezes are back. I'm lost at why the router can be the difference here. Tried enabling/disabling every router setting I could think of, but freezes remain.

I'm not sure if the issue is the same, but behaves similar: a few times a day, connection just stops working and keeps repeating handshake, until sometimes times out and it reconnects. This lasts a few minutes. Manual disconnect/connect makes the connection work immediately. No packets flow through the wireguard connection, but can ping the router just fine.

mentalstring avatar May 01 '20 10:05 mentalstring

I have been experiencing this issue intermittently, but only at one location. We have a Netgear Nighthawk X6 R8000 router there. I upgraded the router firmware from V1.0.4.58_10.1.72 to V1.0.4.62_10.1.74, and everything seemed to work normally again.

Here is the wireguard version info: Wireguard version: 0.0.20191105 (16) Go backend version: 0.0.20191013

Of course, it may have been rebooting the router that did it, or it could just be on the good side of intermittent right now, but in any event . . . fingers crossed. Deactivting wireguard or turning Wifi on/off did not work for me, but this did (at least for now.)

moonhead avatar Dec 08 '20 20:12 moonhead

One more data point. I am using wireguard version 0.0.20191105 on 10.15.6. Utilizing a VPN provider, and was making use of the 'exclude private networks' option. It worked flawlessly, for 2 months, then I rebooted my computer and it stopped working.

I have no figured out, that my current config get exactly the same message as the OP of this issue did. What I did find however, is that reverting to AllowedIPs = 0.0.0.0/0 solves this problem. Unfortunately for me, this configuration doesn't work for me, but perhaps we can find a solution with this data point?

Exact error:

peer(PEER_KEY_FOR_MY_PROVIDER) - Failed to send handshake initiation write udp4 0.0.0.0:54178->1.2.3.4:51820: sendto: network is unreachable

danielschonfeld avatar Dec 08 '20 21:12 danielschonfeld

Same here for me. On my iPhone it works, under macOS Catalina I've got the failed to send handshake initiation when sharing my connection beetween my phone and my macbook. Tried on same location with another iPhone (in the same condition) and it works ?!

lennvilardi avatar Jun 19 '22 11:06 lennvilardi

Same problem here, on macOS 13.0 with Wireguard 1.0.15 (26):

2022-11-02 14:46:10.576885: [APP] Status update notification timeout for tunnel 'q-laptop'. Tunnel status is now 'connected'.
2022-11-02 14:46:11.081151: [NET] peer(Tp16…xeEc) - Sending handshake initiation
2022-11-02 14:46:11.081738: [NET] peer(Tp16…xeEc) - Failed to send handshake initiation: write udp4 0.0.0.0:51028->111.222.333.444:51820: sendto: operation not permitted
2022-11-02 14:46:16.243912: [NET] peer(Tp16…xeEc) - Handshake did not complete after 5 seconds, retrying (try 2)
2022-11-02 14:46:16.244082: [NET] peer(Tp16…xeEc) - Sending handshake initiation
2022-11-02 14:46:16.245058: [NET] peer(Tp16…xeEc) - Failed to send handshake initiation: write udp4 0.0.0.0:51028->111.222.333.444:51820: sendto: operation not permitted
2022-11-02 14:46:21.281335: [NET] peer(Tp16…xeEc) - Sending handshake initiation
2022-11-02 14:46:21.284089: [NET] peer(Tp16…xeEc) - Failed to send handshake initiation: write udp4 0.0.0.0:51028->111.222.333.444:51820: sendto: operation not permitted
2022-11-02 14:46:26.462843: [NET] peer(Tp16…xeEc) - Handshake did not complete after 5 seconds, retrying (try 2)

If I repeatedly click Toggle Status, turning it on-and-off (20–30 times), it will eventually connect successfully. I have a hunch it is related to my ISP or router, because restarting the router, or using mobile hotspot also seems to help.

quinncomendant avatar Nov 02 '22 20:11 quinncomendant

@Ezzahhh and @lennvilardi , did you ever figure out a resolution? I am having the same issue. iPhone and iPad works but MacOS does not with the handshake error.

keanenwold avatar Nov 28 '22 19:11 keanenwold

Same Problem here on iPhone and MacBook.

iOS 16.1.2 MacOS Ventura 13.0.1

Gosuwaldbear avatar Dec 05 '22 15:12 Gosuwaldbear

Same issue (not receiving answer on the handshake), but if I disconnect and try again a few times, it will work. Independent of ISP, location, wifi, mobile — I'm travelling atm and have tried > 10 different locations, issue is same: sometimes doesn't work, retrying fixes issue always.

Macbook Air M2 Ventura 13.1 Algo hosted on Azure, installed Feb 2023

knutole avatar Feb 13 '23 06:02 knutole

For me too retrying is the key but it's quite annoying ?! Bug is still open, is there somebody investigating ?

lennvilardi avatar May 25 '23 18:05 lennvilardi

This is more likely a thing to discuss with the Wireguard community, since Algo is just a tool that installs it. Although I have never experienced this problem myself, we will be happy to implement a solution if the problem is related to the config. We'd like someone who's experiencing this problem to provide a thorough debug analysis

jackivanov avatar May 25 '23 20:05 jackivanov

Same problem here, using 13.3.1 (22E261) with Wireguard App version: 1.0.16 (27) client, and an Asus RT-AX82U router.

2023-06-04 16:44:50.182 [NET] peer(z+vP…uIGg) - Handshake did not complete after 5 seconds, retrying (try 2) 2023-06-04 16:44:50.182 [NET] peer(z+vP…uIGg) - Sending handshake initiation

No problems at all using iPhone 14 as client.

afanjul avatar Jun 04 '23 14:06 afanjul

WG Mac App: 1.0.16 (27) MacOS: 13.4 (22F66) Yup this happens with me as well, definitely a client issue. Tried to raise over at WG apple but they have issues disabled!

amroessam avatar Jun 23 '23 14:06 amroessam

WG Mac App: 1.0.16 (27) MacOS: 13.5 (22G74)

Similar problem for me too )) !

But i think problem in algo configs ! Because I make two servers in digitalocean. On one server I was installed wireguard by algo, on another server I was install wireguard by this script https://github.com/angristan/wireguard-install. And my macbook wireguard client worked perfect with wireguard-install version and not working at all with algo version ! However both servers works fine with iOS wireguard !

sintanial avatar Sep 18 '23 12:09 sintanial

@sintanial:

worked perfect with wireguard-install version and not working at all with algo version

Perhaps you can diff the wireguard config for these two servers and find what causes this problem? If you see some config is different, apply the config to the wireguard-install and test if that VPN server breaks? This will be very helpful to everyone who has this problem. 🙏

quinncomendant avatar Sep 20 '23 23:09 quinncomendant