Project

General

Profile

Actions

Regression #15928

open

OpenVPN DCO clients fail to reconect

Added by Steve Wheeler 6 days ago. Updated about 5 hours ago.

Status:
In Progress
Priority:
Normal
Category:
OpenVPN
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Release Notes:
Default
Affected Plus Version:
25.03
Affected Architecture:
All

Description

OpenVPN clients with DCO enabled fail to reconnect if the server is restarted in 25.03 dev snapshots:

Dec 12 19:17:02     openvpn     6919     Outgoing dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Dec 12 19:17:02     openvpn     6919     Outgoing dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 12 19:17:02     openvpn     6919     Incoming dynamic tls-crypt: Cipher 'AES-256-CTR' initialized with 256 bit key
Dec 12 19:17:02     openvpn     6919     Incoming dynamic tls-crypt: Using 256 bit message hash 'SHA256' for HMAC authentication
Dec 12 19:17:02     openvpn     6919     Failed to set key: No such file or directory (errno=2)
Dec 12 19:17:02     openvpn     6919     Exiting due to fatal error 

This is a regression since 24.11.


Files

ovpne_client_log.txt (5.75 KB) ovpne_client_log.txt Steve Wheeler, 12/12/2024 08:53 PM
Actions #1

Updated by Steve Wheeler 6 days ago

Also of note is that clients without DCO enabled reconnect OK.

Actions #2

Updated by Kristof Provost about 8 hours ago

  • Assignee set to Kristof Provost

Initial observations:

We've updated from OpenVPN 2.6.8 to 2.6.12.

Secondly, the error message `Failed to set key: No such file or directory (errno=2)` logs the errno, in this case 2 or ENOENT, which the set key code only produces if it failed to find the peer we're trying to set the key for.

That leads to the suspicion that something changed in OpenVPN itself to trigger this. Notably, FreeBSD's if_ovpn deletes the peer if it times out (which is what we'd expect to see when the server goes away and we reconnect). It may be that this expectation changed on the userspace side (i.e. the kernel deleted the peer, but userspace assumes it still exists, so when it reconnects it only provides new keys, not a new peer). I have yet to confirm this though.

Actions #3

Updated by Kristof Provost about 5 hours ago

  • Status changed from New to In Progress

Having poked it a bit more it looks like the problem is slightly different.
OpenVPN now closes the socket and opens a new one, but the ovpn_new_peer() function expects the socket to never change. I'll add a special case for 'we have no peers' and allow the socket to change anyway.

Actions

Also available in: Atom PDF