wiki.ipfire.org

The community-maintained documentation platform of IPFire

User Tools

Site Tools


configuration:services:openvpn:troubles

Troubleshooting

Inspect the OpenVPN Logs

One of the first steps in case of problems should be to check the OpenVPN logs. The webinterface 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.

For a simple output:

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

and for a general output is it possible to use also a

grep "openvpn" /var/log/messages

for Roadwarrior specifics and a

grep "n2n" /var/log/messages

for the Net-to-Net connections.

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

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

and for a general output is it possible to use also a

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

for Roadwarrior specifics and a

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

for the Net-to-Net connections.

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

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.

The external IP addresses and personal details have been removed or crossed out from this log, this is a small effort, but for a possible post in the IPFire forum or on another place, a important point

A small collection of possible error reports

1) 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

2) 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

3) 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]

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

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

6) 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 –>

7) –> 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

8) 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 an similarily 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 webinterface, also mssfix should be activated, the actual MTU value can be left in 1500.

1) mssfix and fragment can only be used with UDP tunnel.

2) 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.

3) 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 respose.
  • IPTraf-ng - A console based network statistic monitoring utility.

back to OpenVPN main

configuration/services/openvpn/troubles.txt · Last modified: 2018/09/07 02:15 by Jon