VPN Handshake Failed: Common Causes

You tap connect, the little spinner turns for a while, and then the app tells you the handshake failed. It is one of the least helpful error messages in networking, because it names a stage of the connection rather than a reason. The good news is that handshake failures come from a short and fairly predictable list of causes, and you can work through that list in roughly ten minutes without any technical background.

This article explains what the message actually means, how to tell which stage went wrong, and which cause to test first. If you want the theory of how the exchange works, the explainer on the VPN handshake covers it. Here the focus is on diagnosis: a failed handshake, what to try, in which order, and what not to waste time on.

What "handshake failed" really tells you

Before any of your traffic is protected, the VPN app and the VPN server have to introduce themselves. The app sends a request, the server answers, and the two sides agree on keys and settings. Only then does the tunnel open and your data start to flow through it. That introduction is the handshake. A failure means the introduction did not finish, so no tunnel was ever created.

This tells you something useful: your traffic is not travelling through a half-broken tunnel. It is simply travelling normally over your ordinary connection, unprotected, until the tunnel exists. If you were relying on the VPN for privacy on public Wi-Fi, treat a failed handshake as "no VPN right now" and avoid sensitive logins until it is fixed.

It also tells you the failure happened early. Compare this with a connection that succeeds and then drops, which is a different problem covered in why a VPN keeps disconnecting. And compare it with a tunnel that opens but gives no internet, covered in VPN connected but no internet. A handshake failure is the earliest of the three.

The handshake can break in one of four places, and the symptom often hints which:

Where it breaks	Typical symptom	Most likely cause
The request never reaches the server	Spins for 20-60 seconds, then times out	Blocked port or protocol, no real internet, firewall
The server answers but refuses you	Fails within a few seconds	Wrong username or password, pass ended
The server answers but you refuse it	Certificate or "unable to verify" wording	Wrong device date and time, a network interfering with secure traffic
Large replies get lost on the way	Hangs part way, works on other networks	MTU or fragmentation trouble

Fast failure and slow failure point in different directions. A refusal in two seconds means somebody answered and said no. A long timeout means nobody answered at all. Keep that distinction in mind through the rest of the checklist.

Cause 1: login details or an ended pass

Start here because it is the cheapest check and the most common mistake with a fresh purchase.

With XPASS, the app you connect with is VPNclient, and it signs in with the VPN username and password shown on your My Pass page. Those are not the same as the email address and one-time sign-in link you use for the XPASS website. People often type the website email into the app, or paste a password with a trailing space. Copy both values straight from My Pass, paste them, and check that no space came along at the end.

Then check validity. A prepaid pass has a fixed number of days and it starts when the account is created, not when you first connect. If the days have run out, the server will refuse the login and many apps report that as a failed handshake rather than an expired account. My Pass shows the remaining time, and the guide on how pass expiration works explains the counting. If days are left and the details are correct but it still fails, move on.

A quick test is to sign out of the app completely and sign in again, rather than just pressing connect repeatedly. Some apps keep an old session token, and a fresh sign-in replaces it.

Cause 2: the date and time on your device are wrong

This is the cause that surprises people most, and it is a real one. Secure connections rely on certificates, and every certificate has a start date and an end date. Your device checks those dates against its own clock. If the clock is wrong by more than a short margin, a perfectly valid certificate looks either "not yet valid" or "expired", and the connection is refused.

It happens more than you would expect:

• A phone that has been switched off for weeks and restarts with a stale time.
• A laptop whose clock battery has failed, so it resets to an old date after shutdown.
• A tablet set to a manual time zone while travelling, with the date flipped a day.
• A device used by a child who changed the date to get ahead in a game.

The fix takes under a minute. Open the date and time settings and switch on automatic date and time and automatic time zone. Then confirm the displayed date matches today. On a laptop, force a sync with the time server from the same screen. Try the VPN again immediately.

If you changed the clock on purpose, for example to test an app, change it back before assuming the VPN is broken.

Cause 3: the network blocks the connection

If the login is right and the clock is right, the next suspect is the network between you and the server. VPN protocols use particular ports and kinds of packets. Many hotel, school, office and cafe networks are configured to allow ordinary web browsing and little else, so a handshake sent over a blocked port is silently dropped. The app waits for an answer that will never come and eventually gives up.

The fastest test is to change networks. Switch from Wi-Fi to mobile data, or share a hotspot from a phone, and try again. The result tells you a lot:

• Works on mobile data, fails on the Wi-Fi. The Wi-Fi network is filtering. This is the most common case in hotels and offices.
• Fails on both. The problem is more likely your device, your login or your app.
• Works on the Wi-Fi at home, fails at the office. The office network has a firewall policy. If it is a company network, the IT team may have restricted VPN traffic on purpose, and that is a policy decision for them, not something to work around.

When the network is the cause, your options are to switch the connection method in the app, if it offers more than one, and to try again. The explainer on what a VPN protocol is helps you choose between the options, and the comparison of OpenVPN over TCP and UDP shows why a different transport can succeed where another is dropped. Some networks allow one kind of traffic and not another. Use only the methods listed on your My Pass page and in the app.

If it still fails on a network you do not control, such as a captive-portal hotel network, make sure you have completed the network's own sign-in page first. Open any ordinary website in a browser, accept the terms or enter the room number, and only then start the VPN. A VPN started before that page is accepted can never reach the server.

Cause 4: MTU and fragmentation trouble

