Bug#1012129: openvpn: 2.6 client fails authentication against older server

Guillem Jover

unread,

May 30, 2022, 12:30:03 PM5/30/22

to

Package: openvpn
Version: 2.6.0~git20220518+dco-1
Severity: important

Hi!

Just upgraded openvpn the other day and could not connect anymore to the
VPN. Reverting back to 2.5.6-1 makes it work again. I checked #1011473
and nothing there seemed relevant. Here's an (edited) excerpt from the
log (from today's retry):

,---
[…]
2022-05-30 18:07:07 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
[…]
2022-05-30 18:07:07 us=415641 Cannot find ovpn_dco netlink component: Object not found
2022-05-30 18:07:07 us=415662 Note: Kernel support for ovpn-dco missing, disabling data channel offload.
2022-05-30 18:07:07 us=416916 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on May 20 2022
2022-05-30 18:07:07 us=416925 library versions: OpenSSL 3.0.3 3 May 2022, LZO 2.10
2022-05-30 18:07:07 us=419756 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA2-512' for HMAC authentication
2022-05-30 18:07:07 us=419776 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA2-512' for HMAC authentication
2022-05-30 18:07:07 us=419787 LZO compression initializing
2022-05-30 18:07:07 us=419849 Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 headroom:126 payload:1376 tailroom:126 ET:0 ]
2022-05-30 18:07:07 us=420380 Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 headroom:136 payload:1736 tailroom:557 ET:0 ]
2022-05-30 18:07:07 us=420424 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA2-512,keysize 256,tls-auth,key-method 2,tls-client'
2022-05-30 18:07:07 us=420431 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 0,cipher AES-256-CBC,auth SHA2-512,keysize 256,tls-auth,key-method 2,tls-server'
2022-05-30 18:07:07 us=420437 TCP/UDP: Preserving recently used remote address: [AF_INET]<remote-ip>:<remote-port>
2022-05-30 18:07:07 us=420449 Socket Buffers: R=[212992->212992] S=[212992->212992]
2022-05-30 18:07:07 us=420457 Note: enable extended error passing on TCP/UDP socket failed (IPV6_RECVERR): Protocol not available (errno=92)
2022-05-30 18:07:07 us=420461 UDP link local: (not bound)
2022-05-30 18:07:07 us=420466 UDP link remote: [AF_INET]<remote-ip>:<remote-port>
2022-05-30 18:07:07 us=458976 TLS: Initial packet from [AF_INET]<remote-ip>:<remote-port>, sid=<remote-sid>
2022-05-30 18:07:07 us=544314 VERIFY OK: depth=2, <cert-root-info>
2022-05-30 18:07:07 us=545081 VERIFY OK: depth=1, <cert-ca-info>
2022-05-30 18:07:07 us=545608 Validating certificate extended key usage
2022-05-30 18:07:07 us=545645 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2022-05-30 18:07:07 us=545663 VERIFY EKU OK
2022-05-30 18:07:07 us=545678 VERIFY X509NAME OK: <cert-info>
2022-05-30 18:07:07 us=545693 VERIFY OK: depth=0, <cert-info>
2022-05-30 18:07:07 us=649111 WARNING: 'auth' is used inconsistently, local='auth SHA2-512', remote='auth SHA512'
2022-05-30 18:07:07 us=649265 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2022-05-30 18:07:07 us=649317 [<remote-name>] Peer Connection Initiated with [AF_INET]<remote-ip>:<remote-port>
2022-05-30 18:07:08 us=824515 SENT CONTROL [<remote-name>]: 'PUSH_REQUEST' (status=1)
2022-05-30 18:07:08 us=863166 AUTH: Received control message: AUTH_FAILED
2022-05-30 18:07:08 us=863611 TCP/UDP: Closing socket
2022-05-30 18:07:08 us=863809 SIGTERM[soft,auth-failure] received, process exiting
`---

The auth setting is locally set to SHA512, I'm assuming OpenSSL remaps
it, but that's just a warning. It just seems to be failing at the
PUSH_REQUEST step. Setting «compat-mode 2.5.6» did not help either.

Thanks,
Guillem

Bernhard Schmidt

unread,

May 30, 2022, 2:00:03 PM5/30/22

to

Control: tags -1 + moreinfo

Hi Guillem,

> Just upgraded openvpn the other day and could not connect anymore to the
> VPN. Reverting back to 2.5.6-1 makes it work again. I checked #1011473
> and nothing there seemed relevant. Here's an (edited) excerpt from the
> log (from today's retry):
>

> 2022-05-30 18:07:08 us=863166 AUTH: Received control message: AUTH_FAILED

This one looks weird, do you have any chance to check the logs on the
other side?

> The auth setting is locally set to SHA512, I'm assuming OpenSSL remaps
> it, but that's just a warning. It just seems to be failing at the
> PUSH_REQUEST step. Setting «compat-mode 2.5.6» did not help either.

This (different name between OpenSSL 1.1 and OPenSSL 3.0 for the same
algo) has been fixed upstream already, but not yet imported into the dco
tree. Unless you run opt-verify on the other side that should not matter
though.

Bernhard

Guillem Jover

unread,

Jun 3, 2022, 7:50:03 AM6/3/22

to

Hi!

On Mon, 2022-05-30 at 19:41:08 +0200, [EXT] Bernhard Schmidt wrote:
> Control: tags -1 + moreinfo

> > Just upgraded openvpn the other day and could not connect anymore to the
> > VPN. Reverting back to 2.5.6-1 makes it work again. I checked #1011473
> > and nothing there seemed relevant. Here's an (edited) excerpt from the
> > log (from today's retry):
> >
>
> > 2022-05-30 18:07:08 us=863166 AUTH: Received control message: AUTH_FAILED
>
> This one looks weird, do you have any chance to check the logs on the other
> side?

I've asked our admin, and I'm told the client authenticates correctly
but fails on the push request, but I'll try to ask for the actual
logs.

> > The auth setting is locally set to SHA512, I'm assuming OpenSSL remaps
> > it, but that's just a warning. It just seems to be failing at the
> > PUSH_REQUEST step. Setting «compat-mode 2.5.6» did not help either.
>
> This (different name between OpenSSL 1.1 and OPenSSL 3.0 for the same algo)
> has been fixed upstream already, but not yet imported into the dco tree.

Ah great, thanks.

> Unless you run opt-verify on the other side that should not matter though.

I'm also told we are not using opt-verify on the server side.

I've asked whether we can enable more verbose output on the server
side to try to see what might be going on there, but that will not be
possible until next week or so. If you have no other suggestions or
ideas what I could try from the client side, I'll try to come back with
some better logs from the server side around next week or so.

Thanks,
Guillem

Fabio Pedretti

unread,

Jul 16, 2022, 2:40:03 PM7/16/22

to

This is fixed also in the dco branch now:
https://github.com/OpenVPN/openvpn/commits/dco?after=63409150834208582031876dab70beefa2ee48f6+34&branch=dco&qualified_name=refs%2Fheads%2Fdco

Guillem Jover

unread,

Jul 22, 2022, 5:00:03 AM7/22/22

to

Hi!

On Fri, 2022-06-03 at 13:42:48 +0200, Guillem Jover wrote:
> On Mon, 2022-05-30 at 19:41:08 +0200, [EXT] Bernhard Schmidt wrote:
> > > Just upgraded openvpn the other day and could not connect anymore to the
> > > VPN. Reverting back to 2.5.6-1 makes it work again. I checked #1011473
> > > and nothing there seemed relevant. Here's an (edited) excerpt from the
> > > log (from today's retry):
> >
> > > 2022-05-30 18:07:08 us=863166 AUTH: Received control message: AUTH_FAILED
> >
> > This one looks weird, do you have any chance to check the logs on the other
> > side?
>
> I've asked our admin, and I'm told the client authenticates correctly
> but fails on the push request, but I'll try to ask for the actual
> logs.

> > Unless you run opt-verify on the other side that should not matter though.
>
> I'm also told we are not using opt-verify on the server side.

In the end it looks like we were, sorry. After disabling that option,
and waiting for the downtime window, testing the client again seems to
work fine now.

I'm not sure whether Fabio's mail refers to the auth name fix or the
opt-verify one though?

Thanks,
Guillem