OpenVPN – Debugging

back to OpenVPN

There are many ways for a VPN client/server setup to fail. Some are difficult to diagnose whereas others can be more straightforward.

Debug Data

Server Debug Data

The main server side logs are stored in /var/log/syslog which can be best viewed by trailing them when attempting to connect

john@ubuntu:~$ sudo tail -f /var/log/syslog

2025-03-03T13:44:01.407698+00:00 ubuntu ovpn-server[78237]: Connection Attempt MULTI: multi_create_instance called
2025-03-03T13:44:01.407955+00:00 ubuntu ovpn-server[78237]: 91.110.91.84:65054 Re-using SSL/TLS context
2025-03-03T13:44:01.408036+00:00 ubuntu ovpn-server[78237]: 91.110.91.84:65054 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
...
...

Live connections are listed in the openvpn-status.log. This can be found in /var/log/openvpn/openvpn-status.log

john@ubuntu:~$ sudo cat /var/log/openvpn/openvpn-status.log 
OpenVPN CLIENT LIST
Updated,2025-03-03 13:47:25
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
rizzo,90.10.90.80:65054,4292,4558,2025-03-03 13:44:01
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.2,rizzo,90.10.90.80:65054,2025-03-03 13:44:01
GLOBAL STATS
Max bcast/mcast queue length,1
END

The log level for the server is specified in the server.conf file with the verb directive. Increasing this level will produce a lot of logs, which may or may not be useful.

Client Debug Data

Depending on the client use, the logging data will normally presented directly in the client. For the client TunnelBlick its in the “log” tab.

Errors

These are errors I’ve seen when setting up a client/server. Some took a long time to find and were generally really frustrating!S

Misconfigured TLS – Silent Error

I mention this one first because it was an absolute bitch to find. I was tearing my hair out, and the only way I found it was line by line comparing the server configuration to a known working configuration. The logs weren’t really that helpful – just pointing out that HMAC authentication failed.

2025-03-03T13:59:57.249639+00:00 ubuntu ovpn-server[78469]: Authenticate/Decrypt packet error: packet HMAC authentication failed
2025-03-03T13:59:57.250694+00:00 ubuntu ovpn-server[78469]: TLS Error: incoming packet authentication failed from [AF_INET]91.110.91.84:52819

I checked the server will start up, and there was a hint in the logs, but not something that really stands out – I’ve grabbed the logs from restarting the server and ran grep for anything with TLS mentioned in it

2025-03-03T16:07:07.951632+00:00 ubuntu ovpn-server[79652]:   show_tls_ciphers = DISABLED
2025-03-03T16:07:07.952234+00:00 ubuntu ovpn-server[79652]:   tls_mtu = 1250
2025-03-03T16:07:07.952418+00:00 ubuntu ovpn-server[79652]:   tls_auth_file = '[INLINE]'
2025-03-03T16:07:07.952471+00:00 ubuntu ovpn-server[79652]:   tls_crypt_file = '[UNDEF]'
2025-03-03T16:07:07.952497+00:00 ubuntu ovpn-server[79652]:   tls_crypt_v2_file = '[UNDEF]'
2025-03-03T16:07:07.954961+00:00 ubuntu ovpn-server[79652]:   tls_server = ENABLED
2025-03-03T16:07:07.955037+00:00 ubuntu ovpn-server[79652]:   tls_client = DISABLED
2025-03-03T16:07:07.955308+00:00 ubuntu ovpn-server[79652]:   cipher_list_tls13 = '[UNDEF]'
2025-03-03T16:07:07.955340+00:00 ubuntu ovpn-server[79652]:   tls_cert_profile = '[UNDEF]'
2025-03-03T16:07:07.955369+00:00 ubuntu ovpn-server[79652]:   tls_verify = '[UNDEF]'
2025-03-03T16:07:07.955394+00:00 ubuntu ovpn-server[79652]:   tls_export_peer_cert_dir = '[UNDEF]'
2025-03-03T16:07:07.956062+00:00 ubuntu ovpn-server[79652]:   tls_timeout = 2
2025-03-03T16:07:07.956302+00:00 ubuntu ovpn-server[79652]:   tls_exit = DISABLED
2025-03-03T16:07:07.956334+00:00 ubuntu ovpn-server[79652]:   tls_crypt_v2_metadata = '[UNDEF]'

So I checked the configuration for the next few hours and tried all sorts of changes. Nothing worked, until I managed to spot the error in the line below, and I only noticed by comparing the configuration to a working server. The incorrect configuration is:

# The server and each client must have
# a copy of this key.
tls-auth server/ta.key

Spot the error? It’s missing the key direction parameter – a numeric value of either 0 (server) or 1 (client). When I set the tls key I must have removed the value by accident. I updated the configuration and then clients could connect

# The server and each client must have
# a copy of this key.
tls-auth server/ta.key 0

Regarding the logs, the error is there, but it isn’t tagged in a way that grep would see it. Looking at the raw syslog, the key direction message is printed, but I didn’t notice it because there are hundreds of values printed and this didn’t really stand out. The important line being “key_direction = not set“.

2025-03-03T16:07:07.952418+00:00 ubuntu ovpn-server[79652]:   tls_auth_file = '[INLINE]'
2025-03-03T16:07:07.952445+00:00 ubuntu ovpn-server[79652]:   key_direction = not set
2025-03-03T16:07:07.952471+00:00 ubuntu ovpn-server[79652]:   tls_crypt_file = '[UNDEF]'
2025-03-03T16:07:07.952497+00:00 ubuntu ovpn-server[79652]:   tls_crypt_v2_file = '[UNDEF]'

TLS Key Direction Parameter

When generating a client .opvn configuration file from a working .config file, I ran into an issue where the client would not connect. For more details on the .opvn format, see there

The server was throwing the following error –

2025-03-10T10:10:03.328706+00:00 ubuntu ovpn-server[728]: TLS Error: incoming packet authentication failed from [AF_INET]91.110.91.84:58377
2025-03-10T10:10:04.329026+00:00 ubuntu ovpn-server[728]: Authenticate/Decrypt packet error: packet HMAC authentication failed
2025-03-10T10:10:04.329116+00:00 ubuntu ovpn-server[728]: TLS Error: incoming packet authentication failed from [AF_INET]91.110.91.84:58377

After a bit of head scratching I compared configuration to a file I had working – there was a missing configuration property in the .opvn file. This is because when you inline the TLS key in the .opvn file, you no longer have the direction parameter.

key-direction 1

In the .config file this option is already included in the line

tls-auth ta.key 1