22.05 - DCO and OpenVPN issue

jimp

I think this is what I hit yesterday with multiple clients failing (only the first client, e.g. .2 worked). We got a fix in yesterday afternoon and made a new build. You should be able to update to that and try it.

swixo

This post is deleted!

swixo

@jimp I may have spoken too soon -- It worked once - but shortly after - same problem returned.

Did a server restart - and its blocking data again w/DCO. Sorry for any false start - just reporting what I'm seeing.

jimp

Odd. I can't reproduce any problem now, and I could before. I've restarted the server and clients multiple times. Not just reboots but daemon restarts.

swixo

@jimp So I tried again with MacOS - working with DCO. No erros in logs. Connected with iOS - nothing. And as soon as I connected with iOS, the MacOS connection stopped working too.

Log errors at time of failure:

Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #9 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #8 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

maverick_slo

For me, Android now works OK.
But I had to disable DCO, because it`s like 40% slower than without it...

jimp

@maverick_slo said in 22.05 - DCO and OpenVPN issue:

For me, Android now works OK.
But I had to disable DCO, because it`s like 40% slower than without it...

If your hardware supports AES-NI, make sure the AES-NI kernel module is loaded (System > Advanced, Misc tab).

The only time we've seen DCO be slower is when the hardware supports crypto acceleration but it's not enabled in the kernel/modules. DCO is in the kernel so it can't just latch onto AES-NI via OpenSSL like non-DCO OpenVPN can.

jimp

@swixo said in 22.05 - DCO and OpenVPN issue:

@jimp So I tried again with MacOS - working with DCO. No erros in logs. Connected with iOS - nothing. And as soon as I connected with iOS, the MacOS connection stopped working too.

