Regression #15928: OpenVPN DCO clients fail to reconect - pfSense Plus - pfSense bugtracker

Actions

Copy link

Regression #15928

closed

OpenVPN DCO clients fail to reconect

Added by Steve Wheeler about 1 month ago. Updated 17 days ago.

Status:

Resolved

Priority:

Normal

Assignee:

Kristof Provost

Category:

OpenVPN

Target version:

25.03

Start date:

Due date:

% Done:

Estimated time:

Release Notes:

Force Exclusion

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

Copy link

Updated by Steve Wheeler about 1 month ago

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

Actions

Copy link

Updated by Kristof Provost about 1 month 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

Copy link

Updated by Kristof Provost about 1 month 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

Copy link