OpenVPN - TLS key negotiation failed to occur within 60 seconds

Question

I'm having troubling connecting to my home VPN via my laptop which is connected to a mobile hotspot.

The client OpenVPN log is as follows:

trevor@xps:~$ sudo openvpn --config ~/dev/net/vpn/vpn.sears.network.ovpn 
[sudo] password for trevor: 
Wed Aug 22 11:53:55 2018 OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Jul 18 2017
Wed Aug 22 11:53:55 2018 library versions: OpenSSL 1.0.2l  25 May 2017, LZO 2.08
Wed Aug 22 11:53:55 2018 WARNING: you are using user/group/chroot/setcon without persist-tun -- this may cause restarts to fail
Wed Aug 22 11:53:55 2018 WARNING: you are using user/group/chroot/setcon without persist-key -- this may cause restarts to fail
Wed Aug 22 11:53:55 2018 TCP/UDP: Preserving recently used remote address: [AF_INET]97.83.39.84:1194
Wed Aug 22 11:53:55 2018 UDP link local (bound): [AF_INET][undef]:1194
Wed Aug 22 11:53:55 2018 UDP link remote: [AF_INET]97.83.39.84:1194
Wed Aug 22 11:53:55 2018 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Wed Aug 22 11:54:55 2018 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Wed Aug 22 11:54:55 2018 TLS Error: TLS handshake failed
Wed Aug 22 11:54:55 2018 SIGUSR1[soft,tls-error] received, process restarting
^CWed Aug 22 11:54:59 2018 SIGINT[hard,init_instance] received, process exiting

Server and client info:

Server Info:
    OS: CentOS 7
    OpenVPN version: 2.4.6

Client Info:
    OS: Debian 9
    OpenVPN version: 2.4.0

From the server's local network:

trevor@xps:~$ sudo nmap -sU -p 1194 192.168.2.104
[sudo] password for trevor: 

Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-22 16:23 EDT
Nmap scan report for 192.168.2.104
Host is up (0.0049s latency).
PORT     STATE    SERVICE
1194/udp filtered openvpn
MAC Address: 1E:FB:74:5F:D6:C5 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 0.66 seconds

Over the internet/through the hotspot:

trevor@xps:~$ sudo nmap -sU -p 1194 vpn.sears.network
[sudo] password for trevor:

Starting Nmap 7.40 ( https://nmap.org ) at 2018-08-22 16:27 EDT
Nmap scan report for vpn.sears.network (97.83.39.84)
Host is up (0.088s latency).
rDNS record for 97.83.39.84: 97-83-39-84.dhcp.trcy.mi.charter.com
PORT     STATE    SERVICE
1194/udp filtered openvpn

Nmap done: 1 IP address (1 host up) scanned in 0.83 seconds

On the server:

[root@vpn ~]# netstat -uapn | grep openvpn
udp    0    0 192.168.2.104:1194    0.0.0.0:*                  14096/openvpn

And I have a forwarding rule setup on the router:

External 97.83.39.84:1194 --> Internal 192.168.2.104:1194

My server configuration file can be found here.

My client configuration file can be found here.

And as it stands I haven't been able to connect at all to the vpn, as you see in the log above. Does anyone know what might be going on here?

Answer 1

You're missing a line in the client file:

cipher AES-256-CBC

I think that's the only problem you've got, the rest of the server and client configuration looks fine, according to the documentation. My configs are somewhat different so I can't directly compare however...

With regards to your port test, nmap will not give you any useful information unfortunately. It will send an empty UDP packet to that port in the hope that the service running will reply; in the case of OpenVPN it won't. As far as nmap is concerned the port could be open, or silently dropping packets. All we know is that you're not rejecting (i.e. with iptables) connections because there's no ICMP unreachable message. As UDP is stateless there's no opening of a TCP connection regardless of the service running, so it just uses a hit-and-hope packet. Nmap is protocol aware, so for example if you scan port 53 it actually sends DNS server status request query (0x1000) to which it should get a reply, but there's no equivalent "are you alive" OpenVPN request, for obvious reasons.

Before testing through your the internet change the client config to

remote 192.168.2.104 1194 udp

to see if you can connect locally, just to be sure.

If you're still having problems then it's worth checking that you've gone about certificate generation sensibly too.

HTH!