Bug #10919
closed
Improve handling of OpenVPN data cipher negotiation options
100%
Description
TL;DR: the cipher that is selected as --cipher in the openvpn config, should always be added to ncp-ciphers
In OpenVPN we are trying to simplify the data channel cipher situation and also trying to remove the default of BF-CBC that we currently have in --cipher and move to a sane default of 'AES-256-GCM:AES-128-GCM'. The long term plan is to completely drop --cipher and rely only on --data-ciphers (newer preferred alias to --ncp-ciphers). More details here: https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst
Most people do not mess with ncp-ciphers or if they do have ncp enabled on both server and client side. But it seems to be very easy to generate a configuration with pfSense that violates that assumption. (See also here https://github.com/schwabe/ics-openvpn/issues/1232). The best way to avoid all this troubles is from pfsense side. Also allowing to not include AES-256-GCM and AES-128-GCM into the ncp-ciphers is problematic (see also the document).
So what pfSense should do to avoid compatibility problem with its generated configs:
- Mark disabling NCP deprecated.
- always append the cipher selected to ncp-ciphers to allow compatiblity with OpenVPN version beyond 2.5
- Warn that if AES-256-GCM and AES-128-GCM are not included in ncp-ciphers, this can cause problem if either server or client is 2.5 and the other peer is 2.4
When the server (pfSense) is OpenVPN 2.5+ only, selecting the --cipher can be completely dropped.
Updated by Jim Pingle about 4 years ago
- Subject changed from pfsense's handling of OpenVPN ncp options is problematic to Improve handling of OpenVPN ncp options
- Category set to OpenVPN
- Target version set to 2.5.0
Updated by Jim Pingle about 4 years ago
- Status changed from New to In Progress
Just a note to myself before I start on this:
The OpenVPN 2.5.0 changes doc and some info on the links above do state that the value of --cipher is added to both --data-ciphers and --data-ciphers-fallback but the man page also mentions that --cipher is deprecated. So despite the temptation of relying on --cipher to handle part of this, we should do the right thing and set data-ciphers and data-ciphers-fallback appropriately.
This is the plan (so far, may change):
- Rename "NCP Algorithms" to "Data Encryption Algorithms" to reflect the change in OpenVPN (frontend and backend, e.g. "ncp-ciphers" changes to "data_ciphers")
- Change "Encryption Algorithm" to "Fallback Data Encryption Algorithm" and move it below "Data Encryption Algorithms"
- On upgrade, take the old value of 'crypto' (FKA "Encryption Algorithm") and append it to the cipher list, then rename to 'data_ciphers_fallback' and change backend code to match.
- Mark "Enable NCP" as deprecated and default it to enabled (+ change on upgrade to default enabled)
- Change "Data Encryption Algorithms" default list to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
- Add warning if the "Data Encryption Algorithms" does not include one of the above ciphers, but maybe not make it a fatal error.
Updated by
Updated by Jim Pingle about 4 years ago
- Subject changed from Improve handling of OpenVPN ncp options to Improve handling of OpenVPN data cipher negotiation options
- Status changed from In Progress to Feedback
- % Done changed from 0 to 70
I pushed a commit which implements everything above except for the warning message. It'll be set to feedback by the commit but that's OK since it will be good to test the parts that were pushed in the meantime.
Updated by Jim Pingle about 4 years ago
- % Done changed from 70 to 100
Applied in changeset 189edaf33bb2b21761d9ace0b3fd0119955f8726.
Updated by S Premeau about 4 years ago
This change set does not appear to be writing cipher or data-ciphers to the openvpn configuration file.
Here's my (redacted) openvpn-client configuration block:
<openvpn-client>
<auth_user></auth_user>
<auth_pass></auth_pass>
<proxy_user></proxy_user>
<proxy_passwd></proxy_passwd>
<vpnid>1</vpnid>
<protocol>UDP4</protocol>
<dev_mode>tun</dev_mode>
<interface>wan</interface>
<ipaddr></ipaddr>
<local_port></local_port>
<server_addr>REDACTED</server_addr>
<server_port>1194</server_port>
<proxy_addr></proxy_addr>
<proxy_port></proxy_port>
<proxy_authtype>none</proxy_authtype>
<description></description>
<mode>p2p_shared_key</mode>
<topology>subnet</topology>
<custom_options></custom_options>
<shared_key>REDACTED</shared_key>
<data_ciphers_fallback>AES-256-CBC</data_ciphers_fallback>
<digest>SHA256</digest>
<engine>none</engine>
<tunnel_network>172.30.100.100/30</tunnel_network>
<tunnel_networkv6></tunnel_networkv6>
<remote_network></remote_network>
<remote_networkv6></remote_networkv6>
<use_shaper></use_shaper>
<allow_compression>no</allow_compression>
<compression>none</compression>
<auth-retry-none></auth-retry-none>
<passtos>yes</passtos>
<udp_fast_io></udp_fast_io>
<exit_notify>none</exit_notify>
<sndrcvbuf></sndrcvbuf>
<route_no_pull></route_no_pull>
<route_no_exec></route_no_exec>
<verbosity_level>1</verbosity_level>
<create_gw>v4only</create_gw>
<ncp_enable>disabled</ncp_enable>
<ping_method>keepalive</ping_method>
<keepalive_interval>10</keepalive_interval>
<keepalive_timeout>60</keepalive_timeout>
<ping_seconds>10</ping_seconds>
<ping_action>ping_restart</ping_action>
<ping_action_seconds>60</ping_action_seconds>
<inactive_seconds>0</inactive_seconds>
</openvpn-client>
/var/etc/openvpn/client1/openvpn.conf contains the following:
dev ovpnc1
verb 1
dev-type tun
dev-node /dev/tun1
writepid /var/run/openvpn_client1.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp4
auth SHA256
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local REDACTED
lport 0
management /var/etc/openvpn/client1/sock unix
remote REDACTED 1194 udp4
ifconfig 172.30.100.102 172.30.100.101
secret /var/etc/openvpn/client1/secret
allow-compression no
compress
passtos
resolv-retry infinite
Updated by S Premeau about 4 years ago
The issue does also occur if ncp negotiation is enabled. I could not get any ciphers into the openvpn config file with any cipher config.
Updated by Jim Pingle about 4 years ago
- Status changed from Feedback to In Progress
Updated by Jim Pingle about 4 years ago
- Status changed from In Progress to Feedback
Applied in changeset 924eeefb45222ee5bbf813b8d3d0b3ab704fcede.
Updated by Anonymous about 4 years ago
OpenVPN client edit is not saving / loading the Fallback cypher setting.
Looking through /usr/local/www/vpn_openvpn_client.php the section for the fallback setting is still indexed with the old 'crypto' array index and not the new 'data_ciphers_fallback' index, as updated in revision 189edaf3.
863 $section->addInput(new Form_Select(
864 'data_ciphers_fallback',
865 'Fallback Data Encryption Algorithm',
866 $pconfig['crypto'],
867 openvpn_get_cipherlist()
Updated by S Premeau about 4 years ago
The changes through comment 12 appear to fix my issue.
Updated by Max Leighton almost 4 years ago
The OpenVPN Server Wizard doesn't seem to be updated to reflect these changes. When running through the Wizard the first time, you have the option to set an Encryption Algorithm, but not the Fallback Encryption Algorithm or Data Encryption Algorithms.
As a result, if you create a new server using the Wizard and then export a client config, it will have no value set for data-ciphers-fallback and no data ciphers:
dev tun
persist-tun
persist-key
data-ciphers-fallback
auth SHA256
tls-client
client
resolv-retry infinite
remote 100.64.0.6 1194 udp4
verify-x509-name "OpenVPNCert" name
auth-user-pass
remote-cert-tls server
This gives the error:
Options error: Unrecognized option or missing or extra parameter(s) in TESTpfSense01-UDP4-1194-test2-config.ovpn:4: data-ciphers-fallback (2.5.0)
I can go back into the newly created server and resave it without making any other changes, and then export the config again. It will then have the correct values:
dev tun
persist-tun
persist-key
data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC
data-ciphers-fallback AES-128-CBC
auth SHA256
tls-client
client
resolv-retry infinite
remote 100.64.0.6 1194 udp4
verify-x509-name "OpenVPNCert" name
auth-user-pass
remote-cert-tls server
From there I can connect without issue.
Updated by Jim Pingle almost 4 years ago
- Status changed from Feedback to In Progress
Updated by Jim Pingle almost 4 years ago
- Status changed from In Progress to Feedback
- % Done changed from 80 to 100
Applied in changeset 002a038f4e9d4ce4cb4f8e5dec5036eb822017a6.
Updated by Max Leighton almost 4 years ago
- Status changed from Feedback to Resolved
Tested again on today's snapshot, and all works as expected now. I'll set the ticket to resolved.