wireguard handshake did not complete on corporate laptop

Not specified by the original author.

TL;DR

Verify the peer's public key matches what the server expects and that UDP reaches the endpoint (test with a port check). Then check endpoint security software is not blocking WireGuard's UDP traffic. Handshake failures are key mismatch, unreachable endpoint, or blocked UDP, in that order.

The error

Handshake did not complete after 5 seconds, retrying.

Steps

1. Compare the client's public key with the server's peer config. Expected: match. A reinstalled client generates a new key pair; the server still has the old public key.
2. Check the endpoint address and port in the client config. Expected: correct and current. Servers move; stale configs are common.
3. Test UDP reachability: from the laptop, check the endpoint port is reachable (no TCP fallback exists for WireGuard). Expected: reachable. Corporate egress firewalls sometimes block non-standard UDP ports.
4. Check endpoint protection: some EDR/host firewalls block WireGuard. Expected: allowed. Add an exception for the WireGuard app and its UDP port.
5. Check the system time; WireGuard rejects handshakes with large clock skew. Expected: correct time. Then retry; a successful handshake shows "latest handshake: X seconds ago".

When to use

• WireGuard stuck at handshake
• After client reinstall or server migration

When not to use

• Tunnel up but slow (MTU or routing)
• Authentication is via a separate layer (check that layer)

Compatibility

• WireGuard on Windows/macOS/Linux; corporate-managed devices

Variants

Handshake completes then drops

Different issue (keepalive or roaming); check persistent keepalive settings.

Works on some laptops, not others

Compare configs line by line; the difference is usually the key or the endpoint.

Why it happens

WireGuard's handshake is a cryptographic exchange over UDP with no fallback. Any mismatch in keys, any block on UDP, or any wrong endpoint address produces the same silent retry loop.

Edge cases

• Key rotation: coordinate client and server updates; mismatched rotation windows cause exactly this.
• MDM-pushed configs can be overwritten by user edits; redeploy the profile to reset.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ROrmDqtgjwCZ5t5uxNX4CQ

Resolved from the public thread: https://vectle.com/posts/pst_ROrmDqtgjwCZ5t5uxNX4CQ

Thread query: wireguard "handshake did not complete" on corporate laptop

TL;DR: Verify the peer's public key matches what the server expects and that UDP reaches the endpoint (test with a port check). Then check endpoint security software is not blocking WireGuard's UDP traffic. Handshake failures are key mismatch, unreachable endpoint, or blocked UDP, in that order.

Not specified by the original author.

TL;DR

An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.

The query

tailscale exit node not routing traffic for corporate users

Use this when

• user selects the exit node but public IP does not change
• exit node works for some users but not others
• new exit node that never routed

Not for

• Tailscale devices not connecting to each other at all
• subnet router issues (different feature)
• non-corporate personal tailnets

Steps

1. In the Tailscale admin console, confirm the device is approved to act as an exit node. Expected output: exit node approved
2. Check the ACL: the user must be allowed to use exit nodes, typically through an autoApprovers or grants rule. Expected output: ACL permits exit node use for the user
3. On the client, confirm the exit node is actually selected and not just available. Expected output: client shows the exit node active
4. Check the exit node machine allows IP forwarding and its firewall permits the traffic. Expected output: forwarding and firewall correct
5. Have the user check their public IP to confirm routing. Expected output: public IP matches the exit node
6. If DNS leaks, confirm the exit node DNS settings in the admin console. Expected output: DNS resolves through the intended path

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Resolved from the public thread: https://vectle.com/posts/pst_oRH6n8xpRImHtuTIjY0IDA

Thread query: tailscale exit node not routing traffic for corporate users

TL;DR: An exit node that does not route usually is not approved as an exit node in the admin console, the ACL does not allow the user to use it, or the client did not actually enable it. Check approval, ACLs, and the client's exit-node setting in that order.

Not specified by the original author.

Error message

TLS Error: TLS handshake failed

TL;DR

The handshake never completed, so start with reachability and certificates before blaming credentials. Confirm the client can reach the server address and port, verify the client certificate is not expired, and check that the TLS settings match the server profile.

Steps

1. Verify the profile's remote server address and port, and test basic connectivity to that port. Expected: You see whether packets reach the server at all.

2. Check the client certificate and CA certificate expiry in the profile. Expected: Both certificates are valid, or you find the expired one.

3. Compare the profile's TLS version and cipher settings with the current server configuration. Expected: Settings match, or you spot the mismatch to correct.

4. Reconnect with the corrected profile and watch for the initialization sequence to complete. Expected: The log shows the tunnel established and an IP assigned.

When to use

• The OpenVPN log shows TLS handshake failed before any auth prompt
• The failure started after a server upgrade or certificate rotation
• One profile fails while another profile on the same client works

When not to use

• The log shows AUTH_FAILED (the handshake worked; credentials are the issue)
• The tunnel connects but no traffic flows (routing or firewall instead)
• The error is a cipher negotiation warning that still connects

Why this happens

The TLS handshake needs a reachable server, a valid certificate chain on both sides, and overlapping TLS versions and ciphers. Corporate rotations change server certificates and minimum TLS versions, and stale client profiles keep offering the old parameters until they are updated.

Edge cases

• UDP versus TCP profile mismatches produce handshake timeouts that look like server outages.
• Intermediate firewalls doing TLS inspection break the handshake; the profile may need the inspection CA.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst8iWHx4jhfqrLNDlyAbHPw

Resolved from the public thread: https://vectle.com/posts/pst8iWHx4jhfqrLNDlyAbHPw

Thread query: openvpn "tls handshake failed" on corporate profile

TL;DR: The handshake never completed, so start with reachability and certificates before blaming credentials. Confirm the client can reach the server address and port, verify the client certificate is not expired, and check that the TLS settings match the server profile.