Not on my system though. But on a fresh system that has not been subject to tons of experimenting and development, the GTK-based editor is used.
This setting is apparently loaded from a XDG configuration path: /etc/xdg/xdg-Lubuntu/nm-tray/nm-tray.conf. Something new to me.
Many laptop(-users) never see the light of any network configuration. I am fluent with connman. It is easy to use with server-provisioning tooling. I use it, although not often, when I want to give a laptop a static IP.
Remains to be investigated why I lost the GTK-based connection manager in nm-tray.
Regarding the lack of VPN GUI password prompt on Lubuntu, if I kill the Qt5 based nm-tray and run GTK3 based nm-applet instead, I’m able to get a dialog box prompting for the VPN password.
nm-applet is from the same package as nm-connection-editor, so is able to make use of the GTK3 based password dialog box in the network-manager-l2tp-gnome package (and similarly for other NetworkManager VPN clients with their corresponding -gnome package). Although I said password, the VPN password dialog boxes can prompt for PSKs, certificates, keys, tokens, etc depending on the VPN client.
To end my contribution(s) here, for now and forever, it is not sufficient to just bind connectionsEditor to a terminal. Well, at least at my system it is not. Root-priviliges are required as well.
In my case, I especially appreciate the beamy WiFi icon presented by nm-tray (to quickly check which network I am on). For the configuring part, rarely needed, i just fall back to calling nmtui-edit as root.
This works for me. On a pristine OS straigth from the ISO things are different, better.
Issue 1: L2TP Password not saved/no GUI prompt
I re-entered the password and chose “Store the password for all users” as dkosovic suggested above. It worked and the VPN connected upon entering the command
nmcli con up id 'WZ L2TP Test'
without using the --ask option, as well as by using GUI.
As for the VPN password not being encrypted when saved this way (if I understand it correctly), I consider this to still be a viable workaround when combined with the use of full-disk encryption.
Issue 2 - Broken routing
Upon connecting to the VPN, I ran the command that dkosovic suggested above:
sudo ip route del 24.xxx.xxx.168 dev ppp0
Once again, this worked! It deleted the extraneous route and I was able to ping the LAN side IP of the VPN router, ping 188.8.131.52 and access the devices inside the LAN through the VPN.
Issue 3 - Preventing all this from happening
Is there currently a way in Lubuntu to:
3a make the L2TP password save for the current user or make Lubuntu display the GUI prompt?
3b prevent the extraneous route from being created?
Especially 3b would be useful if solved, because connecting to the VPN and then rushing to delete the extra route before the connection drops, each time I need to use these connections (several times a day), would be quite frustrating.
You could switch from Qt5 based nm-tray to GTK3 based nm-applet which supports VPN passwords. As to how to do it permanently, I’m not sure, but as a temporary proof of concept you can do:
Can you confirm you have updated to network-manager 1.36.6?
network-manger-l2tp does not do the routing, network-manger does. The newer network-manger-l2tp 1.20.8 provides all the details needed to network-manager to do the routing correctly for this case where the VPN External Gateway and PTP host use the same IP address. I have a strong suspicion that network-manager 1.36.4 is broken.
No VPN GUI prompt
Thank you very much! I have successfully replaced nm-tray with nm-applet using the link you sent me. Logged out, logged back in, it autostarts and I can connect to the VPN using the GUI.
I have to apologize, I don’t know how to check the version of network-manager. Could I ask you for sharing the command with me?
I followed your instructions. Disappointingly though, it seems that I already have the latest version of network-manager:
user@user-virtualbox:~$ sudo apt upgrade network-manager
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
network-manager is already the newest version (1.36.6-0ubuntu2).
network-manager set to manually installed.
Calculating upgrade... Done
Second L2TP Test configured - via nm-applet
To test the new GUI applet all the way, I configured a L2TP/IPSEC connection to another location. The applet worked mostly as expected. The only flaw seemed to be that after clicking the final Save in the applet, a new GUI dialog appeared, complaining that the “keyring” didn’t open and that the settings weren’t saved, which made me worried. (I’m sorry, I didn’t take a screenshot, so I don’t have the exact wording). It asked for a password, so guessing it would be my Lubuntu password, rather than the VPN password, I entered it. The dialog box just disappeared, giving no indication whether or not the problem was resolved, but upon checking, both the VPN password and the shared secret were saved. The VPN connected smoothly on the first try, but once again created the extra route (see my reply about the version of the network-manager above). The router make, though not the model, is the same at this location, as is everywhere else. Quickly deleting the extra route, before the connection dropped, left the VPN up and fully functional. So it’s really the extra route that remains to be resolved.
In case it might be useful, this router is: TP-Link TL-ER604W Firmware Version:|1.2.0 Build 20160825 Rel.45884s Hardware Version:|TL-ER604W v2.0
The one to which we were connecting previously was: TP-Link TL-ER6020
NOTE: These two routers are permanently connected with a LAN-to-LAN IPSEC VPN.
NetworkManger queries the kernel for some of the routes and the two problematic dev ppp0 routes you have are kernel routes (the two routes are the same, just different metrics), I heard some reports of VirtualBox VMs having some issues with kernel routes with Ubuntu 22.04 (related, not sure?). I have no idea what the fix is.
Sorry, this is the first report I heard where upgrading to network-manager-l2tp 1.20.8 didn’t fix the routing issue on Ubuntu 22.04 in the case of when the VPN External Gateway and PTP host use the same IP address. So, I’m really not sure what is going wrong.
In the VPN connection’s IPV4 settings you might be able to tick the “Ignore automatically obtained routes” then see if the 2 problematic routes are gone. You may need to manually add some routes back also in the IPv4 settings.
Hopefully it was just a transient issue with the keyring.
Thank you sir, you helped me a lot! I’ll try your latest suggestion too. Two notes:
The two TP-Link routers that I tested with have been EOL for ages (I’m not the owner of the company…) which is also why the firmware is ancient. I have a current model available, so I’ll test against that to see if the results are different.
I’m nearing the point of installing a Linux distro, possibly Lubuntu, on a physical testing laptop (it’s a lot quicker to clone a clean VM installation than to reinstall while learning). After that, I will once again test against these routers and will report the results here.
I believe I jumped to an incorrect assumption, the routes NetworkManager obtains from the kernel are the ones listed with no metric (i.e., metric=0), not the ones that have kernel in the ip route output. So maybe not VirtualBox related.
Regarding VPN External Gateway and PTP host using the same IP address and routers, here are the relevant location in the NetworkManager 1.36.6 code where the values are first obtained (from the values supplied by NetworkManager-l2tp):
which states in the commit’s comments : “For external gateway route management. This setting allows a user to deactivate the automatic route addition to the external gateway. It can be especially useful when a VPN inside another VPN is used.”
Since you mentioned there is a permanent IPsec (LAN-to-LAN) VPN tunnel between the locations, this new ipv4.auto-route-ext-gw setting might be relevant to you and it can be permanently set with nmcli and is available with NetworkManager >= 1.42.0. might be simpler to test with a Linux distro that comes with NetworkManager >= 1.42.0, alternatively if you are up to it, you can backport that ipv4.auto-route-ext-gw commit to the network-manager 1.36.6 source package (or source code) that Ubuntu 22.04 uses.
As it will be a while before Lubuntu comes with network-manager >= 1.42.0, you could try testing with Debian sid on a VM as it comes with both network-manager >= 1.42.0 and network-manager-l2tp 1.20.8. See the following page for installation instructions, maybe use the mini.iso approach or whatever is easier for you:
Wow! Thank you! I’m comfortable downloading/installing ISOs in VBox. Editing system files, such as sources, not so much yet. So I’m downloading Debian Sid and will report back if it behaves differently than Lubuntu.
Well, I’ve learned something new: there are no ISOs for Sid. And although I followed the instructions to install it from the mini.iso, it either doesn’t install GUI or I must have missed the option during the installation. I remember experimenting with “normal” Debian and it offered a choice of DEs selectable with the spacebar. But I didn’t see that option this time. I hate to ask this question here, but is there perhaps a distro that uses network-manager >= 1.42.0, but that already comes as an installable ISO that boots into GUI? At least to finish the troubleshooting.
Wow! I’m learning more than I expected! And yes, thank you, it worked. It doesn’t have the network applet though. The one that looks like Ethernet port. Am I guessing correctly that sudo apt nm-applet is what I should do? Or not? Or something else? Basically to get the network GUI to the same state in which Lubuntu is after the stock install. So I could follow the instructions above to install/configure L2TP and test.
I think Debian LXQt uses connman by default? You may need to uninstall that and then install NetworManager. And then I think LXQt has the NetworkManager applet built in? I could be wrong there, but I’m not seeing a specific NetworkManager applet for LXQt in Ubuntu’s archives, so it seems likely that there probably isn’t one in Debian either.