[Openvpn-users] VPN clients disconnecting since 2.4

[Geert Lorang]

Hi,

Since Ubuntu 17.04 came out a few of our users have upgraded their
OpenVPN client to 2.4 but this seems to break compatibility with our
server which is still on 2.3 (latest Debian Jessie). I can reproduce
this problem on Windows as well with latest 2.4.3.

As soon as you start downloading some big(ger) files which utilize the
VPN quite heavily OpenVPN will prompt again for credentials after 1-5
minutes and our users have to re-authenticate with their token as we use
a 2FA based setup.
The exact same config / setup / PC / Internet connection / ... but with
OpenVPN 2.3 just works perfectly for over a year, it's really only the
2.4 clients (both Windows & Linux) that have this problem.

When a disconnect occurs the following is seen server side:

Jul 17 17:51:09 X ovpn-openvpn[640]: geert/::ffff:X.X.X.X TLS Error: TLS
key negotiation failed to occur within 60 seconds (check your network
connectivity)
Jul 17 17:51:09 X ovpn-openvpn[640]: geert/::ffff:X.X.X.X TLS Error: TLS
handshake failed
Jul 17 17:51:09 X ovpn-openvpn[640]: geert/::ffff:X.X.X.X TLS:
move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1

Client side there is nothing the log.

Most relevant config settings we have are reneg-sec 0, auth-user-pass,
auth-nocache and proto udp I guess. If needed I can provide the entire
configs.

Anyone seen this before / knows what's going on?

Thanks,
Geert

[debbie10t]

Hi,
If needed I can provide the entire configs.

configs and logs at --verb 4 (sanitized)

In advance of that, are you using (default) --cipher BF-CBC ?
because that will force renegotiation after 64MB data.

regards

[David Sommerseth]

Post by Geert Lorang
Hi,
Since Ubuntu 17.04 came out a few of our users have upgraded their
OpenVPN client to 2.4 but this seems to break compatibility with our
server which is still on 2.3 (latest Debian Jessie). I can reproduce
this problem on Windows as well with latest 2.4.3.
As soon as you start downloading some big(ger) files which utilize the
VPN quite heavily OpenVPN will prompt again for credentials after 1-5
minutes and our users have to re-authenticate with their token as we use
a 2FA based setup.
The exact same config / setup / PC / Internet connection / ... but with
OpenVPN 2.3 just works perfectly for over a year, it's really only the
2.4 clients (both Windows & Linux) that have this problem.
Jul 17 17:51:09 X ovpn-openvpn[640]: geert/::ffff:X.X.X.X TLS Error: TLS
key negotiation failed to occur within 60 seconds (check your network
connectivity)
Jul 17 17:51:09 X ovpn-openvpn[640]: geert/::ffff:X.X.X.X TLS Error: TLS
handshake failed
move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
Client side there is nothing the log.
Most relevant config settings we have are reneg-sec 0, auth-user-pass,
auth-nocache and proto udp I guess. If needed I can provide the entire
configs.

Try removing auth-nocache on the client, or add --auth-gen-token to the
server config. That should take care of the need for needing to enter
new credentials. --auth-gen-token also have the advantage that the
password is not cached on the client; it is replaced by a session
specific authentication token.

You say you used OpenVPN 2.3 earlier, which patch level? Also, which
cipher do you use for your tunnel? If you use Blowfish (aka BF-CBC) and
OpenVPN was older than v2.3.13, I can understand you have a different
behaviour. But if you had v2.3.13 or newer should behave similar to
v2.4 in regards to the BF cipher.


Just a side remark; v2.3 _servers_ does not support --auth-gen-token.
Any OpenVPN _client_ newer than 2.2 should support a v2.4 server with
--auth-gen-token enabled.


--
kind regards,

David Sommerseth

[Gert Doering]

Hi,

On Mon, Jul 17, 2017 at 06:17:38PM +0200, Geert Lorang wrote:
[..]

Post by Geert Lorang
As soon as you start downloading some big(ger) files which utilize the
VPN quite heavily OpenVPN will prompt again for credentials after 1-5
minutes and our users have to re-authenticate with their token as we use
a 2FA based setup.

This is most likely not a "2.3 -> 2.4" regression, but "old 2.3.x to
more recent version".

As the default cipher (BF-CBC) is considered weak today, if you do not
renegotiate your keys ever so often, newer 2.3.x versions and 2.4 will
set "reneg-bytes 64MB" automatically if BF-CBC is in use - and if you
hit a renegotiation, you need to re-enter credentials.

One approach to handle this is to migrate to more modern crypto algorithms
- put 2.4 on the server, and it will negotiate AES-256-GCM with 2.4
clients, fixing this issue in multiple aspects.

Alternatively, you can put "reneg-bytes 0" in your configs while preparing
the migration away from BF-CBC (be aware that this weakens your crypto,
so this can only be a temporary thing).

