This recipe will focus on the type of log messages that are typically seen when the OpenVPN configurations are fine, but the network connectivity is not. In most cases, this is due to a firewall blocking access to either the server or the client. In this recipe, we explicitly block access to the server and then try to connect to it.
Set up the client and server certificates using the first recipe from Chapter 2, Client-server IP-only Networks. For this recipe, the server computer was running CentOS 6 Linux and OpenVPN 2.3.11, and the client was running Fedora 22 Linux and OpenVPN 2.3.11. Keep the client configuration file, basic-udp-client.conf
, handy along with the configuration file, basic-udp-server.conf
, from the Server-side routing recipe from Chapter 2, Client-server IP-only Networks, as well as the client configuration file, basic-udp-client.conf
.
basic-udp-server.conf
: [root@server]# openvpn --config basic-udp-server.conf
iptables
: [root@server]# iptables -I INPUT -p udp --dport 1194 -j DROP
basic-udp-client.conf
: [root@client]# openvpn --config basic-udp-client.conf
The client will try to connect the server using the UDP protocol. After a while, a timeout will occur because no traffic is getting through and the client will restart:
... TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity) ... TLS Error: TLS handshake failed ... SIGUSR1[soft,tls-error] received, process restarting
Abort the client and stop the server.
When OpenVPN is configured to use the default UDP protocol, the client will wait for an answer from the server for 60 seconds. If no answer was received, the connection is restarted. As we are explicitly blocking UDP traffic, the timeout occurs and the client is never able to connect.
The amount of time for which the client waits for the connection to start is controlled using the following directive:
hand-window N
Here, N
is the number of seconds to wait for the initial handshake to complete. The default value is 60 seconds.
Of course, the connection can be repaired by removing the firewall rule.
One of the major differences between the UDP protocol and the TCP protocol is the way connections are established: every TCP connection is started using a TCP handshake by both the client and the server. If the handshake fails, then the connection is not established. There is no need to wait for traffic coming back from the server, as the connection itself is dropped:
... Attempting to establish TCP connection with openvpnserver:1194 [nonblock] ... TCP: connect to openvpnserver:1194 failed, will try again in 5 seconds: Connection refused
3.137.198.239