OpenVPN issue - TLS key negotiation failed to occur within 60 seconds
Solution 1:
What's interesting is how the port number changes mid-stream:
Mon Mar 21 11:11:47 2016 XX.XX.XX.XX:57804 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:57804, sid=fdf7a7ac 0264c7f3
Mon Mar 21 11:12:38 2016 XX.XX.XX.XX:55938 TLS: Initial packet from [AF_INET]XX.XX.XX.XX:55938, sid=1f242a3f e454a525
This makes me think that, somewhere between client and server, there is a misbehaving NAT device, a device with very short-lived state table entries, which is changing the source port number that it applies to the client's established stream, causing the server to think that two short-lived communications are in progress, instead of one continuous one.
Such devices generally only do this with UDP, so I have advised you to confirm that you are using UDP, and try TCP instead. This you have done, and found that it fixes the problem. The next step is to identify the misbehaving NAT device, hit it with a club hammer, and replace it with one that doesn't make the cardinal mistake of assuming that all UDP communications are ephemeral; but you have indicated that you're happy with changing to TCP as a workaround, and so the matter is concluded.
Solution 2:
This is one of the most common error in setting up Openvpn and there is a FAQ entry for this. I'm going to quote this here:
TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other.
This is almost a result of:
- A perimeter firewall on the server's network is filtering out incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port number 1194).
- A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194. Be aware that many OSes will block incoming connections by default, unless configured otherwise.
- A NAT gateway on the server's network does not have a port forward rule for TCP/UDP 1194 to the internal address of the OpenVPN server machine.
- The OpenVPN client config does not have the correct server address in its config file. The remote directive in the client config file must point to either the server itself or the public IP address of the server network's gateway.
- Another possible cause is that the windows firewall is blocking access for the openvpn.exe binary. You may need to whitelist (add it to the "Exceptions" list) it for OpenVPN to work.
It's highly likely that any of these is causing the same problem in your case too. So just go through the list one by one to resolve it.
Ref: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Solution 3:
I was getting TLS key negotiation timeouts like this. But in my case I realised that the remote link was a local IP address.
The VPN on our pfSense firewall had mistakenly been put on the LAN interface instead of the WAN interface, and so the exported config was set to try and connect to the firewall's LAN IP address - which was never going to work with the client naturally being on a different LAN.
I think the main takeaways from this are:
Getting a key negotiation timeout does not necessarily mean you've even managed to connect to anything.
So at this stage it may still be worth checking you're actually connecting to the right place, and there are no firewall rules blocking the connection, etc. Particularly if your configuration has been automatically generated.
Note that getting a login prompt does not mean that you're connected, since OpenVPN asks for your credentials before trying to connect.
Make sure your VPN server is listening on the right interface.
(Of course, this is one of a number of server-side misconfigurations that could occur, such as firewall rules, putting the wrong port number, intermixing TCP and UDP, etc.)