Installing L2TP/IPSEC Client

Hi, I have found many different instructions, neither of which was very recent. For example:

sudo apt-get update
sudo apt-get install network-manager-l2tp
sudo apt-get install network-manager-l2tp-gnome

or

sudo add-apt-repository ppa:nm-l2tp/network-manager-l2tp
sudo apt-get update
sudo apt-get install network-manager-l2tp-gnome

or

sudo add-apt-repository universe
sudo apt update
sudo apt install network-manager-l2tp-gnome

All of them seem to reference Gnome, which is probably wrong when using Lubuntu. Anyone knows the correct instructions?

1 Like

OK, so this

sudo apt update
sudo apt install network-manager-l2tp
sudo apt install network-manager-l2tp-gnome

seems to install it. But while it now shows among the connections and can be configured, there doesnā€™t seem to be any way to actually tell the system to connect to it. Clicking on the connection:

lubuntu-l2tp-listed
immediately results in the following message:

lubuntu-l2tp-wont-connect
Even though it was never connected to it in the first place. Both right- and left-click produce the same result. No attempt at connecting is actually made.

Lubuntu uses /usr/bin/nm-tray (which uses the NetworkManagerQt API from KDE) for its system tray utility, it also uses the Gtk3 based /usr/bin/nm-connection-editor from the GNOME Project for editing NetworkManager connections, including VPN connections.

You were correct in installing network-manager-l2tp-gnome as it contains the Gtk3 L2TP editor plug-in for use with nm-connection-editor.

Try the following and see if there was anything which indicates what went wrong :

sudo journalctl --no-hostname _SYSTEMD_UNIT=NetworkManager.service + SYSLOG_IDENTIFIER=pppd

1 Like

ā€œā€¦Clicking on the connection:ā€¦ā€ with left-click produces what you posted.
With a right-click, you get a different menu >
Edit connectionsā€¦ > click ā€˜+ā€™ (add) and choose L2TP.

1 Like

Thank you dkosovic, Iā€™ll take a look. I can connect to the same router with iOS, iPadOS, Win7 physical and Win10 VBoxed, and use the resources on the remote LAN. But none of the Linux distros that I tried so far (Lubuntu, Kubuntu, Berylium - basically Debian) has worked. The only difference is that with Lubuntu, I get the message shown in the screenshot instantly, i.e. it doesnā€™t even try to connect. While Kubuntu and Berylium clearly try, then cheerfully announce that the connection was established, but not only I can not even ping anything on the remote LAN, in about 30 secs I get a message that the connection failed. So as you see my nick, I must be doing something fundamentally wrong when trying to get it work in Linux. Itā€™s not an issue of a specific distro. The problem must be in me. Iā€™ll post more info after trying the command that you suggested.

Lubuntuā€™s /usr/bin/nm-tray system tray for a successful connection has a popup message within a couple of seconds. I think it brings up the same message for a disconnection and an unsuccessful connection. Instead of using the /usr/bin/nm-tray system tray, try using the /usr/bin/nmcli command-line to bring up the VPN connection, e.g. :

nmcli con up id 'WZ L2TP Test'

or the following to get nmcli to explicitly ask for the password :

nmcli con up id 'WZ L2TP Test' --ask

the log output would be useful.

For the Ubuntu based Linux distros, please upgrade to the latest network-manager-l2tp 1.20.8 from the following PPA:

I suspect you have encountered a routing bug for the small minority of L2TP/IPsec VPN servers that have the External Gateway and PTP host configured to be the same IP address, resulting in NetworkManager >= 1.30.6 adding a route to the PTP host that breaks the routing. Upgrading to the latest version of NetworkManager-l2tp should fix the issue (as NetworkManager-l2tp 1.20.8 lets NetworkManager know what the PTP host is in this case).

Broken routing L2TP VPN connections usually stay up for around 30 seconds. In the past, a workaround was to remove that spurious route on the command-line, but I would recommend upgrading to the latest network-manager-l2tp package now.

Debian Sid (i.e., unstable) has network-manager-l2tp 1.20.8, other Debian versions (and derivatives) wouldnā€™t yet:

Unrelated, I would recommend KDE Neon, which is an Ubuntu LTS based distribution from KDE over Kubuntu as the KDE plasma-nm packages are usually newer and KDE bug fixes for packages come more often.

