Hello, I have to report this issue again. It's a problem I've had since purchasing the MT3000 that I've never been able to solve. You can see a detailed description of my problem here: IPv6 OpenVPN Client on 4.8.1 Won’t Forward Traffic on GL‑MT3000
In short, the MT3000 can establish a connection with my home OpenVPN router (proto udp6, only allowing IPv6 inbound) via Android's USB tethering, but once the connection is established, no traffic is forwarded.
Then, the client and server reconnect at a specified time (because ping also fails to send).
I take out my MT3000 every time I need to travel, and it fails every time.
Thank you very much for your previous attempts to help me diagnose the problem, but unfortunately, my problem remains unresolved.
I look forward to any help.
Thank you very much.
—-
From: AI
Bug Report: OpenVPN Client Data Channel Non-Functional
Device: GL.iNet router (OpenWRT-based)
Firmware OpenVPN version: 2.6.12
Issue: OpenVPN tunnel control channel establishes successfully, but data channel passes no traffic.
ENVIRONMENT
- WAN connection via WiFi client mode, with public IPv6 address
- OpenVPN server configured with proto udp6, tls-crypt-v2, topology subnet
- Same client configuration works perfectly on iOS, Android, and other devices on the same hotspot
SYMPTOMS
- OpenVPN handshake completes successfully, "Initialization Sequence Completed" logged
- ovpnclient1 interface RX bytes remain zero permanently
- Server receives UDP packets from router but drops them silently
- Ping between tunnel endpoints fails in both directions
DIAGNOSIS FINDINGS
Finding 1: ovpn_dco_v2 kernel module decrypt failure
dmesg shows continuous decrypt errors for every incoming data packet:
"ovpn_aead_decrypt: decrypt failed: -74 (EBADMSG)"
"ovpn_decrypt_one: error during decryption for peer 0, key-id 0: -74"
The DCO module receives encrypted packets on the correct port but fails to decrypt them. This repeats every 15 seconds matching the keepalive interval until the connection is dropped.
Finding 2: ovpn_dco_v2 corrupts standard tun device
After adding disable-dco to bypass the DCO module, OpenVPN opens the tun device successfully and reports "Initialization Sequence Completed", but immediately produces the following error on every incoming packet:
"write to TUN/TAP: Invalid argument (fd=-1, code=22)"
This occurs even after a full reboot with no OpenVPN process running. The tun device reports "File descriptor in bad state" when accessed directly.
Finding 3: rmmod confirms ovpn_dco_v2 as root cause
After manually unloading the ovpn_dco_v2 module, the tun device returns to normal state. OpenVPN with disable-dco then opens tun0 correctly and traffic flows into tun0. UDP packets are confirmed leaving the WAN interface and arriving at the server. However the server still discards packets, suggesting that the presence of ovpn_dco_v2 during session initialization corrupts the data channel key exchange even after the module is unloaded.
Finding 4: GL.iNet netifd and tun device ownership conflict
The --route-noexec flag passed by GL.iNet's netifd proto handler prevents OpenVPN from installing routes, which are instead managed by netifd scripts. However the interaction between netifd's interface management and OpenVPN's tun device ownership causes conflicts when DCO is disabled, contributing to the fd=-1 condition.
CONCLUSION
The ovpn_dco_v2 kernel module (version 2.0.0) is incompatible with OpenVPN 2.6.12, specifically with tls-crypt-v2 and dyn-tls-crypt negotiated sessions. The module silently fails to decrypt data channel traffic, and its presence corrupts the standard tun device as a side effect. This renders the OpenVPN client completely non-functional for data transfer despite successful tunnel establishment. The control channel handshake succeeds normally, making the issue difficult to detect without deep inspection.
REQUEST
Please update the ovpn_dco_v2 kernel module to be compatible with OpenVPN 2.6.12 and tls-crypt-v2, or provide a supported method to fully disable DCO without the tun device corruption side effect.