OpenVPN Ciphers will not stick in 2.5
So I upgraded my production home firwewall to 2.5 dev yesterday. None of the OpenVPN clients work after the upgrade despite connecting (i'll log a separate bug for that if I can work it out) but i'm attempting to create a new client to see whether that works.
I select the desired ciphers in the "Allowed Data Encryption Algorithms" (AES-256-GCM and AES-256-CBC). Hit save. Go back into the OpenVPN client config, and the ciphers have changed. It seems to like AES-256-GCM, AES-128-GCM and CHACHA20-POLY1305.
#1 Updated by Jim Pingle 2 months ago
- Category changed from VPN (Multiple Types) to OpenVPN
- Status changed from New to Rejected
I can't reproduce this as stated. I was able to edit an existing client as well as create a new client, both times it respected the exact list I chose. I repeated the test with server entries and it worked as well.
#2 Updated by John Griffin 2 months ago
Here is video of it occurring. It seems a bit random, sometimes it works, sometimes you end up with a completely different set of ciphers.
Not sure of the protocol around here, as it's already been rejected should i submit another one? Will anyone ever read this :-)
#3 Updated by Jim Pingle 2 months ago
Those videos are private and cannot be viewed.
I tried again and can't replicate the problem here. Maybe write out a more complete procedure for replicating the problem, starting with a new/fresh tunnel. Also try different browsers, and make sure any script/ad blocking is disabled for the firewall URL.
#4 Updated by John Griffin 2 months ago
Sorry about the video's, they should be viewable now.
You are correct, I cannot replicate the issue in Firefox. I disabled every extension in chrome, then:
On a new blank clean build 2.5 instance I
a) created new CA
b) navigate to OpenVPN - Clients
d) Fill in minimal information (remote server, username, password)
e) deselect AEs-128-GCM and CHACHA
f) added AES-256-CBC
g) hit save
go back in and the values will have changed
In the following video you can see that 2 out of 3 times the values were different when I went back in after saving
#5 Updated by Jim Pingle 2 months ago
- Status changed from Rejected to New
- Assignee set to Steve Beaver
- Priority changed from Normal to Very High
- Target version set to 2.5.0
OK, I can reproduce it that way, but only in Chrome. Watching the network panel as it makes the POST, for whatever reason Chrome is not sending the
data_ciphers list in the POST. It happens to both clients and servers.