Followup on OpenVPN DCO issue (disconnect after 1h)

[Torsten]

Just a quick update on

RUTX50 OpenVPN DCO not working on latest FW 07.14.2

Hi, I have several RUTX50 connecting to the same OpenVPN server (CloudConnexa). Firmware RUTX_R_00.07.08.2 no problems (and it already comes with DCO option enabled by default, if I understand correctly?) Firmware RUTX_R_00.07.14.2 openvpn disconnects and reconnects every few minutes. Log file is flooded with these 2 lines 6114 Fri May 23 11:16:02 2025 daemon.notice openvpn(inst1)[11454]: dco_get_peer_stats: netlink reports object not found, ovpn-dco unloaded? 6115 Fri May 23 11:16:02 2025…

Still present in all latest firmwares of X50, RUT955, RUT956, RUT240 etc.

keepalive (or auto-pings) do not help.
Only “disable-dco” helps.

Root cause:
TLS session need to be renewed after 1h.

OpenVPN server is Cloudconnexa, all Teltonika Routers are clients here.

without DCO there is a TLS soft reset, the log reads:
985 Tue Jul 29 07:13:38 2025 daemon.notice openvpn(inst1)[3465]: TLS: tls_process: killed expiring key
986 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: TLS: soft reset sec=3600/3600 bytes=0/-1 pkts=0/0
987 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: net_route_v4_best_gw query: dst 0.0.0.0
988 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: net_route_v4_best_gw result: via 0.0.0.0 dev qmimux0
989 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: VERIFY OK: depth=1, CN=CloudVPN Prod CA
990 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: VERIFY KU OK
991 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: Validating certificate extended key usage
992 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
993 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: VERIFY EKU OK
994 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: VERIFY OK: depth=0, CN=de-fra-dc1-b1.cloud.openvpn.net
995 Tue Jul 29 07:13:39 2025 daemon.notice openvpn(inst1)[3465]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519

With DCO enabled (default), there is a hard break and full reconnect, which even causes the server to refuse the first attempt because server still considers old tunnel as active (multiple connecdtions not allowed).
Log on Teltonika as client reads:

4833 Tue Jul 29 14:30:42 2025 daemon.notice openvpn(inst1)[4176]: TLS: soft reset sec=3600/3600 bytes=0/-1 pkts=0/0
4849 Tue Jul 29 14:31:42 2025 daemon.err openvpn(inst1)[4176]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
4850 Tue Jul 29 14:31:42 2025 daemon.err openvpn(inst1)[4176]: TLS Error: TLS handshake failed
4851 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: TLS: move_session: dest=TM_LAME_DUCK src=TM_ACTIVE reinit_src=1
4857 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: TLS: Initial packet from [AF_INET6]2a00:c98:2050:a042:2::5:1194, sid=b5c2d0df fb6af37c
4858 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: net_route_v4_best_gw query: dst 0.0.0.0
4859 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: net_route_v4_best_gw result: via 0.0.0.0 dev qmimux0
4865 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: VERIFY OK: depth=1, CN=CloudVPN Prod CA
4866 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: VERIFY KU OK
4867 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: Validating certificate extended key usage
4868 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
4869 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: VERIFY EKU OK
4870 Tue Jul 29 14:31:42 2025 daemon.notice openvpn(inst1)[4176]: VERIFY OK: depth=0, CN=de-fra-dc2-b1.cloud.openvpn.net
4872 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_CHACHA20_POLY1305_SHA256, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
4873 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
4874 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: TLS: tls_multi_process: initial untrusted session promoted to trusted
4875 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: PUSH: Received control message: ‘PUSH_REPLY,route-gateway 10.1.6.145,ifconfig 10.1.6.146 255.255.255.240,ifconfig-ipv6 fd:0:0:8169::2/64 fd:0:0:8169::1,client-ip 2a01:599:140:5d03:6dae:124a:ee85:40d2,ping 8,ping-restart 40,reneg-sec 3600,cipher AES-256-GCM,peer-id 13784,protocol-flags tls-ekm dyn-tls-crypt cc-exit,topology subnet,explicit-exit-notify,remote-cache-lifetime 86400,block-outside-dns,dhcp-option ADAPTER_DOMAIN_SUFFIX inst1.vpn,route 10.1.0.0 255.255.0.0,route-ipv6 fd:0:0:8000::/49,route 10.2.0.0 255.255.0.0,route-ipv6 fd:0:0:4000::/50,dhcp-option DNS 10.1.6.145,auth-tokenSESS_ID,auth-token-user ZW5zaWJvL2Nvbm5lY3Rvci8wMzQyMzAxOC04ZjRmLTQ0N2YtODhkYy1hZjQ0MmQ2NTc3NmRfNGQ5OWI3OWMtNDJmNS00NDZjLWEzMTAtM2JkYjUyZjgwZTc0’
4876 Tue Jul 29 14:31:43 2025 daemon.err openvpn(inst1)[4176]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: client-ip (2.6.9)
4877 Tue Jul 29 14:31:43 2025 daemon.err openvpn(inst1)[4176]: Options error: option ‘reneg-sec’ cannot be used in this context ([PUSH-OPTIONS])
4878 Tue Jul 29 14:31:43 2025 daemon.err openvpn(inst1)[4176]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:13: remote-cache-lifetime (2.6.9)
4879 Tue Jul 29 14:31:43 2025 daemon.err openvpn(inst1)[4176]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:14: block-outside-dns (2.6.9)
4880 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: Initialization Sequence Completed
4882 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: Data Channel: cipher ‘AES-256-GCM’, peer-id: 13784
4883 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: Timers: ping 8, ping-restart 40
4884 Tue Jul 29 14:31:43 2025 daemon.notice openvpn(inst1)[4176]: Protocol options: explicit-exit-notify 1, protocol-flags cc-exit tls-ekm dyn-tls-crypt
4885 Tue Jul 29 14:31:43 2025 daemon.err openvpn(inst1)[4176]: TLS ERROR: received control packet with stale session-id=7148def2 322cc0e6
4889 Tue Jul 29 14:31:44 2025 daemon.err openvpn(inst1)[4176]: TLS ERROR: received control packet with stale session-id=7148def2 322cc0e6
(repeats, but session is working for next 59 minutes)

