Hello!
We use RB850Gx2, it's powerpc based cpu. While using ROS v6.4x we've had no problems with OpenVPN service. We were using AES-265-CBC with SHA1 auth. About 2 weeks ago I updated software to ROS 7.13.1. Now I use AES-256-GCM cipher, and get these errors in Windows OpenVPN Community:

Sat Jan 27 16:21:04 2024 OpenVPN 2.6.7 [git:v2.6.7/53c9033317b3b8fd] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Nov 8 2023
Sat Jan 27 16:21:04 2024 Windows version 10.0 (Windows 10 or greater), amd64 executable
Sat Jan 27 16:21:04 2024 library versions: OpenSSL 3.1.4 24 Oct 2023, LZO 2.10
Sat Jan 27 16:21:04 2024 DCO version: 1.0.0
Sat Jan 27 16:21:06 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 16:21:06 2024 ovpn-dco device [OpenVPN Data Channel Offload] opened
Sat Jan 27 16:21:27 2024 dco connect error: Przekroczono limit czasu semafora. (errno=121)
Sat Jan 27 16:21:27 2024 SIGUSR1[soft,dco-connect-error] received, process restarting
Sat Jan 27 16:21:28 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 16:21:28 2024 ovpn-dco device [OpenVPN Data Channel Offload] opened
Sat Jan 27 16:21:49 2024 dco connect error: Przekroczono limit czasu semafora. (errno=121)
Sat Jan 27 16:21:49 2024 SIGUSR1[soft,dco-connect-error] received, process restarting
Sat Jan 27 16:21:50 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 16:21:50 2024 ovpn-dco device [OpenVPN Data Channel Offload] opened
Sat Jan 27 16:22:11 2024 dco connect error: Przekroczono limit czasu semafora. (errno=121)
Sat Jan 27 16:22:11 2024 SIGUSR1[soft,dco-connect-error] received, process restarting
Sat Jan 27 16:22:12 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 16:22:12 2024 ovpn-dco device [OpenVPN Data Channel Offload] opened
Sat Jan 27 16:22:33 2024 dco connect error: Przekroczono limit czasu semafora. (errno=121)
Sat Jan 27 16:22:33 2024 SIGUSR1[soft,dco-connect-error] received, process restarting
...


It takes about few minutes to connect, just keeps retrying. When it is already connected, connection is stable. We have no clue, if this is a bug only when using powerpc cpu? There are no such problems on the other arm or mipsbe routers, where connection is very fast and stable.


--
Greets,
Marecky.

Can you add
To the client config?

Can you add

Code: Select all

disable-dco

To the client config?

Added.

Sat Jan 27 20:11:50 2024 OpenVPN 2.6.7 [git:v2.6.7/53c9033317b3b8fd] Windows [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Nov 8 2023
Sat Jan 27 20:11:50 2024 Windows version 10.0 (Windows 10 or greater), amd64 executable
Sat Jan 27 20:11:50 2024 library versions: OpenSSL 3.1.4 24 Oct 2023, LZO 2.10
Sat Jan 27 20:11:50 2024 DCO version: 1.0.0
Sat Jan 27 20:11:51 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 20:11:51 2024 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194
Sat Jan 27 20:13:52 2024 TCP: connect to [AF_INET]x.x.x.x:1194 failed: Unknown error
Sat Jan 27 20:13:52 2024 SIGUSR1[connection failed(soft),connection-failed] received, process restarting
Sat Jan 27 20:13:53 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 20:13:53 2024 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194
Sat Jan 27 20:15:54 2024 TCP: connect to [AF_INET]7x.x.x.x:1194 failed: Unknown error
Sat Jan 27 20:15:54 2024 SIGUSR1[connection failed(soft),connection-failed] received, process restarting
Sat Jan 27 20:15:55 2024 TCP/UDP: Preserving recently used remote address: [AF_INET]x.x.x.x:1194
Sat Jan 27 20:15:55 2024 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194
Sat Jan 27 20:16:10 2024 TCP connection established with [AF_INET]x.x.x.x:1194
Sat Jan 27 20:16:10 2024 TCPv4_CLIENT link local: (not bound)
Sat Jan 27 20:16:10 2024 TCPv4_CLIENT link remote: [AF_INET]x.x.x.x:1194
Sat Jan 27 20:16:11 2024 [srv] Peer Connection Initiated with [AF_INET]x.x.x.x:1194


Look, no dco, but making a connection is still about 5 minutes. Now it's conected and working. I had no issues with 6.49.
Also the UDP version of OpenVPN is still not stable - dropping packets when transfering data. Big drama, man


--
Greets,
Marecky.

Can you check that your input rules allow traffic to tcp and udp 1194 on your Mikrotik?

Everything is the same, filter rules are also the same as in 6.49.

actual input rules:

add action=accept chain=input comment=ICMP in-interface-list=WAN protocol=icmp
add action=accept chain=input comment=Winbox dst-port=8591 in-interface-list=WAN protocol=tcp src-address-list=Allowed_IPs
add action=accept chain=input comment=SSH dst-port=55505 in-interface-list=WAN protocol=tcp src-address-list=Allowed_IPs
add action=accept chain=input comment=OpenVPN dst-port=1194 in-interface-list=WAN protocol=tcp
add action=accept chain=input comment=DNS_NTP in-interface-list=WAN protocol=udp src-port=53,123
add action=accept chain=input comment=TCP_EST_REL connection-state=established,related in-interface-list=WAN protocol=tcp
add action=drop chain=input comment=DROP_ALL in-interface-list=WAN

Are these all your input rules? Also, no nat that would interfere?

If ok, can you export all the input and nat rules?

I will have a closer look tomorrow. First thing is your dns_ntp rule is dangerous.

No problem, my NAT rules:

/ip firewall nat
add action=masquerade chain=srcnat comment=NAT ipsec-policy=out,none out-interface-list=WAN src-address=192.168.0.0/24

Why do you think my DNS rule is dangerous ?
It's not dst-port, but src-port, only incoming traffic is allowed.

Because anyone sending udp datagrams with source port 53 or 123 can reach any udp port on your device.

Nat rule is ok. I will have a closer look tomorrow.

Regarding your input rules, can you send the full set? There is some reorganization possible that may help with the issue.

With the rules related to the interface WAN you sent, I would reorder in the following way. Note that without having the full input chain, I may just be duplicating existing entries.

Thank you for studying my firewall rules, appreciate for your changes. But.. the problem with VPN still remains, even without any rules it works the same way. I think it's some kind of bug regarding powerpc arch cpu or this particular model of routerboard.

I also noticed, after connection I have DRH flags on ovpn interface which means also hardware offload of the AES encryption.

It's very confusing, due to different documentation found on the web. RB850Gx2 is powerpc e500v2 cpu based. The CPU itself supports hardware decryption/encryption of AES-GCM cipher:
https://csrc.nist.gov/projects/Cryptogr ... number=488


When you look at the AES 256 GCM mikrotik hardware offload support, there is a big "no" to most of the MikroTik boards. It's about IPSec, but I think this is the same about OpenVPN:
https://help.mikrotik.com/docs/pages/vi ... d=54853770

Before diving into the guts of the openvpn server, I want to make sure that there is no network issue.

From the page you sent, the RB850Gx2 platform supports AES in CBC mode, at least for the devices whose SN starts with 5 or 7. It may be worth giving it a try and see whether that solves the issue - if that's the case, then the hardware offloading may be the cause, if not, then the issue likely lies somewhere else.

Well, I was using AES 256 CBC SHA1 for w long time with no issues on mikrotik routers, including this device. But, considering depreciated CBC cipher in OpenVPN Community and much much faster connection time using AES GCM, with ROS v7 I can use this cipher. As I already mentioned, I don't have problems with AES GCM on mipsbe and arm mikrotik based devices. That's why I still think it's something with ppc cpu or some kid of bug in ROSv7 software.

Well, I was using AES 256 CBC SHA1 for w long time with no issues on mikrotik routers, including this device. But, considering depreciated CBC cipher in OpenVPN Community and much much faster connection time using AES GCM, with ROS v7 I can use this cipher. As I already mentioned, I don't have problems with AES GCM on mipsbe and arm mikrotik based devices. That's why I still think it's something with ppc cpu or some kid of bug in ROSv7 software.

Yes, you mentioned it early on. My goal here is to isolate the issue - is moving to 7.xx or is the AES GCM implementation on PPC the issue. At the same time, if we find an algorithm or a configuration that works fine, albeit temporary, that will relieve the pain, but that means that you need to check that other algorithms are either working fine ... or not.

As an alternative to AES CBC, you can try blowfish128. I am pretty certain that one is not HW accelerated.