SparkLabs Forum.

Community Help.

inconsistent options used upon resuming a broken connection

Whenever a vpn connection is resumed after being temporarily down, I see the following in the log:

Code: Select all

2018-04-03 01:33:56: WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1550', remote='link-mtu 1542'
2018-04-03 01:33:56: WARNING: 'cipher' is used inconsistently, local='cipher AES-128-GCM', remote='cipher BF-CBC'
2018-04-03 01:33:56: WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA1'

This will continue indefinitely, repeating every hour.

Prior to the link interruption, Nothing in the log. This looks like a bug to me.
Hi aardquark,

The warnings are indicating that the settings between the server and the client do not match - this is not a bug. Your log snippet indicates the server is using BF-CBC by default, which is largely considered insecure and deprecated due to the SWEET32 attack. I recommend setting a more modern cipher server-side.

However, while the server and client settings don't match, it looks likely that OpenVPN is performing "cipher negotiation" (introduced in OpenVPN 2.4) to decide on matching cipher details (which is likely why the connection is still working).

If you wish to resolve the warnings you can do so by setting matching MTU and cipher settings on the OpenVPN server. However, if your connection is working, you can also ignore the warnings (at least for cipher and auth) as cipher negotiation will be overriding them.

But I don't see those warning messages when I initially create the connection. In fact, I just closed the connection, and reconnected, and the negotiated cipher is AES-128-GCM (128 bit key). There will then be no warnings in the log, ever... until the connection hiccups and automatically reconnects. Then the warnings start.

The next time that happens I will check to see what cipher is being used on the auto reconnect. (I forget to check before I dropped the connect).
Hi aardquark,

You're only getting the warnings when the OpenVPN session re-keys (it shouldn't actually be dropping in most instances). You're not seeing them on the initial connect as cipher negotiation has not yet taken place. This is normal OpenVPN behaviour and not anything Viscosity controls.

4 posts Page 1 of 1

Copyright © 2016 SparkLabs Pty Ltd. All Rights Reserved. Privacy Policy