Project

General

Profile

Actions

Todo #11020

closed

Update OpenVPN to 2.5.0

Added by Matthew Ray almost 4 years ago. Updated over 3 years ago.

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

100%

Estimated time:
Plus Target Version:
Release Notes:

Description

Update OpenVPN to 2.5.0 and make necessary adjustments, including:
  • Add ability to create network interfaces for VLANs on OpenVPN TAP servers
  • Add GUI option for -block-ipv6

Files

Actions #1

Updated by Jim Pingle almost 4 years ago

  • Assignee set to Renato Botelho
  • Target version set to 2.5.0

We already plan on updating OpenVPN to 2.5.0, and it was added to FreeBSD ports over the weekend.

But those other bullet points are not related to updating to OpenVPN 2.5.0, they are separate feature requests. Neither of them are requirements.

Actions #2

Updated by Renato Botelho almost 4 years ago

  • Status changed from New to In Progress
  • Assignee changed from Renato Botelho to Jim Pingle

2.5.0 was cherry-picked to devel ports tree

Actions #3

Updated by Viktor Gurov almost 4 years ago

+ Add ability to create IPv6-only OpenVPN networks

from https://github.com/OpenVPN/openvpn/blob/release/2.5/Changes.rst

IPv6-only operation
It is now possible to have only IPv6 addresses inside the VPN tunnel, and IPv6-only address pools
(2.4 always required IPv4 config/pools and IPv6 was the "optional extra").

Actions #4

Updated by Jim Pingle almost 4 years ago

  • Status changed from In Progress to Feedback
Actions #5

Updated by Jim Pingle almost 4 years ago

  • Status changed from Feedback to In Progress
Actions #6

Updated by Jim Pingle almost 4 years ago

  • % Done changed from 0 to 30

I pushed a commit which removes the IPv4 tunnel network requirement from the GUI and backend code. I was able to make an IPv6 only server and connect with an IPv6 only client, pass traffic, etc. OpenVPN 2.5.0 on both ends, naturally.

Actions #7

Updated by Jim Pingle almost 4 years ago

  • % Done changed from 30 to 60

I pushed a commit to update the compression options to match changes in OpenVPN 2.5.0:

  • Add new "Allow Compression" option for OpenVPN 2.5.0. Defaults to asymmetric (Decompress incoming packets, do not compress outgoing packets) for a more secure and smooth transition to disabling compression entirely.
  • Rearrange compression options so that the options to disable (or not actively use) compression are first.
  • Disable compression for new instances, upgraded instances will use asymmetric mode.
  • Mark compression option as Deprecated (per the OpenVPN documentation)
Actions #8

Updated by Jim Pingle almost 4 years ago

  • Status changed from In Progress to Feedback
  • % Done changed from 60 to 100

The remaining items which need updated are all related to Data Ciphers (Formerly known as NCP) which have a separate issue: #10919

The main things that need checked here are:

  • That an IPv6 only server and client work
  • That the new compression options behave as expected for existing and new tunnels, and for both OpenVPN 2.4 and 2.5 clients
  • Testing OpenVPN 2.3 clients would be nice but isn't a hard requirement

Any remaining items mentioned (e.g. VLANs, blocking IPv6, etc) would be new features which need to be evaluated on additional feature requests and are not a part of this issue.

Actions #9

Updated by Niccolò Marchi almost 4 years ago

  • File Cattura.PNG added
Actions #10

Updated by Jim Pingle almost 4 years ago

  • File deleted (Cattura.PNG)
Actions #11

Updated by Niccolò Marchi almost 4 years ago

cipher in ovpn file is always empty

Actions #12

Updated by Marcos M almost 4 years ago

Niccolò Marchi wrote:

cipher in ovpn file is always empty

This is likely a misconfiguraiton and not a bug. If this was not happening previously with OpenVPN 2.4 and you are able to reproduce it, please post the relevant .conf file found in /var/etc/openvpn/ as well as the ovpn file being used (redact info as needed).

Actions #13

Updated by Jim Pingle almost 4 years ago

Not nearly enough information, either. Post on the forum to discuss the problem and provide a lot more information about your setup.

Actions #14

Updated by Marcos M over 3 years ago

Restoring an openvpn config from 2.4.5p1 into latest 2.5 does not retain some settings which may potentially break existing client configs.

In the 2.4.5p1 config backup, the OpenVPN config section has:

        <crypto>AES-128-GCM</crypto>
        <ncp-ciphers>AES-128-GCM</ncp-ciphers>

After a restore into 2.5, it now has the following:

        <data_ciphers_fallback>AES-128-CBC</data_ciphers_fallback>
        <data_ciphers>AES-256-GCM,AES-128-GCM,CHACHA20-POLY1305</data_ciphers>

