'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512'

[IPTRACE]

Hello!

Server log indicates the following warning.

peer info: IV_GUI_VER=net.openvpn.connect.ios_1.0.7-199
peer info: IV_VER=3.0.11
peer info: IV_PLAT=ios
peer info: IV_NCP=2
peer info: IV_TCPNL=1
peer info: IV_PROTO=2
peer info: IV_LZ4=1
WARNING: 'auth' is used inconsistently, local='auth [null-digest]', remote='auth SHA512'

Client log shows that sets properly auth as SHA512 value.
All works as expected.

Server config:

AES-256-GCM
auth SHA512

Client config:

AES-256-GCM
auth SHA512

[Gert Döring]

I assume this is due to cipher negotiation selecting AES-256-GCM and the built-into-that authentication, which shows up as "[null-digest]" - and of course, since negotiated differently from what is in the config, this shows up as a warning...

You'll see the same thing when leaving off "auth" on either side - it will use AES-256-GCM anyway (negotiated) but then complain about config-mismatch...

@syzzer: do we know that cipher and auth have been NCP'ed when comparing OCC values? In that case we could just ignore "auth" and "cipher".

[IPTRACE]

Ok. Warning occurrs only with IOS (client) not for Wiindows client with the same configuration.

[Steffan Karger]

Hm, this seems to be an implementation difference between the 2.x and 3.x code base (the iOS app uses the 3.x codebase). The 2.x codebase sets auth to 'none' when AEAD ciphers are used, because the auth is already provided by the cipher. 3.x apparently leaves the (unused) auth in its settings. I'd argue that the 2.x codebase does it right (auth isn't used here), but then again, I wrote that code ;)

As for the tag length, OpenVPN uses 128-bit GCM tags.

[Gert Döring]

Not challenging the correctness of the code if both sides are configured for AES-256-GCM, but we still produce a warning if ciphers are negotiated and pushed (and the original config is different but effectively ignored)... getting rid of those in the 2.x code base would be a good thing.

[Steffan Karger]

Yes, I agree that it would we good to remove some of the unnecessary warnings. This one is slightly tricky though, because it probably means rewriting the option string checking code :(

[mmokrejs]

Hi,

any chances this false alarm will be silenced? It complicates debugging of why openvpn connection is not established (if one just cannot trust the messages openvpn produces). Thank you. Am on dd-wrt r41786 with openvpn-2.4.8.

[Gert Döring]

OpenVPN Inc does not want to see or handle bugs against the commercial OpenVPN Connect products in the community bugtracker. So please report to ​https://support.openvpn.net/