Unable to connect to OpenVPN outside LAN

Posted on

Problem :

I’ve setup OpenVPN behind a router, and port forwarded 1194. The VPN is using the subnet 10.3.15.0/24 and has 192.168.1.14 on the LAN.

It works when I’m connecting locally, or from my home network connecting to the public IP. But not on other networks I’ve tried.

I’m unable to establish a connection to the VPN and on the client I get:

Mon Apr 20 13:50:42 2015 UDPv4 link local: [undef]
Mon Apr 20 13:50:42 2015 UDPv4 link remote: [AF_INET]83.***.***.***:1194
Mon Apr 20 13:51:42 2015 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Apr 20 13:51:42 2015 TLS Error: TLS handshake failed
Mon Apr 20 13:51:42 2015 SIGUSR1[soft,tls-error] received, process restarting
Mon Apr 20 13:51:42 2015 Restart pause, 2 second(s)

I thought it could be a firewall issue, this is from my iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  10.3.15.0/24         anywhere             ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

But I’ve tried to flush the table, which did not work.
And when running tcpdump -qni any port 1194 there is some communication (in both cases):

13:44:35.936684 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14
13:44:41.043704 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.063426 IP 194.***.***.****.22955 > 192.168.1.14.1194: UDP, length 14
13:44:43.544690 IP 194.***.***.****.53929 > 192.168.1.14.1194: UDP, length 14

I also noticed something about destination port unreachable, but those errors went away.

This is my server configuration:

port 1194
proto udp
dev tun

ca openvpn_certs/host-ca.pem
cert openvpn_certs/host-cert.pem
key openvpn_certs/host-key.pem
dh openvpn_certs/dh1024.pem

server 10.3.15.0 255.255.255.0
route 10.3.15.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1 bypass-dhcp"
push "remote-gateway 10.3.15.1"

client-to-client
max-clients 20

keepalive 10 120
comp-lzo

user nobody
group nobody

persist-key
persist-tun
status /var/log/openvpn-status.log
log-append /var/log/openvpn.log

verb 11

Here’s my client configuration:

client
dev vpn
dev-type tun
proto udp
remote server.remote 1194
resolv-retry infinite
nobind
ns-cert-type server
persist-key
persist-tun
pull
ca certs/ca-host.pem
cert certs/cert-local.pem
key certs/key-local.pem
comp-lzo
verb 11

The server runs Alpine linux while the client runs Gentoo.

I’m stuck and have no idea where to look, any ideas or guidance?

Thanks!

Solution :

First of all, I’m not sure which version of OpenVPN you are using, but ‘remote-gateway’ is not a valid option in v2.3.2. If you’re using an older version, check your local man page and remove that directive if necessary.


According to the OpenVPN wiki, the error “TLS key negotiation failed…” is almost always a result of:

  1. A perimeter firewall on the server’s network is filtering out
    incoming OpenVPN packets (by default OpenVPN uses UDP or TCP port
    number 1194).

    • This seems unlikely in your case, but check your router’s firewall just to be sure.
  2. A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194.

    • The filter table you provided looks fine, assuming you normally have the default INPUT policy set to accept. Otherwise, you need to allow UDP port 1194:

      iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
      
  3. 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.

  4. 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.

  5. 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.


If you still have problems, there is likely an issue with your Public Key Infrastructure. I’m not familiar with Alpine linux and whether their OpenVPN package comes with easy-rsa, so go ahead and download the latest release and extract it to an appropriate location on both your server, and, a (preferably) non-network-connect machine (your Certificate Authority). For simplicity, I’ll assume that your server is generating requests for clients. On both systems, change to the directory where you extracted EasyRSA and…

cp vars.example vars
editor ./vars

On the CA system, uncomment and edit the organizational fields accordingly (EASYRSA_REQ_COUNTRY, etc.). On the server, optionally change “set_var EASYRSA_PKI” so it points to an appropriate location (e.g. /etc/openvpn/pki).

Generate certificate requests on the server:

./easyrsa init-pki
./easyrsa gen-req <your_server_name> nopass
./easyrsa gen-req <some_client_name> nopass

On the non-server, create a new CA:

./easyrsa init-pki
./easyrsa build-ca

Copy the .req files to your CA system, then import and sign them:

./easyrsa import-req server /tmp/<your_server_name>.req
./easyrsa import-req client /tmp/<some_client_name>.req
./easyrsa sign-req server <your_server_name>
./easyrsa sign-req client <some_client_name>

Copy the newly signed certificates, as well as the CA certificate, to an appropriate location on the server and client. Then, on the server, generate dh params:

 ./easyrsa gen-dh

Finally, copy the client key to the client machine (if its not already there), and update your configurations with the new key and certificate locations.


Ensure that your server’s certificate was signed with the nsCertType=server designation (this is depreciated and not the default if you used easyrsa3). If not, the ‘ns-cert-type server’ directive in your client config would cause the tls handshake to fail. Use ‘ remote-cert-tls server’ instead.

Leave a Reply

Your email address will not be published. Required fields are marked *