wireguard-install icon indicating copy to clipboard operation
wireguard-install copied to clipboard

error: handshake did not complete after 5 seconds

Open HuijieLin opened this issue 4 years ago • 6 comments

when disconnect in the client(iOS,Mac and windows), after some time to connect the wireGuard again, the status on the client side is success, but in the client log alway show "handshake did not complete after 5 seconds retrying(try 2)"

in this time can only need to restart the wireGuard on the vps, it there any other better solution on it?

HuijieLin avatar Oct 07 '19 04:10 HuijieLin

Try to remove presharedkey the idea is to simplify your config. And check to your journalctl or logs. (for fix a bug need to find bug information first) And if that not work try to connect with rust or go version.

liberodark avatar Dec 18 '19 14:12 liberodark

If you can connect the first time then try adding the PersistentKeepalive option to your client configuration under [Peer]

randshell avatar Jul 01 '20 18:07 randshell

If you can connect the first time then try adding the PersistentKeepalive option to your client configuration under [Peer]

@angristan can we include it by default in the config? We are using it for OpenVPN and it's commonly used for SSH too for example.

randshell avatar Jul 31 '20 20:07 randshell

Seems like a good idea!

angristan avatar Aug 03 '20 15:08 angristan

Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty.

If you don't need this feature, don't enable it.

WireGuard recommends against it in their documentation and in the Android app. Seems like a better solution adding this in a FAQ and saying that if traffic isn't send for some time from the client behind NAT a disconnection can occur.

Their exact words are:

But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.

randshell avatar Aug 04 '20 11:08 randshell

@angristan Here is what they say:

NAT and Firewall Traversal Persistence

By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives. When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT.

If you are using Starlink or any other ISP behind a CGNAT, I'd really think this option PersistentKeepalive = 25 is required, and the script shall offer the option during peer creation.

EDIT: anyway, I have issues, I'll try without the script and do it with ArchWiki.

HLFH avatar Jun 27 '23 18:06 HLFH