This one is rarer but explains the strange cases where the handshake begins, hangs part way, and works fine on another network. MTU is the largest packet a network path will carry in one piece. A VPN adds a wrapper around each packet, so the packet gets bigger. If the path cannot carry the larger size and the "too big" message that should tell your device to shrink it gets lost, large packets vanish. A handshake includes some of the largest packets of the whole session, because certificates and key exchange data are bulky, so it is often the first thing to break.

Signs that point to MTU:

• It hangs rather than failing quickly.
• It works on mobile data or at home but not on a specific home router, fibre line or hotel network.
• Small things such as pinging work, but a real connection stalls.
• It is a router doing PPPoE or a tunnel of its own, which lowers the usable size.

The practical move is the same for most users: try a different connection method in the app, try another network, and restart your router. Router restarts clear stale state surprisingly often. Only if you manage your own router should you consider lowering its MTU, and then in small steps with a note of the original value.

Cause 5: conflicts with other software

Something else on the device can interfere with the handshake. The usual suspects are:

• A second VPN or proxy. Two tunnel apps fight over the same network adapter. Quit the other one fully, not just disconnect it.
• A firewall or security suite. Some block unknown adapters or outgoing traffic from new apps. The guide on VPN and Windows Firewall shows how to check that the app is allowed through.
• A system-wide filter. Parental controls, ad-blocking DNS profiles and corporate device-management profiles can intercept or reroute traffic. Remove a profile only if you installed it yourself and know what it does.
• An outdated app. A very old version may speak a method the server no longer accepts. Update from the official store or the download page.

To test for conflicts without guessing, restart the device and open only the VPN app before anything else. If it connects now, a startup program was in the way. Add your other tools back one at a time.

A ten-minute checklist, in order

Work through this list from the top and stop when the VPN connects. The order is by cost and likelihood, not by importance.

1. Cancel the attempt if it has spun for more than thirty seconds. Waiting longer rarely helps.
2. Open a normal website. Confirm you have real internet, and that you accepted any Wi-Fi sign-in page.
3. Check the pass on My Pass: days left and the exact username and password.
4. Sign out of the VPN app, sign back in with pasted values, and try once.
5. Turn on automatic date, time and time zone. Confirm today's date.
6. Switch from Wi-Fi to mobile data, or the reverse, and try again.
7. Change the connection method or the location in the app, if it offers them.
8. Quit any other VPN, proxy or security tool and try again.
9. Restart the device, then your router if you control it.
10. Update the app, and only then reinstall it.

If step 6 is the one that makes it work, you have learned the most valuable fact of the whole process: the network, not your account, is the problem. Write that down so that next time you reach for mobile data first.

Worked scenarios

The traveller at the airport. Maya lands at a connecting airport, joins the free Wi-Fi and opens the VPN app. It spins and fails. She opens a browser first and finds the airport's welcome page was never accepted. She taps through it, starts the app again, and it connects on the first try. The cause was ordering, not the VPN.

The student in a dorm. Ben's dorm network works for streaming and email but the VPN fails every evening. On his phone's hotspot it connects at once. The dorm Wi-Fi is dropping the packets. He changes the connection method in the app, which succeeds. If it had not, he would have used the hotspot for sensitive tasks and let the network team know.

The laptop that was in a drawer. Priya's old laptop was unused for three months. She installs the app, signs in, and gets a handshake failure with a certificate wording. The system clock reads a date months in the past because the clock battery is flat. She enables automatic time, the clock jumps forward, and the next attempt works.

The new purchase. Somchai buys a pass and pastes his website email into the app. It fails in two seconds, which is the quick refusal pattern. He opens My Pass, copies the VPN username and password, and signs in. Done in a minute.

Common mistakes

• Reinstalling first. It feels productive, but it rarely changes the cause and wipes settings you may need.
• Tapping connect twenty times. Each attempt leaves a half-open session. Cancel, wait ten seconds, then try once.
• Assuming the server is down. Servers fail far less often than logins, clocks and Wi-Fi networks do. Test the cheap causes first.
• Disabling every protection at once. Turning off the firewall and antivirus to test makes later results impossible to interpret. Change one thing at a time, and put it back.
• Trying to defeat a company or school filter. If the network is run by an employer or school, a policy may be blocking VPNs on purpose. Ask the administrator rather than attempting to get around it.
• Not checking the pass. Many "handshake" cases are simply a pass that ended last night.

Limits and when to ask for help

Not every failure can be solved from your side. If every network fails, every device fails, the login is confirmed and the clock is right, the cause may sit with the service rather than with you. At that point gather facts before you contact support: the device and system version, the app version, the connection method you tried, the networks you tested, the exact wording of the error and the time it happened. A message that says "failed on Wi-Fi at the hotel and on mobile data at 21:40, clock automatic, login copied from My Pass" gets answered faster than "VPN broken".

Also remember that a general technical fix is not a promise. Networks differ, and a method that works in one building may fail in another. For deeper background on keeping connections stable once they work, see improving VPN connection stability, and for the broader no-connection case, the guide on when the VPN will not connect.

Summary

A failed handshake means the VPN app and server could not finish their introduction, so no tunnel was created. Work from cheapest to most involved: confirm the login details and pass validity, correct the device clock, change networks to learn whether the network is blocking you, try another connection method, remove conflicting software, and only then update or reinstall. Treat fast failures as refusals and slow ones as blocked paths. If you want a prepaid pass to practise on, you can look at the options on the pricing page, and the download page lists the official VPNclient apps for each device.