Skip to content
inconsistent options used upon resuming a broken connection
Got a problem with Viscosity or need help? Ask here!
Whenever a vpn connection is resumed after being temporarily down, I see the following in the log:
Prior to the link interruption, Nothing in the log. This looks like a bug to me.
Code: Select all
This will continue indefinitely, repeating every hour.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'
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.
https://community.openvpn.net/openvpn/wiki/SWEET32
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.
Cheers,
James
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.
https://community.openvpn.net/openvpn/wiki/SWEET32
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.
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
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).
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.
Cheers,
James
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.
Cheers,
James
Web: https://www.sparklabs.com
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
Support: https://www.sparklabs.com/support
Twitter: https://twitter.com/sparklabs
4 posts
Page 1 of 1