Bug 396530 - [RFE][OpenVPN] Use nmcli importer
Summary: [RFE][OpenVPN] Use nmcli importer
Status: ASSIGNED
Alias: None
Product: plasma-nm
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: Jan Grulich
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-15 11:11 UTC by Martin Schulze
Modified: 2022-11-10 00:14 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Schulze 2018-07-15 11:11:37 UTC
When importing an OpenVPN configuration file from the UI with TCP enabled, the resulting configuration differs from the one that is loaded via nmcli.

Obviously, each project has its own parser, this is rather confusing.
Why isn't the cli parser used as a backend for the GUI import as well?
Comment 1 Dennis Schridde 2018-12-28 13:50:34 UTC
(In reply to Martin Schulze from comment #0)
> When importing an OpenVPN configuration file from the UI with TCP enabled,
> the resulting configuration differs from the one that is loaded via nmcli.
> 
> Obviously, each project has its own parser, this is rather confusing.
> Why isn't the cli parser used as a backend for the GUI import as well?

According to the NetworkManager OpenVPN developers, the import functionality is available as a shared library: https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues/20#note_395161  i.e. It would not even be necessary to shell out to the `nmcli` commandline tool.
Comment 2 fire f. 2019-08-09 12:10:43 UTC
could someone please point out the filename or link to that shared library which plasma-nm could but does not use? Thanks!
Comment 3 Dennis Schridde 2019-08-15 05:33:00 UTC
(In reply to fire f. from comment #2)
> could someone please point out the filename or link to that shared library
> which plasma-nm could but does not use? Thanks!

Please ask at https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/issues/20, I assume they are the best source for this information.
Comment 4 Matthew Woehlke 2019-12-26 17:35:34 UTC
Is anyone working on this? Right now the UX is that plasma+nm+openvpn is broken due to this.
Comment 5 Stefan Schwarz 2020-03-09 13:50:33 UTC
(In reply to Martin Schulze from comment #0)
> When importing an OpenVPN configuration file from the UI with TCP enabled,
> the resulting configuration differs from the one that is loaded via nmcli.
> 
> Obviously, each project has its own parser, this is rather confusing.
> Why isn't the cli parser used as a backend for the GUI import as well?

I have the same problem with UDP configuration files.
Most of the config is ignored by the GUI inport, since the problems have not been fixed for more than a year i'm switching to gnome, slower but at least something simple like an config file import is working...
Comment 6 mcmarius 2020-06-14 12:46:43 UTC
i have the same problem, i hope someone will fix this
Comment 7 tnemeth 2020-07-09 20:05:26 UTC
I've seen some BR about a Plasma-nm VPN GUI importer. I couldn't find it opening connections from the system tray. I had to resort to nmcli connection importer which although successful, failed to import a "working" configuration.

FYI I have a script that does :

...
  10   │ OPENVPN="openvpn --config $CFGDIR/$CONFIG --auth-user-pass $CFGDIR/$CREDS"
...
  19   │ vpn_start()
  20   │ {
  21   │         $OPENVPN > /tmp/vpn.log 2>&1 &
  22   │         TAP=""
  23   │         while [ -z "$TAP" ] ; do
  24   │                 TAP=$(ip l | grep tap0)
  25   │                 sleep 1
  26   │         done
  27   │         dhclient tap0
  28   │         ip route del default via 192.168.0.254 dev tap0
  29   │ }

This script works perfectly and my connection is correctly set up. It would be nice to have an openvpn _exporter_ in order to see which mismatch happened.
Comment 8 ratijas 2020-07-10 11:17:47 UTC
Similar compatibility issue when importing OpenVPN with relatively new tls-crypt option. Discussed at https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/54.

Now that I see this issue with very precise title exists, I don't think it worth opening new one which would be rather a duplicate.

Original text from the link above:

=== ratijas:

Import *.ovpn ignores <tls-crypt>

Using:

    NetworkManager as in Connections — System Settings Module.
    OpenVPN plugin for NetworkManager as in this repository.

Problem

During import of *.ovpn profile via "+" -> "Import VPN connection..." this plugin completely ignores <tls-crypt> with "OpenVPN Static key V1" portion of config. No file is created from the extracted key either.

Observations

 - It seems like tls-crypt option is supported by the plugin itself. I can see it under "Advanced" pane -> "TLS Settings" tab -> "Mode:" drop-down menu.
 - Other keys & certificates are extracted into `$HOME/.local/share/networkmanagement/certificates/$connection` directory.

=== Beniamino Galvani:

Hi, can you paste the ovpn profile, removing keys and other sensitive data? Which NetworkManager-openvpn version do you have?

=== ratijas:

Hi, thank you for quick reply. Here is my set up.

> $ pacman -Qs 'networkmanager*'; pacman -Qs openvpn:
> 
> lib32-libnm-glib 1.18.5dev+12+ga8746f48ca-1
> libnm 1.24.2-1
> libnm-glib 1.18.5dev+12+ga8746f48ca-1
> networkmanager 1.24.2-1 (gnome)
> networkmanager-openconnect 1.2.6-2
> networkmanager-openvpn 1.8.12-1
> networkmanager-pptp 1.2.9dev+10+gb41b0d0-2
> networkmanager-qt 5.71.0-1 (kf5)
> networkmanager-vpnc 1.2.7dev+20+gdca3aea-2
> networkmanager-openvpn 1.8.12-1
> openvpn 2.4.9-2

On the server side I have this setup:

> Ubuntu 18.04.4 LTS
> openvpn/bionic-updates,now 2.4.4-2ubuntu1.3
> easyrsa r3.0.7

I used openvpn-install script from GitHub. It used to generate <tls-auth>-based profiles for year, but then I upgraded.

My ovpn profiles look like this:

    Before upgrade.

> client
> dev tun
> proto udp
> sndbuf 0
> rcvbuf 0
> remote 139.59.134.143 1194
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
> remote-cert-tls server
> auth SHA512
> cipher AES-256-CBC
> comp-lzo
> setenv opt block-outside-dns
> key-direction 1
> verb 3
> <ca>
> -----BEGIN CERTIFICATE-----
> MIIDKzCCAhOgAwIBAgIJALJy2w7RzrK4MA0GCSqGSIb3DQEBCwUAMBMxETAPBgNV
> ...
> ZkERsu/aeyYRqMFaLReajXD6XU74E/tnhC7z2D4SLx/OMHxG8UFp5fBfXpdedow=
> -----END CERTIFICATE-----
> </ca>
> <cert>
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 12 (0xc)
>         Signature Algorithm: sha256WithRSAEncryption
>         Issuer: CN=ChangeMe
>         Validity
>             Not Before: Jan  2 19:06:51 2020 GMT
>             Not After : Dec 30 19:06:51 2029 GMT
>         Subject: CN=K406Keenetic
>         Subject Public Key Info:
>             Public Key Algorithm: rsaEncryption
>                 RSA Public-Key: (2048 bit)
>                 Modulus:
>                     00:ee:a6:13:36:23:53:01:d2:6c:a0:62:77:ae:72:
>                     ...
>                     21:c7
>                 Exponent: 65537 (0x10001)
>         X509v3 extensions:
>             X509v3 Basic Constraints: 
>                 CA:FALSE
>             X509v3 Subject Key Identifier: 
>                 9F:14:2D:8D:33:E8:E4:43:6F:42:E8:A9:25:A0:F5:C4:0C:5F:43:FA
>             X509v3 Authority Key Identifier: 
>                 keyid:F0:FE:80:E3:80:8F:48:FE:74:A6:6E:90:22:61:8C:D1:7D:25:CD:BA
>                 DirName:/CN=ChangeMe
>                 serial:B2:72:DB:0E:D1:CE:B2:B8
>         X509v3 Extended Key Usage: 
>             TLS Web Client Authentication
>         X509v3 Key Usage: 
>             Digital Signature
> Signature Algorithm: sha256WithRSAEncryption
>      69:d2:cb:a4:f6:b1:19:a6:ae:7e:6a:4b:32:87:fe:1f:c4:28:
>      ...
>      ae:09:e3:4d
> 
> -----BEGIN CERTIFICATE-----
> MIIDOjCCAiKgAwIBAgIBDDANBgkqhkiG9w0BAQsFADATMREwDwYDVQQDDAhDaGFu
> ...
> FrZuHqre91FP3K4J400=
> -----END CERTIFICATE-----
> </cert>
> <key>
> -----BEGIN PRIVATE KEY-----
> MIIEvwIBADANBgkqhkiG9w0BAQEFAASCBKkwggSlAgEAAoIBAQDuphM2I1MB0myg
> ...
> /MM7bhfgx8M4fQtmdvVDQwk3ow==
> -----END PRIVATE KEY-----
> </key>
> <tls-auth>
> 
> 2048 bit OpenVPN static key
> 
> -----BEGIN OpenVPN Static key V1-----
> 03183be34004ecf231f318dd38e86484
> ...
> 50e34047de2f8e9b7b4767bf884eac3d
> -----END OpenVPN Static key V1-----
> </tls-auth>

    After upgrade.

> client
> dev tun
> proto udp
> remote 139.59.134.143 1194
> resolv-retry infinite
> nobind
> persist-key
> persist-tun
> remote-cert-tls server
> auth SHA512
> cipher AES-256-CBC
> ignore-unknown-option block-outside-dns
> block-outside-dns
> verb 3
> <ca>
> -----BEGIN CERTIFICATE-----
> MIIDQjCCAiqgAwIBAgIUfQplEjP5qsgBQQcSx17UshzHJD0wDQYJKoZIhvcNAQEL
> ...
> Q0g66vIbGm6s9srffg61AcGE85PRZA==
> -----END CERTIFICATE-----
> </ca>
> <cert>
> -----BEGIN CERTIFICATE-----
> MIIDTzCCAjegAwIBAgIQb7yK997EQwH8XOSLvz5HHjANBgkqhkiG9w0BAQsFADAT
> ...
> qqQ3CjhH1Chc6bDmK+ubCBGEv2gBzuBZjihbnPIsbfG0v1w=
> -----END CERTIFICATE-----
> </cert>
> <key>
> -----BEGIN PRIVATE KEY-----
> MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDaNMqZ6l+iufmE
> ...
> 2pIYMsHlOCNN0u+ECWCAh0U=
> -----END PRIVATE KEY-----
> </key>
> <tls-crypt>
> -----BEGIN OpenVPN Static key V1-----
> 632e42b8611aac6237e2a32837bf9c32
> ...
> 29edc59e72adfef57c69b1cde03c0d01
> -----END OpenVPN Static key V1-----
> </tls-crypt>

I have no problems providing you with a valid certificate for testing purposed. Just you know, do good and don't do bad sort of things.

=== Beniamino Galvani:

Hi, I tried your ovpn profile with tls-crypt, replacing the keys with valid ones, and the TLS-Crypt key is correctly imported in the "TLS authentication tab", "Key file" field.

=== ratijas:

Let's see...

This is fresh import of ovpn profile on my system. I nuked $HOME/.local/share/networkmanagement/certificates/ aforehand.

![Screenshot showing Connections — System Settings Module](https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/uploads/f94f9c92a8141bb47035525595cb1efd/image.png)

![Screenshot showing Advanced OpenVPN properties window -> TLS Settings tab ->  Mode field erroneously set to None](https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/uploads/cdda2ac813d82be1a0573eaf8490b01b/Screenshot_20200707_191154.png)

![Screenshow of $HOME/.local/share/networkmanagement/certificates/ directory with ca.crt, cert.crt and private.key only](https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/uploads/0b35096e1b27c5758aed5de2b98cf7e6/image.png)

=== Beniamino Galvani:

> What's that "TLS authentication tab" you mentioned — is it renamed "TLS Settings"? If not, can you provide a screenshot, please?

Wait, now I understand :) you are using the KDE applet; I'm using nm-connection-editor. Please file the issue on the KDE applet bug tracker.

=== ratijas:

Oh wait, so there are two different subsystems each tries to parse config file in its own way?  That's insane!

Different front-end for KDE and Gnome are alright, but why separate back-ends?

=== Thomas Haller:

Import of openvpn files is done by the client-applicant that you are using.

nmcli, nm-connection-editor, and gnome-control-center uses for that the glib based code from this project. KDE/plasma-nm has a separate implementation of that (https://github.com/KDE/plasma-nm/tree/master/vpn/openvpn). I agree, it would make sense that also KDE uses the same import functionality, especially because it is already intended to be used as a share library.

=== ratijas:

Thanks for pointing out!

In that case, I'll forward this issue to https://bugs.kde.org, and maybe even try to patch plasma-nm myself.

On a side note, since there is now both tls-auth AND tls-crypt, don't you think that it would make more sense to rename the "TLS authentication" tab to "TLS Settings" as in plasma-nm or something?

=== ratijas closed this issue

=== ratijas:

I managed to install nm-connection-editor and try it out per your suggestion.

Indeed, it did the right thing including correct handling of tls-crypt, but stored extracted keys as `$HOME/.cert/nm-openvpn/%connection%-%key%.pem` instead.

Both Qt and GTK interfaces looks fairly similar, and probably were copy-pasted between frameworks — not sure in which direction though.
Comment 9 Bug Janitor Service 2022-11-09 23:06:17 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-nm/-/merge_requests/172