Hello OpenVPN developers,
I would like to report a compatibility regression observed after upgrading an OpenVPN server to OpenVPN 2.7.6.
The affected clients are MikroTik routers using the built-in RouterOS OpenVPN client.
Server environment
- OS: Debian 13 (Trixie)
- OpenVPN: 2.7.6-trixie1
- Architecture: amd64
- Package repository: official OpenVPN 2.7 Debian repository (
build.openvpn.net)
- Transport: TCP
Installed package:
openvpn:
Installed: 2.7.6-trixie1
Candidate: 2.7.6-trixie1
The following previous releases are also available from the same repository:
2.7.5-trixie1
2.7.4-trixie1
2.7.3-trixie1
...
Problem
After upgrading to OpenVPN 2.7.6, multiple MikroTik RouterOS OpenVPN clients can establish a TCP connection to the server, but cannot proceed with the OpenVPN TLS handshake.
The server reports:
2026-08-21 13:58:49 TCP connection established with [AF_INET]WWW.XXX.YYY.ZZZ:34021
2026-08-21 13:58:49 tcp4-server:WWW.XXX.YYY.ZZZ:34021 TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 from [AF_INET]WWW.XXX.YYY.ZZZ:34021 -- 0 was expected, ignoring packet
2026-08-21 13:58:49 TCP connection established with [AF_INET]WWW.XXX.YYY.ZZZ:11444
2026-08-21 13:58:49 tcp4-server:WWW.XXX.YYY.ZZZ:11444 TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 from [AF_INET]WWW.XXX.YYY.ZZZ:11444 -- 0 was expected, ignoring packet
2026-08-21 13:58:49 tcp4-server:WWW.XXX.YYY.ZZZ:55386 TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 from [AF_INET]WWW.XXX.YYY.ZZZ:55386 -- 0 was expected, ignoring packet
This behavior is reproducible with multiple independent MikroTik clients.
All of them appear to send:
P_CONTROL_HARD_RESET_CLIENT_V2
packet id = 1
while OpenVPN 2.7.6 requires:
The packet is therefore ignored before the TLS handshake can proceed.
OpenVPN 2.7.6 behavior change
As I understand it, OpenVPN 2.7.6 introduced stricter validation of HARD_RESET packets and now rejects a HARD_RESET packet when its sequence/packet ID is not 0.
This appears to be correct according to the expected OpenVPN protocol behavior.
However, existing MikroTik RouterOS OpenVPN clients appear to have been sending the initial HARD_RESET packet with ID 1, which was tolerated by previous OpenVPN releases.
As a result, upgrading an existing OpenVPN server to 2.7.6 can cause all affected MikroTik RouterOS OpenVPN clients to stop connecting immediately.
Expected / previous behavior
Previous OpenVPN server releases tolerated the MikroTik client's:
P_CONTROL_HARD_RESET_CLIENT_V2 packet id 1
allowing the handshake to continue.
OpenVPN 2.7.6 behavior
OpenVPN 2.7.6 rejects it with:
TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 ... -- 0 was expected, ignoring packet
This prevents the connection from reaching the TLS certificate verification stage.
Current workaround
Downgrading the OpenVPN server from:
to:
is currently being considered as a compatibility workaround.
There does not appear to be a server configuration option in OpenVPN 2.7.6 to disable only this new HARD_RESET packet-ID validation.
Options related to certificate verification, replay protection, or general compatibility do not appear to control this check.
Questions / request
I understand that sending a HARD_RESET packet with ID 1 may be incorrect behavior on the MikroTik side, and I am also reporting the issue to MikroTik.
However, considering that existing deployed RouterOS clients apparently relied on the behavior accepted by previous OpenVPN releases, could you please clarify:
-
Is rejecting P_CONTROL_HARD_RESET_CLIENT_V2 with packet ID 1 intentional and mandatory behavior in OpenVPN 2.7.6?
-
Is there currently any configuration option or compat-mode setting that can restore the pre-2.7.6 behavior temporarily?
-
If not, would you consider adding a temporary compatibility option allowing non-zero HARD_RESET packet IDs for legacy/third-party clients?
-
Are there security implications that make retaining the previous tolerant behavior unacceptable?
The goal would not be to change the default behavior, but to provide administrators with a migration path for existing MikroTik RouterOS deployments until the client implementation is fixed.
I can provide additional server logs, configuration details, and packet captures if needed.
ROS: 6.49.20 and 7.23.3
Hello OpenVPN developers,
I would like to report a compatibility regression observed after upgrading an OpenVPN server to OpenVPN 2.7.6.
The affected clients are MikroTik routers using the built-in RouterOS OpenVPN client.
Server environment
build.openvpn.net)Installed package:
The following previous releases are also available from the same repository:
Problem
After upgrading to OpenVPN 2.7.6, multiple MikroTik RouterOS OpenVPN clients can establish a TCP connection to the server, but cannot proceed with the OpenVPN TLS handshake.
The server reports:
This behavior is reproducible with multiple independent MikroTik clients.
All of them appear to send:
while OpenVPN 2.7.6 requires:
The packet is therefore ignored before the TLS handshake can proceed.
OpenVPN 2.7.6 behavior change
As I understand it, OpenVPN 2.7.6 introduced stricter validation of HARD_RESET packets and now rejects a HARD_RESET packet when its sequence/packet ID is not
0.This appears to be correct according to the expected OpenVPN protocol behavior.
However, existing MikroTik RouterOS OpenVPN clients appear to have been sending the initial HARD_RESET packet with ID
1, which was tolerated by previous OpenVPN releases.As a result, upgrading an existing OpenVPN server to 2.7.6 can cause all affected MikroTik RouterOS OpenVPN clients to stop connecting immediately.
Expected / previous behavior
Previous OpenVPN server releases tolerated the MikroTik client's:
allowing the handshake to continue.
OpenVPN 2.7.6 behavior
OpenVPN 2.7.6 rejects it with:
This prevents the connection from reaching the TLS certificate verification stage.
Current workaround
Downgrading the OpenVPN server from:
to:
is currently being considered as a compatibility workaround.
There does not appear to be a server configuration option in OpenVPN 2.7.6 to disable only this new HARD_RESET packet-ID validation.
Options related to certificate verification, replay protection, or general compatibility do not appear to control this check.
Questions / request
I understand that sending a HARD_RESET packet with ID
1may be incorrect behavior on the MikroTik side, and I am also reporting the issue to MikroTik.However, considering that existing deployed RouterOS clients apparently relied on the behavior accepted by previous OpenVPN releases, could you please clarify:
Is rejecting
P_CONTROL_HARD_RESET_CLIENT_V2with packet ID1intentional and mandatory behavior in OpenVPN 2.7.6?Is there currently any configuration option or
compat-modesetting that can restore the pre-2.7.6 behavior temporarily?If not, would you consider adding a temporary compatibility option allowing non-zero HARD_RESET packet IDs for legacy/third-party clients?
Are there security implications that make retaining the previous tolerant behavior unacceptable?
The goal would not be to change the default behavior, but to provide administrators with a migration path for existing MikroTik RouterOS deployments until the client implementation is fixed.
I can provide additional server logs, configuration details, and packet captures if needed.
ROS: 6.49.20 and 7.23.3