Granted in this specific example, AES-128-GCM exists in both configs so it wouldn't break. However, if the config initially had something like AES-256-CBC instead, it would break.

Actions #15

Updated by Jim Pingle over 3 years ago

That is expected and will work fine. The options changed names and purposes in OpenVPN 2.5.0. There is no reason to have the same cipher in data_ciphers and as fallback on OpenVPN 2.5.0.

If you can find a real scenario that breaks, not just in theory, let me know.

Actions #16

Updated by Marcos M over 3 years ago

I have a mobile client using OpenVPN for Android with a config that contains:

data-ciphers AES-256-CBC
cipher AES-128-GCM

When connecting to the 2.5 instance, I get on the client:

AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)

To make it work, I have to either:
  1. Specify AES-256-CBC on "Fallback Data Encryption Algorithm", and/or
  2. Add AES-256-CBC on "Data Encryption Algorithms"

Having only one cipher specified in the first place is not ideal and it's not how I had it configured, but as far as I can tell, it does have the potential to break.

Actions #17

Updated by Kris Phillips over 3 years ago

IPv6 tunnel networks aren't supported by the UI, it would seem. Getting an error stating "The field 'Tunnel Network' must contain only valid ipv4 CIDR range(s) separated by commas."

Actions #18

Updated by Jim Pingle over 3 years ago

Marcos Mendoza wrote:

        <data_ciphers_fallback>AES-128-CBC</data_ciphers_fallback>
        <data_ciphers>AES-256-GCM,AES-128-GCM,CHACHA20-POLY1305</data_ciphers>

data-ciphers AES-256-CBC
cipher AES-128-GCM

When connecting to the 2.5 instance, I get on the client:

AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)

That's not surprising since the data-ciphers do not have any ciphers in common. The data_ciphers_fallback field is used if data cipher negotiation itself fails (i.e. a client doesn't support or has disabled cipher negotiation).

cipher is not the same as data-ciphers-fallback. when using cipher, OpenVPN automatically adds the value of cipher to the negotiation list. When using data-ciphers-fallback the list is taken as-is. If the OpenVPN 2.5 instance has data-ciphers-fallback it's used with older clients which don't support negotiation.

On upgrade to 2.5, the selected crypto cipher is added to the data ciphers list to approximate this, but if a user changes it after upgrade, they have made an invalid configuration. If the user had exported a configuration in the past it shouldn't end up as mismatched as your example.

If the client configuration uses data-ciphers and cipher (which is unusual, mixing new and deprecated options), the OpenVPN docs say it should still accept the value of cipher when negotiating, but if that isn't working it may be a bug in OpenVPN ( https://github.com/OpenVPN/openvpn/blob/master/doc/man-sections/cipher-negotiation.rst ) either way the fix is to use the correct data cipher list and not rely on fallback. It may also be that it works one way (e.g. when acting as server, not as client, or vice versa).

Having only one cipher specified in the first place is not ideal and it's not how I had it configured, but as far as I can tell, it does have the potential to break.

As far as I've seen and tested, it only breaks if someone does the wrong thing after upgrade or doesn't quite understand what the options are when configuring them. Which is more of a docs issue and not a code issue/bug. I haven't been able to replicate a problem here yet post-upgrade but I'll keep checking.

Kris Phillips wrote:

IPv6 tunnel networks aren't supported by the UI, it would seem. Getting an error stating "The field 'Tunnel Network' must contain only valid ipv4 CIDR range(s) separated by commas."

I can't reproduce this here. I have instances with IPv4 and IPv6 tunnel networks (one, the other, and both) and they all work fine. If you can reproduce it again, open a fresh issue and include screenshots of what you're filling in on each of the fields.

Actions #19

Updated by Marcos M over 3 years ago

Thanks for the detailed response Jim.

If the user had exported a configuration in the past it shouldn't end up as mismatched as your example.

This is where I'm seeing the potential problem. I exported the following from 2.4.5p1 and imported it into 2.5 and tried connecting with the Android client, which gives me the error mentioned previously. The full log of the error is as follows:

