OpenVpn with DCO

[swixo]

Successfully installed 22.05 and converted our s-s OpenVPN to TLS with a /24 tunnel. DCO works and seems to lower cpu load well.

The issue is with our remote access clients. Enabling DCO usually gets a connection when clients initiate - but most of the time no data flows. Turning off DCO for that tunnel (and no other changes) restores full functionality.

Should also be noted that these failed connections get "Stuck" and do not disappear from the dashboard when terminated, so they just accumulate.
LMK if I can debug further.

[jimp]

Did you export new client configurations or continue to use old ones?

What is in the remote access server configuration? And in the client configuration?

I've tested with several different types of mobile clients (pfSense, Linux, OS X, Windows) and haven't hit an issue with passing traffic in quite some time. But that's in a lab and not "real world" type conditions.

Do those clients ever work? Or does it work initially then stop? Maybe only fails if/when they reconnect?

Any errors in the OpenVPN log when it happens?

[swixo]

@jimp
These are the same configs from before.
These clients have been working for years - and DO work with DCO off.
The log does have some interesting entries:

May 27 14:00:51	openvpn	90679	172.58.37.180:37916 tls-crypt unwrap error: packet replay
May 27 14:00:51	openvpn	90679	172.58.37.180:37916 tls-crypt unwrap error: bad packet ID (may be a replay): [ #8 / time = (1653685250) 2022-05-27 14:00:50 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
May 27 14:00:51	openvpn	90679	172.58.37.180:37916 TLS Error: tls-crypt unwrapping failed from [AF_INET]172.58.37.180:37916 (via [AF_INET]107.3.143.19%)
May 27 14:00:51	openvpn	90679	172.58.37.180:37916 tls-crypt unwrap error: packet replay
May 27 14:00:51	openvpn	90679	172.58.37.180:37916 tls-crypt unwrap error: bad packet ID (may be a replay): [ #7 / time = (1653685250) 2022-05-27 14:00:50 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
~~~

These were experienced when I connected to a client that failed.

s

[swixo]

Tried just about everything - the only thing that allows traffic to flow is DCO=off.

LMK if you can think of some other setting or usage that could/would effect this that I can try.

(The tunnel is using a TLS key both dir, UDP, tun, 4096 DH, 256gcm, SHA512 digest auth.)

[RabidSasquatch]

@swixo Try changing your digest algorithm to SHA256 (256 bit). I was unable to connect using DCO until I switched from SHA512 to SHA256. Not sure why but hopefully it will also work for you.

[swixo]

@rabidsasquatch Hey that worked!

DCO fails with SHA512.

Thanks VM!

[stephenw10]

DCO is SHA256 only right now. When you enable it at either end it forces that bit if you have older clients with existing config it will then become mismatched.

Steve