OpenVPN client incompatibility with OpenVPN 2.7.6 – P_CONTROL_HARD_RESET_CLIENT_V2 sent with packet ID 1 instead of 0

RouterOS
1

Hello,

I would like to report an OpenVPN client compatibility issue between MikroTik RouterOS and OpenVPN 2.7.6.

After upgrading the OpenVPN server to OpenVPN 2.7.6, MikroTik OpenVPN clients are no longer able to establish a TLS session.

Server environment

  • OS: Debian 13 (Trixie)
  • OpenVPN version: 2.7.6-trixie1
  • Package source: official OpenVPN 2.7 repository (build.openvpn.net)
  • Transport: OpenVPN over TCP
  • Clients: MikroTik routers using the built-in RouterOS OpenVPN client

Installed package:

openvpn:
  Installed: 2.7.6-trixie1
  Candidate: 2.7.6-trixie1

Problem

OpenVPN 2.7.6 reports that MikroTik clients send the initial P_CONTROL_HARD_RESET_CLIENT_V2 packet with packet ID 1, while OpenVPN 2.7.6 expects the HARD_RESET packet to use packet ID 0.

Example server log:

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 happens with multiple MikroTik OpenVPN clients, not just a single router.

The TCP connection itself is established successfully, but the TLS handshake cannot proceed because OpenVPN 2.7.6 rejects the initial HARD_RESET packet.

Relevant OpenVPN 2.7.6 change

OpenVPN 2.7.6 introduced stricter validation of incoming HARD_RESET packets. A HARD_RESET packet with a sequence/packet ID other than 0 is now rejected.

The MikroTik OpenVPN client appears to initialize:

P_CONTROL_HARD_RESET_CLIENT_V2

with:

packet id 1

instead of:

packet id 0

OpenVPN therefore ignores the packet and the connection eventually fails with a TLS error.

Expected behavior

The RouterOS OpenVPN client should send the initial:

P_CONTROL_HARD_RESET_CLIENT_V2

using:

packet id 0

as expected by the OpenVPN protocol and current OpenVPN 2.7.6 implementation.

Actual behavior

RouterOS sends:

P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1

OpenVPN 2.7.6 responds:

TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 ... -- 0 was expected, ignoring packet

and the VPN connection cannot be established.

Compatibility observation

OpenVPN 2.7.5 is available on the same Debian server and does not contain the new strict HARD_RESET packet-ID validation introduced in 2.7.6.

Therefore, downgrading the server from OpenVPN 2.7.6 to 2.7.5 is currently a possible workaround, but this is not desirable as a permanent solution.

Request

Could you please verify the OpenVPN control-channel packet ID initialization in the RouterOS OpenVPN client?

In particular, please check why P_CONTROL_HARD_RESET_CLIENT_V2 starts with packet ID 1 rather than 0.

If this is a RouterOS OpenVPN implementation issue, please update the client to be compatible with OpenVPN 2.7.6 and newer versions.

I can provide additional OpenVPN server logs and RouterOS OpenVPN client configuration if required.

ROS: 6.49.20 and 7.23.3

2

I would recommend using this container GitHub - qwertykolea/openvpn-client: A lightweight OpenVPN client container designed specifically for RouterOS · GitHub as OpenVPN client instead of the built-in client.

3

Unfortunately, older devices like hAP AC2 do not have the ability to run containers.

4

Submit a ticket and hopefully it will get fixed quickly. (I assume that you have checked that is is not already fixed in 7.24?)

5

RouterOS use own version of OpenVPN, so, contact the developer of OpenVPN
and ask to add a flag on 2.7.6 to be compatible to RouterOS proprietary version.

2.7.6 is fresh, released this month,
usually you must wait some decades before internal software on RouterOS is aligned to actual version...

6

No, I haven't tested it yet, but I expect the behavior to be the same.
I only rolled back to an earlier version on Thursday because version 7.24 broke DHCP snooping functionality; my Wi-Fi repeater was unable to receive the ACK packet from the MikroTik confirming the assigned IP lease.
This became a critical issue for my network, causing the entire Wi-Fi infrastructure to fail.