2021-01-11 10:15:20 official build 0.7.21 running on OnePlus ONEPLUS A6013 (sdm845), Android 10 (QKQ1.190716.003) API 29, ABI arm64-v8a, (OnePlus/OnePlus6T/OnePlus6T:10/QKQ1.190716.003/2010042216:user/release-keys)
[...]
2021-01-11 10:15:20   ciphername = 'AES-256-CBC'
2021-01-11 10:15:20   ncp_enabled = ENABLED
2021-01-11 10:15:20   ncp_ciphers = 'AES-256-CBC'
2021-01-11 10:15:20   authname = 'SHA256'
[...]
2021-01-11 10:15:20 OpenVPN 2.5-icsopenvpn [git:icsopenvpn/v0.7.20-0-g46ce6652] arm64-v8a [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Sep 24 2020
2021-01-11 10:15:20 library versions: OpenSSL 1.1.1h  22 Sep 2020, LZO 2.10
[...]
2021-01-11 10:15:22 Local Options String (VER=V4): 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,keydir 1,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-client'
2021-01-11 10:15:22 Expected Remote Options String (VER=V4): 'V4,dev-type tun,link-mtu 1569,tun-mtu 1500,proto UDPv4,keydir 0,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-server'
[...]
2021-01-11 10:15:22 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bit RSA, signature: RSA-SHA256
2021-01-11 10:15:22 [gw.home.arpa] Peer Connection Initiated with [AF_INET]x.x.x.x:1195
2021-01-11 10:15:23 MANAGEMENT: >STATE:1610381723,GET_CONFIG,,,,,,
2021-01-11 10:15:23 SENT CONTROL [gw.home.arpa]: 'PUSH_REQUEST' (status=1)
2021-01-11 10:15:23 AUTH: Received control message: AUTH_FAILED,Data channel cipher negotiation failed (no shared cipher)
2021-01-11 10:15:23 TCP/UDP: Closing socket
2021-01-11 10:15:23 SIGTERM[soft,auth-failure] received, process exiting
2021-01-11 10:15:23 MANAGEMENT: >STATE:1610381723,EXITING,auth-failure,,,,,
Actions #20

Updated by Jim Pingle over 3 years ago

Exported what from 2.4.5-p1? The client config? Or the pfSense configuration?

The client export package wouldn't have put in the combination of "data-ciphers" and "cipher" into a client configuration. It would either be data-ciphers and data-ciphers-fallback (OpenVPN 2.5 mode, default) or ncp-ciphers and cipher (Legacy mode).

Maybe that client did something unexpected when importing the configuration, hard to say.

What does the server log show for cipher negotiation?

There must be something else amiss in your environment. I setup one here on the server side to match yours:

            <ncp_enable>enabled</ncp_enable>
                        <data_ciphers>AES-256-GCM,AES-128-GCM,CHACHA20-POLY1305</data_ciphers>
                        <data_ciphers_fallback>AES-128-CBC</data_ciphers_fallback>

Which results in a configuration of this in the backend:

data-ciphers AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC
data-ciphers-fallback AES-128-CBC

So you can see that our code already adds the fallback cipher to the main list.

If I force a client to match yours, it does fail, and the server logs this:

Jan 11 11:56:54     openvpn     28404     clara.dw.example.com/198.51.100.6:2361 PUSH: No common cipher between server and client. Server data-ciphers: 'AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:AES-128-CBC', client supported ciphers 'AES-256-CBC' 

Which is true. But it's a failure of the client. The client didn't tell the server it could accept AES-128-CBC. There is nothing the server can do about that.

From all appearances this is a misconfigured client, and I wouldn't expect it to have worked on 2.4.5-p1 except perhaps by accident.

I'm going to edit down the log above so it doesn't dominate the comments.

Also note in the log that the client doesn't even see AES-128-CBC.

Actions #21

Updated by Marcos M over 3 years ago

Exported what from 2.4.5-p1? The client config? Or the pfSense configuration?

Exported the server config from 2.4.5p1 and imported into 2.5.

To narrow down any potential issues with a custom client config, I have now exported the client configuration file on 2.4.5p1 and imported that file on the Android client. See attached. So here are the steps I took:
  1. Set AES-256-CBC on 2.4.5p1 (<crypto>AES-256-CBC</crypto> and <ncp-ciphers>AES-256-CBC</ncp-ciphers>). See openvpn-config-20210111095057.xml.
  2. Exported inline client config. See gw-UDP4-1194-internal-config.ovpn.
  3. Restore OpenVPN config on 2.5.
  4. Re-select correct certs and save/apply.
  5. Import client inline client config into OpenVPN for Anroid client.
  6. Connect fails with log posted earlier.

Note: There is an option on the client application called "OpenVPN 3 Core" that when toggled on, it successfully connects to the 2.5 server without any changes. Here's the log for that:

2021-01-11 11:42:57 official build 0.7.21 running on OnePlus ONEPLUS A6013 (sdm845), Android 10 (QKQ1.190716.003) API 29, ABI arm64-v8a, (OnePlus/OnePlus6T/OnePlus6T:10/QKQ1.190716.003/2010042216:user/release-keys)
2021-01-11 11:42:57 Building configuration…
2021-01-11 11:42:58 OpenVPN core 3.6_git:master(icsopenvpn/v0.7.18-0-g9c577420) android arm64 64-bit
2021-01-11 11:42:58 Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
2021-01-11 11:42:58 OpenVPN core 3.6_git:master(icsopenvpn/v0.7.18-0-g9c577420) android arm64 64-bit
2021-01-11 11:42:58 Frame=512/2048/512 mssfix-ctrl=1250
2021-01-11 11:42:58 UNUSED OPTIONS
1 [verb] [4]
2 [connect-retry] [2] [300]
3 [resolv-retry] [60]
13 [data-ciphers] [AES-256-CBC]
15 [persist-tun]
16 [preresolve]
17 [resolv-retry] [infinite]
18 [lport] [0]
19 [data-ciphers-fallback] [AES-256-CBC]
2021-01-11 11:42:58 Network Status: CONNECTED LTE to MOBILE fast.t-mobile.com
2021-01-11 11:42:58 Debug state info: CONNECTED LTE to MOBILE fast.t-mobile.com, pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 
2021-01-11 11:42:58 Debug state info: CONNECTED LTE to MOBILE fast.t-mobile.com, pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 
2021-01-11 11:42:58 Contacting x.x.x.x:1195 via UDP
2021-01-11 11:42:58 Connecting to [gw.home.arpa]:1195 (x.x.x.x) via UDPv4
2021-01-11 11:42:59 Tunnel Options:V4,dev-type tun,link-mtu 1553,tun-mtu 1500,proto UDPv4,keydir 1,cipher BF-CBC,auth SHA256,keysize 128,tls-auth,key-method 2,tls-client
2021-01-11 11:42:59 Creds: UsernameEmpty/PasswordEmpty
2021-01-11 11:42:59 Peer Info:
IV_VER=3.6_git:master
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=14
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305:BF-CBC
IV_AUTO_SESS=1
IV_GUI_VER=de.blinkt.openvpn 0.7.21
IV_SSO=openurl,crtext
IV_BS64DL=1
2021-01-11 11:42:59 VERIFY OK: depth=0, /CN=gw.home.arpa
2021-01-11 11:42:59 SSL Handshake: peer certificate: CN=gw.home.arpa, 2048 bit RSA, cipher: TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
2021-01-11 11:42:59 Session is ACTIVE
2021-01-11 11:42:59 Sending PUSH_REQUEST to server...
2021-01-11 11:42:59 OPTIONS:
0 [route] [10.0.5.0] [255.255.255.0]
1 [dhcp-option] [DOMAIN] [home.arpa]
2 [dhcp-option] [DNS] [172.20.0.1]
3 [route] [172.20.5.0] [255.255.255.0]
4 [client-nat] [dnat] [172.20.5.0] [255.255.255.0] [10.0.5.0/24]
5 [route-gateway] [172.20.0.1]
6 [topology] [subnet]
7 [ping] [10]
8 [ping-restart] [60]
9 [ifconfig] [172.20.0.2] [255.255.255.0]
10 [peer-id] [0]
11 [cipher] [AES-256-GCM]
2021-01-11 11:42:59 PROTOCOL OPTIONS:
  cipher: AES-256-GCM
  digest: NONE
  key-derivation: OpenVPN PRF
  compress: NONE
  peer ID: 0
  control channel: tls-auth enabled
2021-01-11 11:42:59 We should call this sessiongw.home.arpa
2021-01-11 11:42:59 Opening tun interface:
2021-01-11 11:42:59 Local IPv4: 172.20.0.2/24 IPv6: (not set) MTU: 1500
2021-01-11 11:42:59 DNS Server: 172.20.0.1, Domain: home.arpa
2021-01-11 11:42:59 Routes: 10.0.5.0/24, 172.20.5.0/24 
2021-01-11 11:42:59 Routes excluded:  
2021-01-11 11:42:59 VpnService routes installed: 10.0.5.0/24, 172.20.5.0/24 
2021-01-11 11:42:59 Disallowed VPN apps: 
2021-01-11 11:42:59 TunPersist: saving tun context:
Session Name: gw.home.arpa
Layer: OSI_LAYER_3
Remote Address: x.x.x.x
Tunnel Addresses:
  172.20.0.2/24 -> 172.20.0.1
Reroute Gateway: IPv4=0 IPv6=0 flags=[ IPv4 ]
Block IPv6: no
Add Routes:
  10.0.5.0/24
  172.20.5.0/24
Exclude Routes:
DNS Servers:
  172.20.0.1
Search Domains:
  home.arpa
2021-01-11 11:42:59 Connected via tun
2021-01-11 11:42:59 Debug state info: CONNECTED LTE to MOBILE fast.t-mobile.com, pause: userPause, shouldbeconnected: true, network: SHOULDBECONNECTED 

EDIT:
So the issue ended up being that I was restoring the OpenVPN configuration on pfSense by only selecting the OpenVPN restore section which does not run the upgrade code. Restoring the full config file makes the proper adjustments on 2.5.

Actions #22

Updated by Jim Pingle over 3 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF