Troubleshooting OpenVPN

Inspect the OpenVPN Logs

One of the first steps in case of problems should be to check the OpenVPN logs. The web-interface provides also OpenVPN logs fundable in logs --> System Logs under the "settings" in the "Section" "OpenVPN", in here all OpenVPN connections are displayed. If a connection is to be considered specifically, for this purpose you can also use the Console. The following commands might be useful.

Simple output:

grep "<Connection Name>" /var/log/messages

Roadwarrior specifics:

grep "openvpn" /var/log/messages

Net-to-Net connections:

grep "n2n" /var/log/messages

Reads the log regularly, and outputs all the new lines:

tail -f /var/log/messages | grep <Connection Name>

Roadwarrior specifics:

tail -f /var/log/messages | grep openvpn

Net-to-Net connections:

tail -f /var/log/messages | grep n2n

Example

Like this Net-to-Net log, a log in verbose mode 3 with a successful connection could look similarly:

ipfire Testn2n[21019]: OpenVPN 2.2.1 i586-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 19 2011
ipfire Testn2n[21019]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
ipfire Testn2n[21019]: Diffie-Hellman initialized with 1024 bit key
ipfire Testn2n[21019]: LZO compression initialized
ipfire Testn2n[21019]: Control Channel MTU parms [ L:1558 D:138 EF:38 EB:0 ET:0 EL:0 ]
ipfire Testn2n[21019]: Socket Buffers: R=[114688->131072] S=[114688->131072]
ipfire Testn2n[21019]: ROUTE default_gateway=192.168.2.1
ipfire Testn2n[21019]: TUN/TAP device tun0 opened
ipfire Testn2n[21019]: TUN/TAP TX queue length set to 100
ipfire Testn2n[21019]: /sbin/ip link set dev tun0 up mtu 1500
ipfire Testn2n[21019]: /sbin/ip addr add dev tun0 local 10.75.40.1 peer 10.75.40.2
ipfire Testn2n[21019]: /sbin/ip route add 192.168.10.0/24 via 10.75.40.2
Sep 13 17:49:15 ipfire Testn2n[21019]: Data Channel MTU parms [ L:1558 D:1450 EF:58 EB:135 ET:0 EL:0 AF:3/1 ]
ipfire Testn2n[21019]: Local Options hash (VER=V4): 'd6ea7000'
ipfire Testn2n[21019]: Expected Remote Options hash (VER=V4): '69e551db'
ipfire Testn2n[21033]: GID set to nobody
ipfire Testn2n[21033]: UID set to nobody
ipfire Testn2n[21033]: UDPv4 link local (bound): [undef]:5316
ipfire Testn2n[21033]: UDPv4 link remote: 90.23.xx.xx:5316
ipfire Testn2n[21033]: TLS: Initial packet from 90.23.xx.xx:5316, sid=fcd82b07 1d6c537a
ipfire Testn2n[21033]: VERIFY OK: depth=1, /C=DE/ST=BW/L=JBerlin/O=ipfire/OU=Freetime/CN=ipfire_CA/emailAddress=xxx@xxx.de
ipfire Testn2n[21033]: VERIFY OK: depth=0, /C=DE/ST=BW/O=ipfire/CN=ipfire
ipfire Testn2n[21033]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
ipfire Testn2n[21033]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ipfire Testn2n[21033]: Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
ipfire Testn2n[21033]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
ipfire Testn2n[21033]: Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
ipfire Testn2n[21033]: [ipfire] Peer Connection Initiated with 90.23.xx.xx:5316
ipfire Testn2n[21033]: Initialization Sequence Completed

In which case the last line:

ipfire Testn2n[21033]: Initialization Sequence Completed

says that the tunnel is initialized and thus in mostly cases built up.

A small collection of possible error reports

Appears when the port is already in use. Thus the port should be changed.

ipfire n2n[10181]: TCP/UDP: Socket bind failed on local address [undef]:1195: Address already in use
ipfire n2n[10181]: Exiting

The fragment is active on one side but not on the other. Adjustments should be made on both sides.

ipfire n2n[31761]: Initialization Sequence Completed
ipfire n2n[31761]: FRAG_IN error flags=0xfa2a187b: FRAG_TEST not implemented

Appears when the same subnet is used on both sides. Take care not to use the same subnets on both sides.

ipfire n2n[1371]: WARNING: potential route subnet conflict between local LAN [192.168.2.0/255.255.255.0] and remote VPN [192.168.2.0/255.255.255.0]

