With any of the NSS options selected under Shortcut Forwarding Engine, traffic to/from OpenVPN tunnels appears to be blocked if DCO is enabled.
It works fine with the NSS options enabled if DCO is disabled.
It works fine with DCO enabled if I select SFE as the Shortcut Forwarding Engine.
However the combination of NSS and DCO results in an established tunnel but no traffic passes, either routed to other interfaces or to a port on the router itself. Running tcpdump on the tunnel interface doesn't show any traffic and the logs don't show anything relevant.
Router performance using SFE is fine, so I'm perfectly happy just to stick with that, but I'm curious. Is this behaviour to be expected?
I have two MX4300 running OpenVPN with NSS-ECM enabled (no SFE), and DCO works fine on them. The one running the OpenVPN server is in AP mode on DD-WRT and is not doing routing, so that may differ from your setup. The other one running OpenVPN client is in standard router mode in DD-WRT.
I know that using OpenVPN options that are incompatible with DCO will cause problems. I had mssfix enabled on the server, and it caused transfer rates to dramatically decline after a few seconds into the transfer. There doesn't seem to be a check for all options incompatible with DCO. Maybe check to make sure you are not using any? They are listed at https://community.openvpn.net/DataChannelOffload/Features
Joined: 07 Jan 2025 Posts: 244 Location: Bethel Park, PA, USA
Posted: Sat Jun 14, 2025 20:36 Post subject:
I'm running OpenVPN server on a similar MR7350 with NSS-ECM enabled. I don't have DCO disabled in the config, so I'm assuming it's using it. No issues connecting from a remote Windows client. I don't have MSS Fix enabled.
I know if I have CVE-2019-14899 Mitigation or Inbound Firewall on TUN enabled, it doesn't route. _________________ Formerly dpp3530 Linksys MR7350
Gateway, 2 wired APs, NSS-ECM , Clock 1440MHz
VAPs on wlan0 and wlan1 for guest/IOT devices
IPv4 & IPv6 (Prefix Delegation)
Static Leases & DHCP
SmartDNS (DOT using NextDNS, Cloudflare), DNSMasq
Wireguard and OpenVPN server
2.4GHz: dd-wrt, AX Only, ACK Timing 1350, WPA3 SAE & WPA2 w/AES
5GHz: dd-wrt, AX/AC/N Mixed, ACK Timing 1350, WPA3 SAE & WPA2 w/AES
Verizon Fios, 500/500Mbps
Thanks both. I do have inbound firewall rules configured on the tunnel interface so that could be a factor. I'll investigate further when I get an opportunity and report back.
I don't have DCO disabled in the config, so I'm assuming it's using it.
To confirm that DCO is active, you can look at the OpenVPN log or the system log (/var/log/messages if syslogd is enabled) when OpenVPN first starts up and search for DCO/dco. ie. "grep -i dco /var/log/messages" You should see the following lines:
net_iface_new: add tun1 type ovpn-dco
I DCO device tun1 opened
I also have CVE-2019-14899 Mitigation and Inbound Firewall on TUN disabled.
It doesn't look like the firewall rules are the issue. Deselecting Inbound Firewall on tun for the OpenVPN client adds a rule at the top of the input and forward chains that allows connections from the tunnel to the router or devices on other interfaces. On my setup, if I have DCO and NSS-ECM enable that rule shows no hits. Switch back to SFE and I see traffic hitting that rule.
I normally have that option on, and my own rules allowing connections out to the wan and selective connections to devices on my internal network. Either way, it makes no difference as I see no hits on any of the rules in the blocked state.
I use the client to connect to a Cloudconnexa account to get around CG-NAT with my current provider. Unfortunately in investigating this I've also spotted that key renegotiation is failing when DCO is enabled which means the connection gets restarted every hour. As Cloudconnexa offers very little control over the server side and there's no option to turn key renegotiation off (it's stuck at the hour default), I can't prevent it from trying - either the client initiates a renegotiation and seemly gets no response, or the server does and I get an error logged about stale keys.
Turn off DCO and renegotiation works as expected, which is what I've now done.
No idea if this is a Cloudconnexa incompatibility with a DCO client. I will leave a connection running to OpenVPN server on the router with key renegotiation and DCO enabled and see if that has similar issues.
Joined: 07 Jan 2025 Posts: 244 Location: Bethel Park, PA, USA
Posted: Sun Jun 15, 2025 19:34 Post subject:
BumRap wrote:
To confirm that DCO is active, you can look at the OpenVPN log or the system log (/var/log/messages if syslogd is enabled) when OpenVPN first starts up and search for DCO/dco. ie. "grep -i dco /var/log/messages" You should see the following lines:
net_iface_new: add tun1 type ovpn-dco
I DCO device tun1 opened
I also have CVE-2019-14899 Mitigation and Inbound Firewall on TUN disabled.
hmmmm.
Code:
root@Barricade:~# grep -i dco /var/log/messages
Dec 31 19:00:24.240 Barricade kern.info kernel: [ 24.245619] OpenVPN data channel offload (ovpn-dco) 2.0.0 -- (C) 2020-2023 OpenVPN, Inc.
Dec 31 19:00:24.514 Barricade daemon.notice openvpn[2136]: OpenVPN 2.6.14 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
Dec 31 19:00:24.514 Barricade daemon.notice openvpn[2136]: DCO version: N/A
No idea if this is a Cloudconnexa incompatibility with a DCO client. I will leave a connection running to OpenVPN server on the router with key renegotiation and DCO enabled and see if that has similar issues.
Connections to the OpenVPN server with DCO enabled (from a local device) outlast the standard 1 hour key renegotiation window. Useful for the rare occasions I want access from somewhere with IPv6 connectivity and don't have CG-NAT in the way, but I still have the traffic blocking issue where one of the NSS options is selected.
For now I'll stick with options that work even if sub-optimal. The ultimate answer may be to switch from OpenVPN to WireGuard but would still need some kind of relay to bridge the IPv4/IPv6 gap and my preference to use part of my IPv6 GUA /56 for remote devices seems not to be possible with Tailscale.
root@Barricade:~# grep -i dco /var/log/messages
Dec 31 19:00:24.240 Barricade kern.info kernel: [ 24.245619] OpenVPN data channel offload (ovpn-dco) 2.0.0 -- (C) 2020-2023 OpenVPN, Inc.
Dec 31 19:00:24.514 Barricade daemon.notice openvpn[2136]: OpenVPN 2.6.14 aarch64-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
Dec 31 19:00:24.514 Barricade daemon.notice openvpn[2136]: DCO version: N/A
If those are the only results, they suggest that DCO isn't being used. Another test is to run "ps |grep ovp". If DCO is active, you should see something like:
Joined: 18 Mar 2014 Posts: 13880 Location: Netherlands
Posted: Mon Jun 16, 2025 6:10 Post subject:
marks7389 wrote:
For now I'll stick with options that work even if sub-optimal. The ultimate answer may be to switch from OpenVPN to WireGuard but would still need some kind of relay to bridge the IPv4/IPv6 gap and my preference to use part of my IPv6 GUA /56 for remote devices seems not to be possible with Tailscale.
WireGuard fully supports IPv6, you can make a connection on IPv6 and then WireGuard will send both IPv4 and IPv6 traffic via the connection. So it works perfectly fine with CGNAT using IPv6 as the endpoint address to connect
WireGuard guides are a sticky in the Advanced Networking forum.
The OpenVPN, guides with some pointers about DCO, are also a sticky in the Advanced Networking forum but I do not know if it is supposed to work with NSS or not.
I know OpenWRT has NSS builds but I never saw this problem come up there because DCO is not standard enabled on OpenWRT (I have it enabled in my own builds but do not use NSS builds so cannot answer that either) _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
WireGuard fully supports IPv6, you can make a connection on IPv6 and then WireGuard will send both IPv4 and IPv6 traffic via the connection. So it works perfectly fine with CGNAT using IPv6 as the endpoint address to connect
Yes, the issue is more that I typically need to connect from locations (public / hotel WiFi / mobile networks) that are often not IPv6 enabled, so a direct WireGuard connection in those circumstances to a router behind CGNAT isn't possible.
Joined: 18 Mar 2014 Posts: 13880 Location: Netherlands
Posted: Mon Jun 16, 2025 11:22 Post subject:
marks7389 wrote:
egc wrote:
WireGuard fully supports IPv6, you can make a connection on IPv6 and then WireGuard will send both IPv4 and IPv6 traffic via the connection. So it works perfectly fine with CGNAT using IPv6 as the endpoint address to connect
Yes, the issue is more that I typically need to connect from locations (public / hotel WiFi / mobile networks) that are often not IPv6 enabled, so a direct WireGuard connection in those circumstances to a router behind CGNAT isn't possible.
That unfortunately is true.
Then you need to have a man in the middle.
I use an Oracle free VPS on which I have setup WireGuard and OpenVPN which can serve that purpose (not that I need it, I have full dual stack ).
I have a link added for that in the DDWRT WireGuard server setup guide
From that guide:
Quote:
If you are behind CGNAT and do not have IPv6 or using IPv6 is not applicable then you have to involve a third party to get a public IP address.
This can be a VPN provider which supports port forwarding, or you can rent a Virtual Private Server ( I have an Oracle VPS which can be had for free see at the bottom of this guide), or use things like Zerotier, Cloudflared, Tailscale or ngrok and there are more.
Joined: 07 Jan 2025 Posts: 244 Location: Bethel Park, PA, USA
Posted: Mon Jun 16, 2025 15:47 Post subject:
If you have Compression set to anything other than Disabled, it automatically disables DCO. For legacy reasons, I have Compression set to Adaptive.
Code:
19691231 19:00:43 Note: '--allow-compression' is not set to 'no' disabling data channel offload.
19691231 19:00:43 Consider using the '--compress migrate' option.
19691231 19:00:43 W WARNING: Using --management on a TCP port WITHOUT passwords is STRONGLY discouraged and considered insecure
19691231 19:00:43 I OpenVPN 2.6.14 arm-unknown-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [MH/PKTINFO] [AEAD] [DCO]
19691231 19:00:43 I library versions: OpenSSL 3.5.0 8 Apr 2025 LZO 2.10
19691231 19:00:43 I DCO version: N/A
).