[Marija]

Hello,

I’ve sent you a form to fill out. Once it’s completed, I will contact you privately regarding this issue. For the ticket ID, please use “14922”.

Best regards,

[Marija]

Hello,

Hope you are doing well!

The analysis was did, and in most cases the problems with DCO are related to network issues. I would like to point out that the logs below in most cases do not indicate an issue.

10537 Wed May 14 00:10:23 2025 daemon.notice openvpn(inst1)[19544]: dco_get_peer_stats: netlink reports object not found, ovpn-dco unloaded?
10538 Wed May 14 00:10:23 2025 daemon.notice openvpn(inst1)[19544]: dco_get_peer_stats: failed to send netlink message: No such file or directory (-2)

The messages you are seeing in the logs are informational messages from the VPN software. They appear when the software checks for certain performance statistics and does not receive them back from the system.

The main your device problem is:

822 Fri Aug  1 11:41:41 2025 daemon.err openvpn(Ensibo)[10551]: TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
823 Fri Aug  1 11:41:41 2025 daemon.err openvpn(Ensibo)[10551]: TLS Error: TLS handshake failed

and it happens after:

816 Fri Aug  1 11:40:41 2025 daemon.notice openvpn(Ensibo)[10551]: TLS: soft reset sec=3600/3600 bytes=0/-1 pkts=0/0

This indicates the TLS key renegotiation process, which by default occurs every 1 hour. During this process, connectivity issues with the server are causing the failure.

What can help

1. The issues usually occur when using OpenVPN CloudConnexa , which by default connects to the server over UDP . However, it is also possible to use TCP . Often, when problems are caused by network issues, switching from UDP to TCP helps.

Example:

remote nl-ams.gw.openvpn.com 1194 udp
remote nl-ams.gw.openvpn.com 443 tcp

change priority to

remote nl-ams.gw.openvpn.com 443 tcp
remote nl-ams.gw.openvpn.com 1194 udp

in openvpn configuration.

2. If possible, ensure a stable network connection with the remote server, avoiding packet delays, packet loss, and similar issues.
3. Since the problem usually occurs during the TLS key renegotiation process, you can try disable it by adding the extra option reneg-sec 0 . This will disable TLS key renegotiation .
4. DCO mode is not mandatory, the connection can work without it as well. You can disable it by adding the extra option disable-dco .

Best regards,

[Torsten]

Hello @Marija ,

thanks for the analysis. But you only confirm what I already stated: There is an issue with the TLS renegotiation when DCO on.

We do not experience this issue on other Routers (e.g. Insys with latest firmware). They use the same mobile network and connect to the same (CloudConnexa) Ovpn server, and support DCO now.

All 4 suggestions are just workarounds:

1. No possible on remote routers, where ovpn profile was uploaded without parsing option. Also, since this is a very regular problem (precisely every 3600 seconds, on several routers at multiple locations all over the country), I do not point to “unstable internet connection”.
2. The connection has not changed, only the Teltonika Firmware.
3. workaround, but I put it to the server settings for client push-option
4. workaround, but I put it to the server settings for client push-option

Hope to see DCO working in the future over 5G-NSA and 4G internet connections of stationary remote routers.

All the best,

Torsten

[Marija]

Hello,

@Torsten

No possible on remote routers, where ovpn profile was uploaded without parsing option. Also, since this is a very regular problem (precisely every 3600 seconds, on several routers at multiple locations all over the country), I do not point to “unstable internet connection”.

It is possible. If you don’t want to parse, you can modify the OpenVPN config file before uploading.

@Marija

Since the problem usually occurs during the TLS key renegotiation process, you can try disable it by adding the extra option reneg-sec 0 . This will disable TLS key renegotiation

It is enough to add this option on the client side to disable renegotiation.

@Marija

DCO mode is not mandatory, the connection can work without it as well. You can disable it by adding the extra option disable-dco

It is enough to add this option on the client side to disable dco.

Additionally, our developers are currently testing an updated OpenVPN version, which will be included starting from the 7.19 RutOS firmware release. It should provide more stability. Let me know if you’d like to test it, and I can provide you with the test firmware.

Best regards,

[Torsten]

perfect, thanks. We will wait for the official 7.19 release.