I’ve submitted a bug report to technical support.

7

Response from OpenVPN technical support

  1. Yes. Rejecting P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 is intentional: d1e67f4 See the commit message for more details.
  2. no you cannot disable this behaviour
  3. We need to investigate what is really happening here before adding an option like that.
  4. No security implications but this fix was to address an issue in our own client that was always there but there was another bug in the 2.7.x series that made made this issue surface (603aa96) a lot more. So we are unlikely to revert this fix as it address buggy behaviour when interacting with 2.7.0 - 2.7.5 peers.

I am surprised that our reliable layer even accepts sessions that do not start at 1.

8

You certainly can if you are willing to work in the source code . . . . :slight_smile:

(And kind of comical . . . "no security implications" but they decided to deliberately (and instantly) break old clients anyhow . . .)

9

I observed the same issue with Windows clients running OpenVPN Community versions 2.7.3-2.7.6.

I rolled the server back to version 2.7.5, and it is no longer possible to re-verify the issue, as version 2.7.6 caused all VPN connections to drop and resulted in a loss of access to critical remote devices.

So it turns out they broke all the old clients, leaving only the current version available ))

10

Stand up 2.7.6 on a different port for testing, perhaps?

11

I ran this container on my hap ac2, but unfortunately without the modern wifi-qcom-ac driver

12

I'll run tests on virtual machines in the lab to avoid breaking the existing physical network :slight_smile:

13

That was my point . . . running on a different port won't break anything. (Well, if you are on WhinDuhs, the parallel install might be a challenge . . . ) VM's are an ideal test as well, though.

14

Hi,

You should open a ticket to a Support as forum is not the the place that MT follows to solve the probles. They MIGHT or NOT consider your post as an important one and MIGHT or NOT apply proper change to ROS.
Experience tells that they rarely consider such posts as important.

15

I ran tests on virtual machines and CHR.
Currently unable to connect:

  • ROS 6.49.20

Error in Mikrotik logs:
openvpn: terminating... - TLS failed

Server log:
2026-08-27 23:32:06 public/tcp4-server:192.168.15.103:59088 IP packet with unknown IP version=0 seen
2026-08-27 23:32:06 public/tcp4-server:192.168.15.103:59088 IP packet with unknown IP version=0 seen
2026-08-27 23:32:10 tcp4-server:192.168.15.104:40894 Connection reset, restarting [0]
2026-08-27 23:32:16 TCP connection established with [AF_INET]192.168.15.104:40895
2026-08-27 23:32:16 tcp4-server:192.168.15.104:40895 TLS Error: received P_CONTROL_HARD_RESET_CLIENT_V2 with packet id 1 from [AF_INET]192.168.15.104:40895 -- 0 was expected, ignoring packet

ROS version 7.21.5+ - connects correctly.

16

Not sure if it's an option, but I declared ROS6 dead to me a looooong time ago. Have you tested with 7?

(I did see notes from the OpenVPN side on this though . . . . Seems like they broke just about every client but thier own most recent, so I can't fault MikroTik too hard for this.)

17

Yes, I tested it on the latest version 7.24.1. It works.

But I have many clients running 6.49.20, as well as my own equipment in different cities and offices. It works flawlessly, and I don't see the point in replacing existing equipment just because of the OVPN protocol. :slight_smile:
Eventually, when I have to do a scheduled equipment replacement, I'll choose ROS 7.

No one will finance me for hundreds (if not thousands) of devices to replace them all with ROS 7. :slight_smile:

18

What do you have that won't run ROS7? Even my 16MB stuff seems to handle it fine (albeit without any extra modules/features loaded).

The only mention I see of a specific model is:

"Unfortunately, older devices like hAP AC2 do not have the ability to run containers."

And the hAP-ac2 runs flawlessly on ROS7 . . . (or is that not what you have?) unless you need more than ROS+wireless packages. (I have almost 1MB free on hAP-ac2) . . . )