1 Like

I see the same package available in Ubuntu repositories (eg. Ubuntu ā€“ Details of package network-manager-l2tp in lunar with the identical changelog to that I see in Debian repositories & Debian changelog so why go off-topic with detail? especially as not required.

Please try and stay on-topic if you can, and donā€™t forget Ubuntu uses Debian sid as itā€™s source (where possible & when not frozen as approaching release of course).

I created both the network-manager-l2tp package in Debian Sid and the Ubuntu packages in the aforementioned PPA. As multiple Ubuntu and Debian linux distors were mentioned, I was just pointing out the network-manager-l2tp 1.20.8 which has the routing bug fix is currently only available in the PPA for Ubuntu derivatives. I had never heard of Berylium (Debian derivative) before today, so pointed out the only Debian version that has network-manager-l2tp 1.20.8 is Debian sid. Ubuntu wonā€™t officially get network-manager-l2tp 1.20.8 from Debian sid until Ubuntu 23.04.

2 Likes

Thank you for your work and service upstream in Debian that also benefits us here in Ubuntu. Iā€™d not noted it was your name in the changelogs in my pastes (both Debian & Ubuntu); for which I apologize.

Thank you also for your service in providing your work in PPA form such that those on stable releases [of Ubuntu] can also benefit.

Dear dkosovic, first of all, thank you so much for your help! I did the following:

  • Created a clone of a clean installation of Lubuntu 22.04.1 with LXQt 1.20 in VBox.

  • It never had l2tp installed.

  • Triple-checked that it was attached to Bridged Adapter.

  • Ran update/upgrade.

  • Installed l2tp according to your instructions and those that were shown in the terminal.

  • Connected to the VPN from the host to make sure it worked, it did.

  • Disconnected the host from the VPN.

  • Configured l2tp in lubuntu using GUI. Just name, host IP, un, pw, shared secret, no other changes.

  • Tried to connect using GUI first.

  • This time it took a bit of time, got the message that the connection was established, but couldnā€™t ping through the VPN and it shut down after 42 secs (as far as I could time it correctly). So this is a progress from the GUI showing immediately that the connection was disconnected. [edit: this only happened the first time, immediately after configuring the VPN, when I tried it later from GUI, it once again went straight to the ā€œdisconnectedā€ message]

  • Then I followed your instructions to connect using the terminal. (the command without --ask gave me an error, but the one with --ask worked)

  • The results were identical to the first try with GUI. It said it was connected, I could not ping through it. And it disconnected after 42 secs.

  • Then I ran the command to get the log. But that resulted in an enormous number of lines, so Iā€™d like to ask you where I should start copying from. (just in case, I copied everything , starting from what it seemed to me like the end of the previous attempt to connect, i.e.
    Feb 21 06:55:37 ipsec_starter[1704]: charon stopped after 200 ms
    Feb 21 06:55:37 ipsec_starter[1704]: ipsec starter stopped
    Feb 21 06:55:37 nm-l2tp-service[1676]: ipsec shut down
    I have all the rest saved in Notepad, so if this is the correct beginning, I can enter it here)

  • Finally, I connected to the VPN from the host and looked into the routerā€™s log. There wasnā€™t much there, but Iā€™d say that this is related to my attempts to connect:
    397 2023-02-21 06:53:45 <5> : IKE began to negotiate as responder. Mode=main,peers=24.xxx.xx.xx8<->19x.xx.xxx.xx2.
    398 2023-02-21 06:55:07 <5> : IKE began to negotiate as responder. Mode=main,peers=24.xxx.xx.xx8<->19x.xx.xxx.xx2.
    399 2023-02-21 07:00:23 <5> : IKE began to negotiate as responder. Mode=main,peers=24.xxx.xx.xx8<->19x.xx.xxx.xx2.

So please, let me know what part of the Lubuntu log I should post.

Thank you very much!

Issue 1 - No GUI VPN password prompt

I only wanted to see the log for your original issue which would have been short as the connection failed immediately. Iā€™ve reproduced the issue on Lubuntu by selecting ā€œAsk for the password every timeā€ in the right side of the L2TP user authentication password field. This is the error log entry :

NetworkManager[728]: <warn> [1677373915.6685] vpn[0x5625d31c0820,73564336-2e96-4de8-b4a7-0a5077b5fbc9,"VPNtest"]: secrets: failed to request VPN secrets #3: No agents were available for this request.

This is definitely a Lubuntu only issue amongst the Ubuntu remixes, I believe itā€™s because it uses a combination of KDE and GNOME NetworkManager related components. To spare you a long winded explanation, I wonā€™t go into more details.

The workaround is to select ā€œStore this password for all usersā€ in the right side of the password field, as it will bypass the Secret Service agent, any of the other options will use the Secret Service.

Issue 2 - Broken routing

As the VPN connection is up for 42 seconds, but you are unable to ping any hosts, it sounds like a routing issue. Alto to rule out DNS VPN issues, try pinging IP addresses rather than hostnames if you werenā€™t.

You are definitely using network-manager-l2tp 1.20.8 (from the PPA) and can be confirmed with dpkg -l network-manager-l2tp ? Just asking to be sure as I really thought it would fix your routing issue.

Iā€™ll show you what working routes I see:

Before VPN connection

$ ip route
default via 172.16.244.2 dev ens33 proto dhcp metric 100 
172.16.244.0/24 dev ens33 proto kernel scope link src 172.16.244.132 metric 100 

During VPN connection:

$ ip route
default dev ppp0 proto static scope link metric 50 
default via 172.16.244.2 dev ens33 proto dhcp metric 100 
146.70.141.61 via 172.16.244.2 dev ens33 proto static metric 50 
172.16.244.0/24 dev ens33 proto kernel scope link src 172.16.244.132 metric 100 
172.16.244.2 dev ens33 proto static scope link metric 50 
192.168.30.1 dev ppp0 proto kernel scope link src 192.168.30.2 
192.168.30.1 dev ppp0 proto kernel scope link src 192.168.30.2 metric 50

or route with netstat which some find easier to read :

$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
default         _gateway        0.0.0.0         UG        0 0          0 ens33
146.70.141.61   _gateway        255.255.255.255 UGH       0 0          0 ens33
172.16.244.0    0.0.0.0         255.255.255.0   U         0 0          0 ens33
_gateway        0.0.0.0         255.255.255.255 UH        0 0          0 ens33
192.168.30.1    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
192.168.30.1    0.0.0.0         255.255.255.255 UH        0 0          0 ppp0

Make sure the ppp0 device only has one IP address like the following, if there are two addresses then something is wrong:

$ ip add show dev ppp0
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1200 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 192.168.30.2 peer 192.168.30.1/32 scope global ppp0
       valid_lft forever preferred_lft forever
2 Likes

Regarding the routing issue, if the remote router and home router are using the same private subnet IP address range, reconfigure one of them to use a different subnet.

Windows L2TP client is able to connect if both routers are using same subnet, but with Linux it goes into a routing loop.

1 Like

Dear dkosovic, thank you once again for your continued effort to help me resolve this issue. I followed your instructions and hereā€™s the outcome:

Issue 1 - No GUI VPN password prompt
Thank you, though I havenā€™t tried this for now, as it is moot if I canā€™t make the VPN work.

Issue 2 - Broken routing
The local and the remote LAN use different subnets. This is confirmed by the outcome of the $ ip route command below. I didnā€™t use netstat, because Lubuntu said it wasnā€™t installed and I didnā€™t want to bring additional variables to the problem by installing additional software.

STEP 1: Checking the version of network-manager-l2tp:

user@user-virtualbox:~$ dpkg -l network-manager-l2tp
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                 Version                       Architecture Description
+++-====================-=============================-============-======================================>
ii  network-manager-l2tp 1.20.8-1~ubuntu22.04.1~ppa1.1 amd64        network management framework (L2TP plu>
lines 1-6/6 (END)

STEP 2: Checking the routing without the VPN:

user@user-virtualbox:~$ sudo ip route
[sudo] password for user: 
default via 192.168.8.1 dev enp0s3 proto dhcp metric 100 
192.168.8.0/24 dev enp0s3 proto kernel scope link src 192.168.8.210 metric 100 
user@user-virtualbox:~$ 

Confirmation that the VPN is down:

ip add show dev ppp0
user@user-virtualbox:~$ sudo ip add show dev ppp0
[sudo] password for user: 
Device "ppp0" does not exist.
user@user-virtualbox:~$ 

STEP 3: Connecting to the VPN:

user@user-virtualbox:~$ nmcli con up id 'WZ L2TP Test' --ask
You need to authenticate to access the Virtual Private Network ā€œWZ L2TP Testā€.
Password (vpn.secrets.password): ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢
You need to authenticate to access the Virtual Private Network ā€œWZ L2TP Testā€.
Pre-shared key (PSK) (vpn.secrets.ipsec-psk): ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢ā€¢
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/3)
user@user-virtualbox:~$ 

After even the GUI notification showed that the VPN was up, I ran:

user@user-virtualbox:~$ sudo ip route
default dev ppp0 proto static scope link metric 50 
default via 192.168.8.1 dev enp0s3 proto dhcp metric 100 
24.xxx.xxx.168 dev ppp0 proto kernel scope link src 192.168.70.200 
24.xxx.xxx.168 via 192.168.8.1 dev enp0s3 proto static metric 50 
24.xxx.xxx.168 dev ppp0 proto kernel scope link src 192.168.70.200 metric 50 
192.168.8.0/24 dev enp0s3 proto kernel scope link src 192.168.8.210 metric 100 
192.168.8.1 dev enp0s3 proto static scope link metric 50 
user@user-virtualbox:~$ 

and

user@user-virtualbox:~$ sudo ip add show dev ppp0
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet 192.168.70.200 peer 24.xxx.xxx.168/32 scope global ppp0
       valid_lft forever preferred_lft forever
user@user-virtualbox:~$ 

Ping to the LAN side of the router (through the VPN) didnā€™t go through:

user@user-virtualbox:~$ sudo ping 192.168.70.1
PING 192.168.70.1 (192.168.70.1) 56(84) bytes of data.
^C
--- 192.168.70.1 ping statistics ---
36 packets transmitted, 0 received, 100% packet loss, time 36041ms

Ping to Google did - but only after the VPN connection dropped, as evident from the number of sent/lost packets:

user@user-virtualbox:~$ sudo ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=31 ttl=118 time=114 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=118 time=117 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=118 time=122 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=118 time=115 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=118 time=117 ms
^C
--- 8.8.8.8 ping statistics ---
35 packets transmitted, 5 received, 85.7143% packet loss, time 34727ms
rtt min/avg/max/mdev = 114.453/116.940/121.660/2.638 ms
user@user-virtualbox:~$ 

As for the Lubuntu log, if you give me an idea what to look for, Iā€™ll paste that particular section here.

I apologize for only experimenting with the connection on weekends. Starting later this week, Iā€™ll be in the position to follow your instructions within 24 hours.

Thank you very much!

1 Like

You have one of the rare cases where on the VPN server side the Ext Gateway and PTP host are one and the same, 24.xxx.xxx.168. Could be the firewall or the VPN server configuration on the remote side thatā€™s configured that way.

You basically have too many routes going to 24.xxx.xxx.168 and they are conflicting. Once the VPN connection is up, try the following:

sudo ip route del 24.xxx.xxx.168 dev ppp0

Also if you are still using network-manager 1.36.4, please upgrade to 1.36.6 from the updates repository, there is a chance it might fix the routing issue.

Thank you once again! Will do, once I settle down. Iā€™m traveling now. But a bit of a background, in case it might be useful. The remote router is TP-Link TL-ER6020 and it is assigned a single public WAN IP out of the subnet that we purchased, I believe /26. So I do have a few unused public IPs in that subnet, but I donā€™t think that this router has the option to have a different WAN IP for the VPN. There is no separate firewall between this router and the ISP. I built all the networks 12 years ago, but I am a mechanical engineer, so while Iā€™m used to reading manuals and following instructions, once we get to routes, Iā€™m starting to get out of my depth and truly appreciate your help. There are permanent IPSEC (LAN-to-LAN) VPNs between the locations and L2TP (Client-to-LAN) connections ready at all the sites for external contractors - and for me. None of us has ever had a problem with the L2TPs until I started my - yet another - attempt to move to Linux. I can use my Win10 VM to connect to the system, so itā€™s not a crisis. But partly Iā€™d like to eliminate Windows for good. And partly, at this point, the engineer in me got curious/furious and Iā€™d love to get to the bottom of this problem or it will bug me forever. Thank you again and more later this week.

Version of network-manager-l2tp:
You say:

Blockquote
ā€œif you are still using network-manager 1.36.4, please upgrade to 1.36.6ā€

But the outcome of the dpkg -l network-manager-l2tp command shows that Iā€™m running version:
network-manager-l2tp 1.20.8-1~ubuntu22.04.1~ppa1.1 amd64
1.20 seems a lot older than 1.36!

I just ran apt update and apt upgrade, but it failed to bring the version above 1.20.8-1.

How can I upgrade to 1.36.6 that you recommend? Here are my sources:

In the following Ubuntu bug report, the user is connecting to a Zyxel router which has a bult-in firewall that is doing the same thing (Ext Gateway and PTP host are one and the same) as your TP-Link router. He ended up using network-manager-l2tp 1.20.8 from the PPA and network-manager 1.36.6 from updates (which fixed his bug) :

NetworkManager does the routing, not NetworkManager-l2tp. NetworkManager 1.36 was a major overhaul in source code and completely changed the way it internally handles IPv4, IPv6 and routing. NetworkManager-l2tp had a workaround for the case where Ext Gateway and PTP host are one and the same by not supplying NetworkManager with what the PTP host was, but that workaround broke with the release of NetworkManager 1.36. With NetworkManager-l2tp 1.20.8 it reversed that workaround in its source code.

A bit off-topic, but I put it here anyway.

I happened to be installing Debian 12 on a laptop a few days ago, and needed to set the WiFi credentials. I noticed a subtle change in their implementation of editing configurations in nm-tray.

When selecting ā€˜Edit connecionsā€¦ā€™ from the tray, the character based nmtui-edit applet is called, inside a xterm terminal. It looks ugly, even more ugly than on Lubuntu (the editor is character based), and seems to be less usable on Debian compared to Lubuntu.

After reading @dkosovicā€™s possessive attribution of Lubuntu in relation to nm-tray, I wondered, is there maybe on Lubuntu another version of that very useful tray application running?

Indeed there is. Lubuntu uses an alternatives symlink-helper (x-terminal-emulator) when invoking the nm-trayā€™s configuration editor

I found it here: GitHub - lubuntu-team/nm-tray-packaging: Packaging for nm-tray. Lubuntu veteran Simon (tsimonq2) has made a patch, and instead of xterm the systems selected alternative editor (configurable via Preferences ā†’ Alternatives Configurator) will be used. On Lubuntu this will be usually qterminal.

The configuration editor looks much, much better (and scaled to propertion as well) when opened with qterminal.

Now, to come back to Debian, I appreciate Simons effort, ofcourse, but should it not be a good idea to just make a pull request on palinek/nm-tray so (eventually) also Debian users (of the limited LXQt user group) will benefit from this?

Aproposā€¦ an alternative (sic) would be (perhaps even better) to just change the default editor configuration in nm-trayā€™s configuration file (see /usr/share/nm-tray/nm-tray.conf) from

connectionsEditor=xterm, -e, nmtui-edit

to

connectionsEditor=x-terminal-emulator, -e, nmtui-edit

This is not just an alternative implementation. It looks almost nothing, what I am yarning about here, but a little longer ago I had to fall back (on Debian) to another network configuration system (connman) and one of its configurators (cmst), instead of NetworkManager (and nm-tray). Just because xterm was unwittingly removed from the system. No xterm, no configuration editor. I discovered that just yesterday, after reading this thread.

Thatā€™s interesting about nmtui (or in this case its symlink /usr/bin/nmtui-edit), weird thing is that when I select ā€˜Edit connectionsā€¦ā€™ from nm-tray, it starts the GTK3 based /usr/bin/nm-connection-editor.

Unfortunately nmtui doesnā€™t support adding and editing VPN connections (along with WPA Enterprise wireless connections and 802.1X Ethernet connections), Iā€™m guessing thatā€™s why nm-tray switched to /usr/bin/nm-connection-editor for the connection editor (possibly after I installed the network-manager-l2tp-gnome package which contains the GTK3 based L2TP editor plugin).

Looks like from the upstream nm-tray issues, nm-tray canā€™t prompt for VPN passwords :

(for a moment I thought the solution for a GUI VPN password prompt not working would involve Kubuntuā€™s plasma-nm-l2tp package which contains a Qt5 password dialog box which uses the same D-Bus KF5::NetworkManagerQt API as nm-tray)