Description of problem: After upgrade to F34, VPN fails to start. All that's in /var/log/messages is this: Jun 7 09:58:31 suzdal NetworkManager[1299]: <info> [1623077911.5676] vpn-connection[0x55b1e3338100,be8c5357-394c-4669-a165-c15ddd937484,"ovpn-phx2-udp",0]: VPN connection: (ConnectInteractive) reply received Jun 7 09:58:31 suzdal NetworkManager[3229]: Options error: Unrecognized option or missing or extra parameter(s) in [CMD-LINE]:1: tls-remote (2.5.2) Jun 7 09:58:31 suzdal NetworkManager[3229]: Use --help for more information. Version-Release number of selected component (if applicable): NetworkManager-openvpn-1.8.14-1.fc34.x86_64 How reproducible: Synchronous Steps to Reproduce: 1. Install F33 2. Add VPN with OpenVPN 3. Verify VPN works 4. Upgrade to F34 5. Verify fails Actual results: No VPN anymore Expected results: VPN working Additional info:
what is the configuration you are using? nmcli connection show "$PROFILE_NAME" Please sanitize before posting, but not in a way that distorts the meaning. Thanks.
connection.id: ovpn-phx2-udp connection.uuid: be8c5357-394c-4669-a165-c15ddd937484 connection.stable-id: -- connection.type: vpn connection.interface-name: -- connection.autoconnect: no connection.autoconnect-priority: 0 connection.autoconnect-retries: -1 (default) connection.multi-connect: 0 (default) connection.auth-retries: -1 connection.timestamp: 1623077624 connection.read-only: no connection.permissions: -- connection.zone: -- connection.master: -- connection.slave-type: -- connection.autoconnect-slaves: -1 (default) connection.secondaries: -- connection.gateway-ping-timeout: 0 connection.metered: unknown connection.lldp: default connection.mdns: -1 (default) connection.llmnr: -1 (default) connection.wait-device-timeout: -1 ipv4.method: auto ipv4.dns: -- ipv4.dns-search: -- ipv4.dns-options: -- ipv4.dns-priority: 0 ipv4.addresses: -- ipv4.gateway: -- ipv4.routes: -- ipv4.route-metric: -1 ipv4.route-table: 0 (unspec) ipv4.routing-rules: -- ipv4.ignore-auto-routes: no ipv4.ignore-auto-dns: no ipv4.dhcp-client-id: -- ipv4.dhcp-iaid: -- ipv4.dhcp-timeout: 0 (default) ipv4.dhcp-send-hostname: yes ipv4.dhcp-hostname: -- ipv4.dhcp-fqdn: -- ipv4.dhcp-hostname-flags: 0x0 (none) ipv4.never-default: yes ipv4.may-fail: yes ipv4.dad-timeout: -1 (default) ipv4.dhcp-vendor-class-identifier: -- ipv4.dhcp-reject-servers: -- ipv6.method: auto ipv6.dns: -- ipv6.dns-search: -- ipv6.dns-options: -- ipv6.dns-priority: 0 ipv6.addresses: -- ipv6.gateway: -- ipv6.routes: -- ipv6.route-metric: -1 ipv6.route-table: 0 (unspec) ipv6.routing-rules: -- ipv6.ignore-auto-routes: no ipv6.ignore-auto-dns: no ipv6.never-default: yes ipv6.may-fail: yes ipv6.ip6-privacy: -1 (unknown) ipv6.addr-gen-mode: stable-privacy ipv6.ra-timeout: 0 (default) ipv6.dhcp-duid: -- ipv6.dhcp-iaid: -- ipv6.dhcp-timeout: 0 (default) ipv6.dhcp-send-hostname: yes ipv6.dhcp-hostname: -- ipv6.dhcp-hostname-flags: 0x0 (none) ipv6.token: -- vpn.service-type: org.freedesktop.NetworkManager.openvpn vpn.user-name: -- vpn.data: ca = /etc/pki/ca-trust/source/anchors/RH-IT-Root-CA.crt, cipher = AES-256-CBC, connection-type = password, dev = redhat0, dev-type = tun, password-flags = 2, port = 443, remote = ovpn-phx2.redhat.com, tls-remote = ovpn.redhat.com, tunnel-mtu = 1360, username = zaitcev vpn.secrets: <hidden> vpn.persistent: no vpn.timeout: 0 proxy.method: none proxy.browser-only: no proxy.pac-url: -- proxy.pac-script: -- I see, so this is where it's hiding. Should I edit vpn.data and kill that tls-remote setting?
Okay, I had folks help me out in the chat. The right solution is to use verify-x509-name=name:ovpn.redhat.com In GNOME, it is called "Verify name exactly".
yes, this is expected. NetworkManager-openvpn also warns about it: nm-openvpn[2518465] <warn> the tls-remote option is deprecated and removed from OpenVPN 2.4. Update your connection to use verify-x509-name In general, the NetworkManager openvpn plugin tries to work around such API changes, but in this case it was intentionally not done because there is no *exact* replacement for tls-remote and it seemed wrong to guess what the user might have meant. So the user is required to fix their configuration. After all, that is what openvpn projects expects users to do by removing the configuration option. I personally find openvpn's approach of breaking previously working configurations questionable. If somebody else provided you this configuration (e.g. from RHEL CSB), consider notifying them about this problem.
> replacement for tls-remote and it seemed wrong to guess what the user might have meant. So the user is required to fix their configuration. Ah, wrong. NetworkManager's plugin actually tries to map `tls-remote` to `verify-x509-name $REMOTE name` automatically (and also logging a warning). https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/commit/f7421ef277222bd640c432afefc21ef5a98477bc But the version detection was broken since 2.5.0. Fix at https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/merge_requests/37