OpenVPN Connect 3.6.0 fails to connect to the ROS 7.17 OpenVPN Server, showing an error indicating decryption failure.

OpenVPN Connect 3.6.0 successfully connects to the ROS 7.17 OpenVPN Server. However, when accessing an intranet webpage, the OpenVPN client disconnects with the message: “Required credentials are missing for the reconnection attempt.” .Reviewing the logs reveals a decryption failure warning.Testing revealed that there might be an issue with AES-256-GCM decryption, but OpenVPN Connect uses AES-256-GCM by default. I’d like to ask if ROS 7.1.7 has made any changes to the AES-256-GCM implementation.

[Jan 20, 2025, 16:22:21] OpenVPN core 3.10.5 win x86_64 64-bit OVPN-DCO built on Dec 17 2024 12:24:32
⏎[Jan 20, 2025, 16:22:21] Frame=512/2112/512 mssfix-ctrl=1250
⏎[Jan 20, 2025, 16:22:21] NOTE: This configuration contains options that were not used:
⏎[Jan 20, 2025, 16:22:21] Unsupported option (ignored)
⏎[Jan 20, 2025, 16:22:21] 0 [resolv-retry] [infinite]
⏎[Jan 20, 2025, 16:22:21] 1 [persist-key]
⏎[Jan 20, 2025, 16:22:21] 2 [persist-tun]
⏎[Jan 20, 2025, 16:22:21] EVENT: RESOLVE ⏎[Jan 20, 2025, 16:22:21] EVENT: WAIT ⏎[Jan 20, 2025, 16:22:21] WinCommandAgent: transmitting bypass route to 117.88.226.24
{
	"host" : "117.88.226.24",
	"ipv6" : false
}

⏎[Jan 20, 2025, 16:22:21] Connecting to [xxx.com]:1194 (117.88.226.24) via TCPv4
⏎[Jan 20, 2025, 16:22:21] EVENT: CONNECTING ⏎[Jan 20, 2025, 16:22:21] Tunnel Options:V4,dev-type tun,link-mtu 1523,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
⏎[Jan 20, 2025, 16:22:21] Creds: Username/Password
⏎[Jan 20, 2025, 16:22:21] Clearing credentials
⏎[Jan 20, 2025, 16:22:21] Sending Peer Info:
IV_VER=3.10.5
IV_PLAT=win
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2974
IV_MTU=1600
IV_CIPHERS=AES-128-CBC:AES-192-CBC:AES-256-CBC:AES-128-GCM:AES-192-GCM:AES-256-GCM:CHACHA20-POLY1305
IV_GUI_VER=OCWindows_3.6.0-4074
IV_SSO=webauth,crtext

⏎[Jan 20, 2025, 16:22:21] SSL Handshake: peer certificate: CN=*.ros-vpn-dtops.cc, 2048 bit RSA, cipher: ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2 Kx=ECDH     Au=RSA   Enc=AESGCM(256)            Mac=AEAD

⏎[Jan 20, 2025, 16:22:21] Session is ACTIVE
⏎[Jan 20, 2025, 16:22:21] EVENT: GET_CONFIG ⏎[Jan 20, 2025, 16:22:21] Sending PUSH_REQUEST to server...
⏎[Jan 20, 2025, 16:22:21] OPTIONS:
0 [dhcp-option] [DNS] [223.5.5.5]
1 [dhcp-option] [DNS] [223.6.6.6]
2 [ping] [5]
3 [ping-restart] [15]
4 [topology] [subnet]
5 [route-gateway] [172.20.0.254]
6 [route] [10.0.0.0] [255.255.255.0]
7 [route] [172.16.16.0] [255.255.255.0]
8 [route] [192.168.88.0] [255.255.254.0]
9 [route] [10.30.0.0] [255.255.0.0]
10 [ifconfig] [172.20.0.237] [255.255.255.0]
11 [peer-id] [21]

⏎[Jan 20, 2025, 16:22:21] PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: none
  key-derivation: OpenVPN PRF
  compress: NONE
  peer ID: 21

⏎[Jan 20, 2025, 16:22:21] EVENT: ASSIGN_IP ⏎[Jan 20, 2025, 16:22:21] CAPTURED OPTIONS:
Session Name: xxx.com
Layer: OSI_LAYER_3
Remote Address: 117.88.226.24
Tunnel Addresses:
  172.20.0.237/24 -> 172.20.0.254
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv4: no
Block IPv6: no
Block local DNS: no
Add Routes:
  10.0.0.0/24
  172.16.16.0/24
  192.168.88.0/23
  10.30.0.0/16
