Project

General

Profile

Actions

Bug #10919

closed

Improve handling of OpenVPN data cipher negotiation options

Added by Arne Schwabe over 3 years ago. Updated about 3 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
OpenVPN
Target version:
Start date:
09/20/2020
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

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.

Actions #1

Updated by Jim Pingle over 3 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
Actions #2

Updated by Anonymous over 3 years ago

  • Assignee set to Jim Pingle
Actions #3

Updated by Jim Pingle over 3 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.
Actions #4

Updated by Arne Schwabe over 3 years ago

Sounds like a good plan!

Actions #5

Updated by Jim Pingle over 3 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.

Actions #6

Updated by Jim Pingle over 3 years ago

  • % Done changed from 70 to 100
Actions #7

Updated by S Premeau over 3 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

Actions #8

Updated by S Premeau over 3 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.

Actions #9

Updated by Jim Pingle over 3 years ago

  • Status changed from Feedback to In Progress
Actions #10

Updated by Jim Pingle over 3 years ago

  • Status changed from In Progress to Feedback
Actions #11

Updated by Anonymous over 3 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()
Actions #12

Updated by Jim Pingle over 3 years ago

Nice catch, I've pushed a fix. Thanks!

Actions #13

Updated by S Premeau over 3 years ago

The changes through comment 12 appear to fix my issue.

Actions #14

Updated by Max Leighton over 3 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.

Actions #15

Updated by Jim Pingle about 3 years ago

  • Status changed from Feedback to In Progress
Actions #16

Updated by Jim Pingle about 3 years ago

  • % Done changed from 100 to 80
Actions #17

Updated by Jim Pingle about 3 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 80 to 100
Actions #18

Updated by Max Leighton about 3 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.

Actions

Also available in: Atom PDF