A user reported[1] that after upgrading from Fedora 43 to Fedora 44, an OpenVPN client using ovpn stopped passing data traffic. The tunnel setup appears successful, but no traffic passes through the VPN. Adding --disable-dco on the client makes the same configuration work again.
Version:
OpenVPN 2.7.3 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
DCO version: 7.0.4-200.fc44.x86_64
The session initializes cleanly and DCO setup also appears successful:
DCO device ovpn-sfx opened
dco_set_peer: peer-id 0, keepalive 10/60, mss 1400
dco_new_key: slot 0, key-id 0, peer-id 0, cipher AES-256-GCM
Initialization Sequence Completed
While pinging through the failed DCO tunnel, dmesg does not report any errors. A capture on ovpn-sfx shows ICMP echo requests leaving the tunnel interface, but no echo replies coming back.
One early underlay capture showed something suspicious: UDP packets appeared to return to a different local UDP port than the one used by the active OpenVPN session, and the host replied with ICMP port-unreachable. However, a later capture that included the full handshake and subsequent ping test did not reproduce that port mismatch. In that later run, the underlay 5-tuple stayed consistent and there was bidirectional UDP traffic after the tunnel had come up. So the earlier port-unreachable packets could be stale traffic from a previous connection rather than the main failure mode.
[1] https://sourceforge.net/p/openvpn/mailman/message/59334334/
A user reported[1] that after upgrading from Fedora 43 to Fedora 44, an OpenVPN client using ovpn stopped passing data traffic. The tunnel setup appears successful, but no traffic passes through the VPN. Adding
--disable-dcoon the client makes the same configuration work again.Version:
OpenVPN 2.7.3 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
DCO version: 7.0.4-200.fc44.x86_64
The session initializes cleanly and DCO setup also appears successful:
While pinging through the failed DCO tunnel, dmesg does not report any errors. A capture on
ovpn-sfxshows ICMP echo requests leaving the tunnel interface, but no echo replies coming back.One early underlay capture showed something suspicious: UDP packets appeared to return to a different local UDP port than the one used by the active OpenVPN session, and the host replied with ICMP port-unreachable. However, a later capture that included the full handshake and subsequent ping test did not reproduce that port mismatch. In that later run, the underlay 5-tuple stayed consistent and there was bidirectional UDP traffic after the tunnel had come up. So the earlier port-unreachable packets could be stale traffic from a previous connection rather than the main failure mode.
[1] https://sourceforge.net/p/openvpn/mailman/message/59334334/