Todo #11020
closed
Update OpenVPN to 2.5.0
Added by Matthew Ray over 3 years ago. Updated over 3 years ago.
100%
Description
- Add ability to create network interfaces for VLANs on OpenVPN TAP servers
- Add GUI option for -block-ipv6
Files
| openvpn-config-20210111095057.xml (2.44 KB) openvpn-config-20210111095057.xml | Marcos M, 01/11/2021 09:26 AM | ||
| gw-UDP4-1194-internal-config.ovpn (605 Bytes) gw-UDP4-1194-internal-config.ovpn | Marcos M, 01/11/2021 11:23 AM |
Updated by Jim Pingle over 3 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.
Updated by Renato Botelho over 3 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
Updated by Viktor Gurov over 3 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").
Updated by Jim Pingle over 3 years ago
- Status changed from In Progress to Feedback
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to In Progress
Updated by Jim Pingle over 3 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.
Updated by Jim Pingle over 3 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)
Updated by Jim Pingle over 3 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.
Updated by
Updated by Marcos M over 3 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).
Updated by Jim Pingle over 3 years ago
Not nearly enough information, either. Post on the forum to discuss the problem and provide a lot more information about your setup.
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.
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.
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:
- Specify AES-256-CBC on "Fallback Data Encryption Algorithm", and/or
- 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.
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."
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.
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,,,,,
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.
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:- 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.
- Exported inline client config. See gw-UDP4-1194-internal-config.ovpn.
- Restore OpenVPN config on 2.5.
- Re-select correct certs and save/apply.
- Import client inline client config into OpenVPN for Anroid client.
- 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.
Updated by Jim Pingle over 3 years ago
- Status changed from Feedback to Resolved