Exclude Routes:
DNS Servers:
  223.5.5.5
  223.6.6.6

⏎[Jan 20, 2025, 16:22:21] SetupClient: transmitting tun setup list to \\.\pipe\agent_ovpnconnect
{
	"allow_local_dns_resolvers" : false,
	"confirm_event" : "4811000000000000",
	"destroy_event" : "2811000000000000",
	"tun" : 
	{
		"adapter_domain_suffix" : "",
		"add_routes" : 
		[
			{
				"address" : "10.0.0.0",
				"gateway" : "",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			},
			{
				"address" : "172.16.16.0",
				"gateway" : "",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			},
			{
				"address" : "192.168.88.0",
				"gateway" : "",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 23
			},
			{
				"address" : "10.30.0.0",
				"gateway" : "",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 16
			}
		],
		"block_ipv6" : false,
		"block_outside_dns" : false,
		"dns_options" : 
		{
			"servers" : {}
		},
		"dns_servers" : 
		[
			{
				"address" : "223.5.5.5",
				"ipv6" : false
			},
			{
				"address" : "223.6.6.6",
				"ipv6" : false
			}
		],
		"layer" : 3,
		"mtu" : 0,
		"remote_address" : 
		{
			"address" : "117.88.226.24",
			"ipv6" : false
		},
		"reroute_gw" : 
		{
			"flags" : 256,
			"ipv4" : false,
			"ipv6" : false
		},
		"route_metric_default" : -1,
		"session_name" : "xxx.com",
		"tunnel_address_index_ipv4" : 0,
		"tunnel_address_index_ipv6" : -1,
		"tunnel_addresses" : 
		[
			{
				"address" : "172.20.0.237",
				"gateway" : "172.20.0.254",
				"ipv6" : false,
				"metric" : -1,
				"net30" : false,
				"prefix_length" : 24
			}
		]
	},
	"tun_type" : 0
}
POST np://[\\.\pipe\agent_ovpnconnect]/tun-setup : 200 OK
TAP ADAPTERS:
guid='{7989DA32-F7F6-431A-9286-645B175147BC}' index=10 name='本地连接'
Open TAP device "本地连接" PATH="\\.\Global\{7989DA32-F7F6-431A-9286-645B175147BC}.tap" SUCCEEDED
TAP-Windows Driver Version 9.27
ActionDeleteAllRoutesOnInterface iface_index=10
netsh interface ip set interface 10 metric=9000
确定。
netsh interface ip set address 10 static 172.20.0.237 255.255.255.0 gateway=172.20.0.254 store=active
IPHelper: add route 10.0.0.0/24 10 172.20.0.254 metric=-1
IPHelper: add route 172.16.16.0/24 10 172.20.0.254 metric=-1
IPHelper: add route 192.168.88.0/23 10 172.20.0.254 metric=-1
IPHelper: add route 10.30.0.0/16 10 172.20.0.254 metric=-1
netsh interface ip set dnsservers 10 static 223.5.5.5 register=primary validate=no
netsh interface ip add dnsservers 10 223.6.6.6 2 validate=no
NRPT::ActionCreate pid=[5700] domains=[] dns_servers=[223.5.5.5,223.6.6.6] dnssec=[0] id=[OpenVPNDNSRouting-5700]
DNS::ActionApply: successful
ActionBase openvpn_app_path=C:\Program Files\OpenVPN Connect\OpenVPNConnect.exe tap_index=10 enable=1
permit IPv4 requests from OpenVPN app
permit IPv6 requests from OpenVPN app
block IPv4 requests from other apps
block IPv6 requests from other apps
allow IPv4 traffic from TAP
allow IPv6 traffic from TAP
block IPv4 DNS requests to loopback from other apps
block IPv6 DNS requests to loopback from other apps
ipconfig /flushdns
Windows IP 配置
已成功刷新 DNS 解析缓存。
TAP: ARP flush succeeded
TAP handle: f412000000000000
⏎[Jan 20, 2025, 16:22:21] Connected via TUN_WIN
⏎[Jan 20, 2025, 16:22:21] EVENT: CONNECTED user1@xxx.com:1194 (117.88.226.24) via /TCPv4 on TUN_WIN/172.20.0.237/ gw=[172.20.0.254/] mtu=(default)⏎[Jan 20, 2025, 16:22:26] Session invalidated: DECRYPT_ERROR
⏎[Jan 20, 2025, 16:22:26] Client terminated, restarting in 2000 ms...
⏎[Jan 20, 2025, 16:22:26] SetupClient: signaling tun destroy event
⏎[Jan 20, 2025, 16:22:28] EVENT: RECONNECTING ⏎[Jan 20, 2025, 16:22:28] EVENT: RESOLVE ⏎[Jan 20, 2025, 16:22:28] EVENT: WAIT ⏎[Jan 20, 2025, 16:22:28] WinCommandAgent: transmitting bypass route to 117.88.226.24
{
	"host" : "117.88.226.24",
	"ipv6" : false
}

⏎[Jan 20, 2025, 16:22:28] Connecting to [xxx.com]:1194 (117.88.226.24) via TCPv4
⏎[Jan 20, 2025, 16:22:28] EVENT: CONNECTING ⏎[Jan 20, 2025, 16:22:28] Tunnel Options:V4,dev-type tun,link-mtu 1523,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-GCM,auth [null-digest],keysize 256,key-method 2,tls-client
⏎[Jan 20, 2025, 16:22:28] Creds: UsernameSessionId/PasswordEmpty
⏎[Jan 20, 2025, 16:22:28] Transport Error: missing password
⏎[Jan 20, 2025, 16:22:28] EVENT: NEED_CREDS ⏎[Jan 20, 2025, 16:22:28] EVENT: DISCONNECTED ⏎

Same problem when connecting an Android phone using OpenVPN Connect 3.5.1.

This started when updating to RouterOS v7.17.1, in version 7.16.2 this did not occur.

I tested it in version 7.17.1 using OpenVPN in UDP and the error does not occur, I still need a solution to make it work in v7.17.1 in TCP

I have similar issue on ROS 7.17.1. Both IOS (OVPN 3.5.1) & Android (OVPN 3.5.1) clients keep disconnecting with “peer disconnected” message

I managed to make it work by changing TCP to UDP
And with the following changes.
Remove the parameter;
auth-nocache

Changing
auth SHA1 to auth SHA256
tun-mtu 1500 to tun-mtu 1400

I had no problems with Windows and Linux stations, only cell phone connections need these adjustments.

You are right, changed protocol to UDP and the connection was stable!

Also, windows client works with TCP, but the connection is extremely slow. Changing MTU did not solve issue.

Hi everyone. I found solution: change cipher AES-256-GCM to cipher AES-256-CBC, and all work fine with tcp connection. All works fine with OVPN Connect 3.6.0 on Android 14. My ROS 7.18.1

Hello everyone,

The issue persists with OpenVPN Server on ROS 7.18.2 when using AES-256-GCM on an RB4011iGS+ (ARM).

Logs:

Fatal decryption error: cipher final failed  
Fatal decryption error (process_incoming_link), restarting.

I thought this problem was resolved with the changelog in version 7.18.1:

*) ovpn - disable hardware accelerator for GCM on MMIPS CPUs (introduced in v7.18);

However, that’s not the case.

No issues occur when reverting to version 7.16.2.

Thanks in advance for your help.

Hi all,

I have nearly the same issue. RB4011iGS+ (ROS 7.18.2) is the openvpn client (using proto tcp and certificates). The openvpn (OpenVPN 2.6.12 x86_64-pc-linux-gnu) server is a Gentoo Linux. The tunnel is established without any problem. I can even access the RB4011iGS+ through the tunnel.

But as soon as I increase the tunnel traffic a little bit (e.g. running the command /log/print) the tunnel goes down is immediatly re-established.

In the server log I can see:

AEAD Decrypt error: cipher final failed
Fatal decryption error (process_incoming_link), restarting
SIGUSR1[soft,decryption-error] received, client-instance restarting

Changing the cipher from aes256-gcm to aes128-gcm did not help.

Heino

Hi again,

changing the cipher to aes256-cbc solved my problem:

openvpn config server:

data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC

openvpn config client (RB4011iGS+):

/interface/ovpn-client add name=... cipher=aes256-cbc

Heino