> So IIUC the connection works as expected, but only after reloading the connection profiles; it doesn't show up at the time it is expected, right?
Hm, not sure if we mean the same. That two connections (tun2 and <vpn_conn>) appear after connecting to the VPN is expected. NM recognizes tun2 as "external" as it is an auxiliary device/connection created by the OpenVPN plugin. The problem that is happening is that that connection is being stored in /etc/netplan/, which should not be the case. Note that tun0 and tun1 are slightly different as those are created by the OpenVPN server also running on the device. The netplan files for them are not written anymore after changing the patch. > Does running 'nmcli connection reload' after the connection profile for the VPN connection (tun2?) got written, make it show up in the NM daemon? No, that does not happen. But it happens if I reboot the system. I think that is because there is some file in /run that prevents this from happening if just reloading things. Before rebooting: $ sudo ls run/NetworkManager/system-connections/ -l total 20 lrwxrwxrwx 1 root root 9 Jan 10 11:22 891164a5-1fed-42b8-8f6e-903db6396d5e.nmmeta -> /dev/null -rw------- 1 root root 403 Jan 10 11:24 netplan-NM-891164a5-1fed-42b8-8f6e-903db6396d5e.nmconnection -rw------- 1 root root 1248 Jan 10 11:24 netplan-NM-af486148-2495-48a9-9704-2a1230e97e32.nmconnection -rw------- 1 root root 131 Jan 10 11:24 netplan-ens3.nmconnection -rw------- 1 root root 336 Jan 10 09:37 tun0.nmconnection -rw------- 1 root root 336 Jan 10 09:37 tun1.nmconnection After rebooting: $ sudo ls run/NetworkManager/system-connections/ -l total 20 -rw------- 1 root root 403 Jan 10 11:28 netplan-NM-891164a5-1fed-42b8-8f6e-903db6396d5e.nmconnection -rw------- 1 root root 1248 Jan 10 11:28 netplan-NM-af486148-2495-48a9-9704-2a1230e97e32.nmconnection -rw------- 1 root root 131 Jan 10 11:28 netplan-ens3.nmconnection -rw------- 1 root root 336 Jan 10 11:28 tun0.nmconnection -rw------- 1 root root 336 Jan 10 11:28 tun1.nmconnection 891164a5 was tun2 and af486148 the VPN connection. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to network-manager in Ubuntu. https://bugs.launchpad.net/bugs/1998207 Title: netplan network-manager plugin tries to save temporary connections Status in netplan: Triaged Status in network-manager package in Ubuntu: Confirmed Bug description: When creating an OpenVPN connection, a temporal connection called tunN is created. For instance, after activating a connection called vpntest, I have: NAME UUID TYPE DEVICE vpntest 458856e6-8f0f-4dc6-82f2-dd72868252a0 vpn ens3 tun0 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 tun tun0 tun0 is created/removed after activating/deactivating vpntest and should not really be saved, but I see netplan adding it in /etc/netplan. And while doing so the plugin also reports some errors (I see these when stopping the connection): Nov 28 16:16:57 ubuntu NetworkManager[11752]: <error> [1669652217.2920] BUG: the profile cannot be stored in keyfile format without becoming unusable: cannot access file: No such file or directory Nov 28 16:16:57 ubuntu NetworkManager[11752]: ((src/libnm-core-impl/nm-connection.c:342)): assertion '<dropped>' failed Nov 28 16:16:57 ubuntu NetworkManager[11752]: <warn> [1669652217.2920] keyfile: commit: failure to write 1eb1dbe8-5678-4818-9adf-fb2dc01ed132 ((null)) to "/run/NetworkManager/system-connections/tun0-1eb1dbe8-5678-4818-9adf-fb2dc01ed132.nmconnection": keyfile writer produces an invalid connection: cannot access file: No such file or directory To manage notifications about this bug go to: https://bugs.launchpad.net/netplan/+bug/1998207/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