If no "Initialization Sequence Completed" appears at the end of the log after the start of the connection, but a similar output to this, is this often a firewall problem or OpenVPN aren't activated.

ipfire n2n[8475]: Expected Remote Options hash (VER=V4): '55b6c0d9'
ipfire n2n[8475]: UDPv4 link local (bound): [undef]:5317
ipfire n2n[8475]: UDPv4 link remote: 97.44.xx.xx:5317

Or if there is an e.g. upstream router/firewall before IPFire located, the port 5317 UDP should be forwarded.

Is mostly a problem with the outgoing firewall mode 1.

ipfire n2n[8142]: write UDPv4 []: Operation not permitted (code=1)

In that case, accept the connection in the outgoing Firewall rule.

The MTU setting is not equal on both sides.

ipfire n2n[8389]: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1562', remote='link-mtu 1558'
ipfire n2n[8389]: WARNING: 'mtu-dynamic' is present in local config but missing in remote config, local='mtu-dynamic'

in conjunction with the next message -->

--> this is usually a corrupt fragment adjustment and should be checked and adjusted on both sides.

ipfire n2n[8389]: Initialization Sequence Completed
ipfire n2n[8389]: FRAG_IN error flags=0xfa450804: spurrious FRAG_WHOLE flags
ipfire n2n[8389]: FRAG_IN error flags=0xfa450004: spurrious FRAG_WHOLE flags
ipfire n2n[8389]: FRAG_IN error flags=0xfa450804: spurrious FRAG_WHOLE flags
ipfire n2n[8389]: FRAG_IN error flags=0xfa450004: spurrious FRAG_WHOLE flags
ipfire n2n[8389]: FRAG_IN error flags=0xfa450804: spurrious FRAG_WHOLE flags
ipfire n2n[8389]: Bad LZO decompression header byte: 64

If the Certificate Revocation List has been expired the following appears in server log

ipfire openvpnserver[16368]: a.b.c.d:46227 VERIFY ERROR: depth=0, error=CRL has expired: C=US, O=Tatoine, CN=LGG3
ipfire openvpnserver[16368]: a.b.c.d:46227 OpenSSL: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed
ipfire openvpnserver[16368]: a.b.c.d:46227 TLS_ERROR: BIO read tls_read_plaintext error
ipfire openvpnserver[16368]: a.b.c.d:46227 TLS Error: TLS object -> incoming plaintext read error
ipfire openvpnserver[16368]: a.b.c.d:46227 TLS Error: TLS handshake failed
ipfire openvpnserver[16368]: a.b.c.d:46227 Fatal TLS error (check_tls_errors_co), restarting

a solution is to renew the CRL . With Core 120, this should be done by IPFire itself.

MTU - Test

For possible performance problems it can be quite useful, to check the MTU settings, therefor OpenVPN offers a MTU-test. To create an empirical MTU test, it needs an additional entry in the OpenVPN configuration file before the connection starts, the following line must be added.

mtu-test

If the connection is started, the test requires approximately 3 minutes and the connection log should get a similarly output to this.

ipfire n2n[3839]: Initialization Sequence Completed
ipfire n2n[3839]: NOTE: Beginning empirical MTU test -- results should be available in 3 to 4 minutes.
ipfire n2n[3839]: NOTE: Empirical MTU test completed [Tried,Actual] local->remote=[1253,1253] remote->local=[1253,1253]

In this test the value is suggested by OpenVPN to 1253 to what can be achieved if 1253 will be written into the "fragment" line into the web-interface, also mssfix should be activated, the actual MTU value can be left in 1500.

mssfix and fragment can only be used with UDP tunnel.
During the mtu-test, the fragment should have no value and the mssfix should be disabled, "Path_MTU-Discovery" needs also to be deactivated, so the test can be performed properly.
A configuration change needs to be made on both sides of the connection.

After the test, the added "mtu-test" line should be deleted from the configuration file.

Useful tools for connection analysis

IPFire offers a number of useful tools (Addons) which are also pretty useful for OpenVPN too. Here are some links to the IPFire wiki.

tcpdump - Real time recording of the protocol header.
iftop - A tool to inspect the network traffic for the respective interfaces.
bwm-ng - A network bandwidth monitor.
MTR - Traces the way through the tunnel and gives time response.
IPTraf-ng - A console based network statistic monitoring utility.
Tshark - A network protocol analyzer.

back to OpenVPN main