Log errors at time of failure:

Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #9 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 TLS Error: tls-crypt unwrapping failed from [AF_INET]192.168.1.212:54428 (via [AF_INET]192.168.1.1%)
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: packet replay
Jun 15 10:48:35	openvpn	2705	192.168.1.212:54428 tls-crypt unwrap error: bad packet ID (may be a replay): [ #8 / time = (1655315314) 2022-06-15 10:48:34 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings

I still can't reproduce any problems here. Replay errors suggest it's a network-level problem with packets arriving out of order, though.

swixo

@jimp Updated to 22.05.r.20220617.0613 this AM.

Similar situation - First client to connect - its good. Second client to connect - Both lose data flow.

maverick_slo

It7s loaded...
AES-NI CPU Crypto: Yes (active)

But still it is really slower...

tman222

Hi @jimp - just upgraded my 22.01 system to 22.05 RC and seeing the same issues that @swixo and @maverick_slo have described when DCO is enabled on OpenVPN.

In my case I'm using two clients:

iPhone with iOS 15.5 and version 3.2.3 of the OpenVPN Connect client for iOS
Macbook Pro with macOS 12.4 and latest version of Tunnelblick VPN client (3.8.7a)

Each client will work fine when connected individually. If I connect both then both will lose data flow as soon as the second client is connected (the order in which they are connected doesn't seem to matter). I've increased the verbosity on the OpenVPN logs but can't really see anything that looks to the a problem. Are there any settings on the client or server side I should doublecheck? I basically just enabled DCO on the server and tried things out. As a sanity check, I did disable DCO and then connected both clients - everything worked fine (i.e. data flow was not interrupted).

EDIT: Just tried with a non Apple client as well (Debian 11.3 Linux system). As soon as second client connects both lose data flow.

Regarding speed:

On the iPhone (WiFi) having DCO enabled is slower for me also (especially download) compared to no DCO with Fast I/O and 512KB buffer sizes.
On the Macbook Pro (wired) it is just as fast if not a tad faster, which I thought was interesting.

Thanks in advance for your help.

tman222

One additional thing I thought of: I did create an OpenVPN interface ovpns1 when I originally set things up. Are there any configuration settings I should be checking with respect to that interface (e.g. MTU, MSS, etc.)? Thanks again.

tman222

I'm curious if you guys had any idea on how to troubleshoot this further? The only thing I have not tried yet is creating a brand new OpenVPN server (tunnel) from scratch to see if that resolves the data flow issues. @swixo and @maverick_slo - have you guys tried this yet? Thanks in advance.

swixo

@tman222 I have not tried deleting the tunnel and starting over - although I may create a new one and see if it is ok.

We have a bug in either case and I want to preserve the failure condition so I can verify a proper fix if offered.

swixo

@swixo This issue has been reliably reproduced (and still failing) on 22.05-RELEASE (amd64).

jimp

There must be something different about your setup. I still can't reproduce a problem here. I have three clients connected (pfSense, Windows, and OSX) and they all have working connectivity across the VPN.

swixo

@jimp I must have a setting aggravating it - user tman seems to have same issue.
Just in case - here are my settings:

DCO=on
Mode: TUN
Proto: UDP/v4
interface: Any 
Use Tls Key: Checked
TLS Usage: Enc and Auth
TLS KeyDir: Both
No Cert Rev List
No OCSP Check
DH: 4096
ECDH: secp384r1
Algorithms: AES-256-GCM
Fallback: AES-256-GCM
Auth Digest: SHA256 (256)
HW Crypto: Intel RDRAND
Cert Depth (Client+Server)
Client Certificate Key Usage: Enforce Checked
Tunnel Network /24
no IPV6
Redirect: Force all IPv4 Thru tunnel: Checked
No Redirect IPv6 checked
Concurrent connections: blank
Compression: Refuse non stub
Inter Client Comm: Checked
Duplicate Conn: Checked
Dup Conn Limit: Blank
Client Dynamic IP: Checked
Topology: One IP address per client common subnet
Ping: Inactive: 0
Method: Keepalive
interval: 10
Timeout: 60
DNS Default Domain: Checked
DNS Server Enable: Checked
Block Outside DNS: Unchecked
Force DNS Update: Unchecked
NTP Server: Checked
Custom Options: push "route 1.2.3.4 255.255.255.0"
UDP Fast I/O: Unchecked
Exit Notify: Disabled
Send/Receive Buffer: Default
Gateway Creation ipv4 only

jimp

I'm using RA SSL/TLS but that shouldn't matter.

TLS Usage: Enc and Auth

Mine: Auth only

TLS KeyDir: Both

Mine: Default

DH: 4096

Mine: 2048

ECDH: secp384r1

Mine: Default

HW Crypto: Intel RDRAND

Set that to "No", you aren't going to gain anything from that one, especailly with DCO.

Redirect: Force all IPv4 Thru tunnel: Checked

I don't have this set but it's probably not going to change anything.

Inter Client Comm: Checked

Mine: Unchecked

Duplicate Conn: Checked

Mine: Unchecked (each client has a unique cert)

Client Dynamic IP: Checked

Mine: Unchecked

DNS Default Domain: Checked

Mine: Unchecked

DNS Server Enable: Checked

Mine: Unchecked

NTP Server: Checked

Mine: Unchecked

Custom Options: push "route 1.2.3.4 255.255.255.0"

Mine: Blank (but that one route alone should be fine)

A lot of those, like the pushed DNS options, shouldn't make a difference. I'd focus on trying to change one thing at a time to see if it helps and if it doesn't, change it back and try the next one. That way you can isolate the potential problem there.

I'd try changing TLS auth first to auth only, I'm not sure if anyone has tried TLS enc+auth with DCO yet.

Also you listed several options that should be hidden when you have DCO on (like inactive and UDP fast i/o), are those really showing in your GUI with DCO checked or did you transcribe those from somewhere else?

swixo

@jimp said in 22.05 - DCO and OpenVPN issue:

HW Crypto: Intel RDRAND

Set that to "No", you aren't going to gain anything from that one, especailly with DCO.

I'd try changing TLS auth first to auth only, I'm not sure if anyone has tried TLS enc+auth with DCO yet.

Also you listed several options that should be hidden when you have DCO on (like inactive and UDP fast i/o), are those really showing in your GUI with DCO checked or did you transcribe those from somewhere else?

My bad on that - I had flipped DCO off just to get the VPN going again and hadn't thought the UX would change the options.

I will test the changes you suggest and report.

swixo

@swixo Tried a bunch of these changes and made things worse.

Intel Hardware accel had no effect. But the Key Dir and Auth Only/Auth+Encry setting made a lot of difference. Had to export new profiles after every change to make sure clients were in sync.

Most of the time - I couldn't connect at all - or data never flowed, until turning DCO off - then it usually worked fine after that.