2.5-RC OpenVPN cipher negotiation not working as expected

q54e3w

I hesitate to call this a bug as I'm aware there have been a lot of changes with regards OpenVPN cipher negotiation, and its possible it could be the server configuration I am connecting to causing the result. Its also (very) likely my understanding if how this should work is wrong too.

My expected results
Ciphers selected in the 'Allowed Data Encryption Algorithms' will be tried in a top down order, the highest priority that matches with the server will be selected.

From the OpenVPN 2.5 manual on Data channel cipher negotiation specifically

When both client and server are at least running OpenVPN 2.5, that the order of the ciphers of the server's --data-ciphers is used to pick the the data cipher. That means that the first cipher in that list that is also in the client's --data-ciphers list is chosen. If no common cipher is found the client is rejected with a AUTH_FAILED message (as seen in client log):

AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)
OpenVPN 2.5 will only allow the ciphers specified in --data-ciphers. To ensure backwards compatibility also if a cipher is specified using the --cipher option it is automatically added to this list. If both options are unset the default is AES-256-GCM:AES-128-GCM.

Whats happening
Multiple options are ignored, or lower priority CHACHA20 is being selected over higher priority GCM ciphers.

I have three config files and logs

data-ciphers AES-256-GCM:AES-256-CBC
This negotiates AES-256-GCM correctly

data-ciphers AES-128-GCM:AES-256-CBC
This fails to select AES-128-GCM and falls back to AES-256-CBC

data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-256-CBC
This prioritizes CHACHA20-POLY1305 even thought the server supports both GCM ciphers.

Would appreciate any help resolving my understanding, or identifying if this is a bug, either in pfSense or with the VPN server configuration.

jimp

Are the configuration examples you posted from the client, the server, or both?

The order of preference goes by what the server wants, not by what the client wants, so seeing the exact options from the server is critical in knowing what will happen.

From your quote (emphasis mine)

[...] the order of the ciphers of the server's --data-ciphers is used to pick the the data cipher.

So it doesn't matter how you order things on the client, if the server has CHACHA20-POLY1305 as its preferred cipher and the client lists it as supported (in any order) then the server will pick that one.

From the sound of it the server may only have something like data-ciphers CHACHA20-POLY1305:AES-256-GCM and doesn't actually include AES-128-GCM. Perhaps it has 192 and not 128, for example. But you need the server config to know for sure.

q54e3w

@jimp thats the nuance I was missing, thank you.

The servers cipher order is

CHACHA20-POLY1305 AES-256-GCM AES-256-CBC AES-192-GCM AES-192-CBC AES-128-GCM AES-128-CBC

Configuring pfSense with only AES-128-GCM added to the allowed data encryption list, and having AES-256-CBC as the fallback data encryption list results in a client side of data-ciphers AES-128-GCM:AES-256-CBC.
Given these two configurations its correct that the servers higher preference for AES-256-CBC is selected over the GCM cipher.

My mistake was thinking the client had more control, and the fall back option was a last hope fallback, not evaluated equally and as part of the allowed cipher list.

thanks for clearing this up