Third option would be what David suggested, using the new approach where
the server would generate an auth-token which can be used in place of the
username/password on TLS renegotiation. I'm not sure 2.3 can do that,
though, so you might have to upgrade your server anyway.


(...but 2.4 on the server will also give you TLS floating, you want
that, no matter what .-) )

gert

[Geert Lorang]

Post by Gert Doering
This is most likely not a "2.3 -> 2.4" regression, but "old 2.3.x to
more recent version".
As the default cipher (BF-CBC) is considered weak today, if you do not
renegotiate your keys ever so often, newer 2.3.x versions and 2.4 will
set "reneg-bytes 64MB" automatically if BF-CBC is in use - and if you
hit a renegotiation, you need to re-enter credentials.

Many thanks for the hint about the renegotiation that happens after
64MB when on BF-CBC cipher.
I can indeed confirm we're on the default BF-CBC cipher and the issue
occurs exactly once 64MB of data was downloaded.

On the other hand, this is really only an issue with 2.4. Both 2.3.17 &
2.4.3 log (twice) the warning "WARNING: INSECURE cipher with block size
less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate
by using a --cipher with a larger block size (e.g. AES-256-CBC)." but
the warning "WARNING: cipher with small block size in use, reducing
reneg-bytes to 64MB to mitigate SWEET32 attacks." is *only* seen in 2.4.

Let me know if I can be any help here?

Post by Gert Doering
One approach to handle this is to migrate to more modern crypto algorithms
- put 2.4 on the server, and it will negotiate AES-256-GCM with 2.4
clients, fixing this issue in multiple aspects.
Alternatively, you can put "reneg-bytes 0" in your configs while preparing
the migration away from BF-CBC (be aware that this weakens your crypto,
so this can only be a temporary thing).

Thanks for this! I can also confirm that reneg-bytes 0 fixes it with a
2.4 client on a 2.3 server.

With Stretch just released / OpenVPN 2.4 available in jessie-backports
we're going to plan an upgrade somewhere soon.
At the same time we will check out the auth-gen-token as it seems really
useful in our setup.


Thanks again guys! This was really helpful.

Regards,
Geert

[David Sommerseth]

Post by Geert Lorang

Post by Gert Doering
This is most likely not a "2.3 -> 2.4" regression, but "old 2.3.x to
more recent version".
As the default cipher (BF-CBC) is considered weak today, if you do not
renegotiate your keys ever so often, newer 2.3.x versions and 2.4 will
set "reneg-bytes 64MB" automatically if BF-CBC is in use - and if you
hit a renegotiation, you need to re-enter credentials.

Many thanks for the hint about the renegotiation that happens after
64MB when on BF-CBC cipher.
I can indeed confirm we're on the default BF-CBC cipher and the issue
occurs exactly once 64MB of data was downloaded.
On the other hand, this is really only an issue with 2.4. Both 2.3.17 &
2.4.3 log (twice) the warning "WARNING: INSECURE cipher with block size
less than 128 bit (64 bit). This allows attacks like SWEET32. Mitigate
by using a --cipher with a larger block size (e.g. AES-256-CBC)." but
the warning "WARNING: cipher with small block size in use, reducing
reneg-bytes to 64MB to mitigate SWEET32 attacks." is *only* seen in 2.4.

That is correct. We decided we could not change the behaviour on the
client side on v2.3. The --reneg-bytes is set to 64MB by default for
client and server on v2.4 and only server mode on v2.3.

Post by Geert Lorang
Let me know if I can be any help here?

Post by Gert Doering
One approach to handle this is to migrate to more modern crypto algorithms
- put 2.4 on the server, and it will negotiate AES-256-GCM with 2.4
clients, fixing this issue in multiple aspects.
Alternatively, you can put "reneg-bytes 0" in your configs while preparing
the migration away from BF-CBC (be aware that this weakens your crypto,
so this can only be a temporary thing).

Thanks for this! I can also confirm that reneg-bytes 0 fixes it with a
2.4 client on a 2.3 server.

I strongly recommend not calling this a fix. This is purely a temporary
workaround. For weak ciphers (such as BF-CBC), you really do need the
64MB renegotiation to be for the time being _reasonably_ safe. But it
is just a quick band-aid.

Post by Geert Lorang
With Stretch just released / OpenVPN 2.4 available in jessie-backports
we're going to plan an upgrade somewhere soon.
At the same time we will check out the auth-gen-token as it seems really
useful in our setup.

Just an early heads-up, we do have a bug which affects configurations
which provides username/passwords via the management interface and uses
--auth-nocache. That might not be too bad, until you realise that the
NetworkManager OpenVPN plug-in uses the management interface for
providing the username/password via a graphical interface _and_ enforces
--auth-nocache. We have a promising patch ready, just need to get it
reviewed and applied and it will hit the next OpenVPN release.

Regarding Debian repositories ... have a look here too:
<http://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos>



--
kind regards,

David Sommerseth