Regression in L2TP/IPsec VPN to Meraki MX: Pre-existing Connections Work After Upgrade But New Profiles Fail in Debian 12/Ubuntu 24.04

[Lonniebiz]

Bug Description

L2TP/IPsec VPN connections to Meraki MX firewalls fail to establish on fresh installations of Debian 12 and Ubuntu 24.04, while existing connections created in earlier versions survive an upgrade but cannot be recreated if deleted.

Environment

• Potentially Affected Packages:
  • network-manager-l2tp
  • network-manager-l2tp-gnome
  • network-manager-strongswan
  • strongswan-nm
  • xl2tpd
  • Any dependencies of these packages that may have changed in newer distributions
• Operating Systems Affected:
  • Debian 12 (Bookworm) - fresh install
  • Ubuntu 24.04 LTS (Noble Numbat) - fresh install
  • Debian 12 (upgraded from Debian 11) - for new VPN profiles only
  • Ubuntu 24.04 (upgraded from Ubuntu 22.04) - for new VPN profiles only
• Operating Systems Working:
  • Debian 11 (Bullseye)
  • Ubuntu 22.04 LTS (Jammy Jellyfish)
  • Debian 12 (upgraded from Debian 11) - only for pre-existing VPN profiles
  • Ubuntu 24.04 (upgraded from Ubuntu 22.04) - only for pre-existing VPN profiles
• Hardware Tested:
  • ASUS Zenbook 14 OLED
  • Lenovo IdeaPad 15IAu7
  • Virtual machines
• VPN Type: L2TP/IPsec with PSK and username/password authentication
• VPN Server: Meraki MX Firewall

Steps to Reproduce

1. Fresh install of Debian 12 or Ubuntu 24.04
2. Install required packages: network-manager-l2tp, network-manager-l2tp-gnome, network-manager-strongswan, strongswan-nm
3. Configure L2TP/IPsec VPN connection to Meraki MX firewall following these steps
4. Attempt to connect to the VPN

Expected Behavior

VPN connection established successfully.

Actual Behavior

VPN connection fails to establish.

Regression Information

This is a critical regression that affects both fresh installations and the ability to create new connections on upgraded systems:

1. VPN connections work perfectly on Debian 11 and Ubuntu 22.04
2. Pre-existing VPN connections continue to work after upgrading to Debian 12/Ubuntu 24.04
3. CRITICAL: On upgraded systems, if you delete a working VPN profile, you CANNOT recreate it successfully
4. CRITICAL: On upgraded systems, creating additional VPN profiles for other users or with different names also fails
5. All attempts to create new VPN profiles on fresh installations of Debian 12/Ubuntu 24.04 fail

Additional Testing Details

I've conducted extensive testing to confirm this regression:

1. I installed Ubuntu 22.04 fresh on a Lenovo IdeaPad 15IAu7, and the VPN setup worked perfectly following the guide.

2. I then upgraded this system to Ubuntu 24.04.2, and the pre-existing VPN configuration continued to work correctly.

3. After the upgrade to 24.04.2, I attempted to:

   • Create another VPN profile for a different user - FAILED
   • Create another profile with different credentials - FAILED
   • Create another entry for the same user with a different profile name - FAILED

4. Most critically: When I deleted the working VPN profile that was originally created in 22.04, I was completely unable to recreate it in 24.04.2, even with identical settings.

5. I have concerns that even modifying the working VPN profile (e.g., updating a password) might corrupt

Final Thoughts and Request for Help

I'm submitting this report with the hope that someone can help identify where this regression is occurring. I've spent considerable time testing and documenting this issue, as it's forcing me to revert to Windows for new deployments where I'd strongly prefer to use Linux.

While I've filed this with the network-manager-l2tp project as a starting point, I recognize the issue could be in any of the related packages or their interactions. If you're reading this and have insights about which component might be causing this regression, or if you have a workaround beyond the one I've discovered, I'd be incredibly grateful for your assistance.

Has anyone else experienced similar issues with L2TP/IPsec VPNs on the newer distributions? Is there something fundamental that changed in how these components interact in Debian 12 and Ubuntu 24.04 that might explain why existing configurations work but new ones fail?

Thank you in advance for any help or insights you can provide.

[dkosovic]

On Debian 12, could you do a diff (e.g. sudo diff -u filename1 filename2) between the following:

• /etc/NetworkManager/system-connections/pre-existing-profile.nmconnection
• /etc/NetworkManager/system-connections/new-profile.nmconnection

Or similarly on Ubuntu 24.04, a diff between /etc/netplan/90-NM-*.yaml files for the pre-existing-profile and new one.

Hopefully that might give a hint as to which settings are missing or have been added that are causing the issue.

[dkosovic]

A few other things I forgot to mention.

If you decide to manually modify one of those connection filles with a text editor, issue the following to let NetworkManager know to re-read the connection profiles from disk:
sudo nmcli con reload

Katalix go-l2tp kl2tpd is now the default L2TP daemon with network-manager-l2tp on Ubuntu 24.04 and later (if it can find kl2tpd, otherwise will fallback to xl2tpd). There is a compatibility bug between Ubuntu 24.04's kl2tpd and Meraki's really old Katalix OpenL2TP. See katalix/go-l2tp#6 . The issue was fixed with go-l2tp v 0.1.8. I have a PPA for newer go-l2tp, network-manager-l2tp and network-manager-l2tp-gnome packages which have a number of bug fixes:

• https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp

I'm guessing you are using xl2tpd instead of kl2tpd.

[dkosovic]

A few more things after clicking on the link to the guide you posted.

strongswan has 3 different IPsec daemons; charon, charon-systemd and charon-nm. The network-manager-l2tp package uses charon, while network-manager-strongswan uses strongswan-nm (which has charon-nm). Not that it matters, there is no need to explicitly install network-manager-strongswan or strongswan-nm packages as the package that is used is strongswan-charon.

network-manager-l2tp >= 1.2.16 use a merge of the macOS and Win10/11 L2TP/IPsec clients' phase 1 & 2 algorithm proposals, instead of the default strongswan proposals with earlier versions. So, you shouldn't need to explicitly enter anything in the phase 1 & 2 algorithm boxes, in fact I would recommend not entering anything as it will try to use stronger algorithms first. But, if you explicitly only want to use those proposals in the guide that are now considered weak or broken, put an exclamation mark ('!`) at the end of the proposals (when using strongswan instead of libreswan), e.g.:

• phase 1 algorithms : 3des-sha1-modp1024!
• phase 2 algorithms : 3des-sha1!

strongswan uses the original FreeS/WAN syntax where the exclamation mark ('!`) tells strongswan not to append to the existing proposals, instead it overrides them. Libreswan on the other hand has dropped the exclamation mark syntax. Not using the exclamation mark with strongswan is known to break some Meraki running older firmware.

To work out what actually is going wrong, I recommend looking at the following output:
sudo journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd

[Lonniebiz]

@dkosovic Thank you for your detailed responses. I appreciate your expertise on this matter and will need some time to thoroughly address your other comments.

In the meantime, I wanted to share an interesting development: Meraki Support actually directed me to this link:
https://www.linux.org/threads/help-connecting-to-l2tp-vpn-in-linux-debian-12.53466/

Remarkably, this leads to one of your own forum discussions where you helped another user! In that thread, you resolved their issue by having them disable Perfect Forward Secrecy (PFS).

Following this suggestion, I attempted to implement the same fix in Ubuntu 24.04.2 using the configuration approach from the Meraki guide. Initially, while the "Disable PFS" checkbox was visible in the interface, it was grayed out and I couldn't interact with it.

To address this, I installed the libreswan package and restarted Network-Manager, which did make the checkbox interactive. However, after checking "Disable PFS," applying the setting, and restarting Network-Manager again, my previously functioning VPN profile (originally created in Ubuntu 22.04 and carried over through upgrade to 24.04.2) actually stopped working entirely.

I was only able to restore functionality by uninstalling libreswan and restarting Network-Manager. While your suggestion successfully helped the Fedora user in that thread, I couldn't replicate those results in Ubuntu 24.04.2.

I'll follow up on your other points as soon as I can provide a proper response. Thank you for your continued assistance with this issue.

[dkosovic]

For historical reasons, Fedora/RHEL defaults to libreswan and Debian/Ubuntu to strongswan.

With newer Ubuntu/Debian libreswan packages (and soon also with Fedora 42 libreswan), you need to enable IPSEC IKE v1 support, see README.md file :

• https://github.com/nm-l2tp/NetworkManager-l2tp?tab=readme-ov-file

Also, Libreswan >= 3.30 is no longer built with DH2 (modp1024) support by default as the libreswan developers consider it broken, so VPN connection will fail if the Meraki is only proposing the weak 3des-sha1-modp1024 proposal, but pretty confident your Meraki is configured to propose stronger algorithms along with that weak one. Libreswan will complain about a modp1024 syntax error if you supply 3des-sha1-modp1024 for the phase 1 algorithm like in that guide.

According to the following strongswan docs, with strongswan >= 5.0 (released a decade ago), the pfs parameter has no effect anymore. So corresponding PFS option in GUI is grayed out (if PFS is needed with strongswan, it can be specified as part of the phase 2 algorithms instead).

• https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

[Lonniebiz]

I've discovered additional important information about this regression. The situation has unexpectedly improved on some systems:

1. On Debian 12 systems upgraded from Debian 11, I can now successfully create new VPN profiles using the guide steps
2. On fresh Debian 12 installations with GNOME in a VM, the VPN setup also now works correctly
3. On Ubuntu 24.04 upgraded from 22.04, the VPN setup works as expected

Note: I did not make any changes to these systems beyond routine updates (apt update/upgrade). This unexpected improvement suggests that either recent package updates fixed some issues OR Meraki may have made changes on their end after I filed a support case with them. I want to be clear that my initial reports were accurate - these systems weren't working before, but are now.

However, fresh installations of Ubuntu 24.04.2 still fail to connect properly. I've captured detailed logs of the connection attempt that pinpoint the exact failure:

level=debug tunnel_name=t1 function=transport message=recv message_type=avpMsgTypeSli
level=error tunnel_name=t1 message="bad control message" message_type=avpMsgTypeSli error="no specification for v2 message avpMsgTypeSli"

The connection process shows:

1. The IPsec tunnel establishes successfully
2. The L2TP tunnel starts to establish
3. Then there's a failure when receiving a "Set Link Info" (SLI) message from the Meraki server
4. The local L2TP client doesn't understand this message type and disconnects

This appears to be a compatibility issue between the L2TP implementation in fresh Ubuntu 24.04.2 and the Meraki MX firewall. Interestingly, this same issue does not occur on fresh Debian 12 installs or on systems upgraded from previous versions.

Also, @dkosovic, I want to mention that I've learned the Phase 1 and Phase 2 algorithm specifications are completely unnecessary on the systems that work correctly. The connection establishes successfully whether I include them or not, which saves significant time during setup. However, even when omitting these steps on the fresh Ubuntu 24.04.2 install, the connection still fails with the same error.

I appreciate your help in identifying which parts of the guide can be streamlined. If there are other unnecessary packages or configuration steps in the guide that could be eliminated for a more efficient setup process, that would be valuable information as well.

This specific error suggests that:

1. The L2TP protocol implementation may have changed in Ubuntu 24.04.2
2. There might be a version mismatch between packages in fresh vs. upgraded installations
3. Some configuration file or setting that handles these message types properly might be preserved during upgrades but not set correctly in fresh installations

Since fresh Debian 12 installations are now working, this narrows down the issue specifically to Ubuntu 24.04.2 fresh installations, which should help in identifying and resolving the regression.

[dkosovic]

Debian stable won't come with go-l2tp's kl2tpd until Debian 13. Debian Sid has the newer go-l2tp package with the fix, as do Ubuntu versions > 24.04.

It's ironic Ubuntu 24.04's kl2tpd cannot handle the SLI message from Meraki's OpenL2TP even though both were developed by Katalix, but they did fix the issue with newer go-l2tp package.

A workaround for Ubuntu 24.04 is to use my nm-l2tp PPA repository which has a newer go-l2tp package (it also has newer network-manager-l2tp packages):

• https://launchpad.net/~nm-l2tp/+archive/ubuntu/network-manager-l2tp

i.e. issue the following:

sudo add-apt-repository ppa:nm-l2tp/network-manager-l2tp
sudo apt update
sudo apt upgrade golang-github-katalix-go-l2tp  network-manager-l2tp  network-manager-l2tp-gnome

Would probably recommend sudo apt upgrade instead of the last line in order to upgrade all packages, but the above upgrade should suffice to fix your issue.

I could never get sponsors for the Ubuntu Backports repository, so have been using the aforementioned PPA repository instead to provide newer packages with additional features and/or bug fixes.

Yeah, definitely recommend not filling in the phase 1 & 2 algorithms for 99% of the VPN connections.

[Lonniebiz]

I'm happy to confirm that upgrading these packages (alone) from your repository completely fixes the issue that was preventing a freshly installed Ubuntu 24.04.2 from being a successful Meraki VPN client:

1. network-manager-l2tp
2. network-manager-l2tp-gnome

Command used:
sudo add-apt-repository ppa:nm-l2tp/network-manager-l2tp && sudo apt update && sudo apt install network-manager-l2tp network-manager-l2tp-gnome

I noticed the golang-github-katalix-go-l2tp package wasn't installed on my system when I tried to update it:
E: Unable to locate package golang-github-katalix-go-l2tp

The issue is already fixed without it, but I don't mind installing it if you recommend it to prevent potential future problems.

Would you consider working with the Ubuntu maintainers to get these fixes into the main Ubuntu 24.04.2 repositories? This would help many users who might encounter this issue but aren't aware of your PPA.

Do you have a PayPal link or similar? I'd like to show my appreciation for your help with this issue. Without your guidance, I would never have been able to resolve this problem. I'm sure other users who benefit from your work would appreciate a way to contribute as well.

Thank you again for being such a dedicated maintainer of these essential open source projects.

[dkosovic]

I often get confused by the Debian/Ubuntu Go Language package naming convention. In this case the source package name is the long-winded golang-github-katalix-go-l2tp but the binary package name is just go-l2tp. So, it should have been sudo apt upgrade go-l2tp.

I suspect the new go-l2tp 0.1.8-1 package got automatically upgraded as I would have added an explicit go-l2tp >= 0.1.8 dependency to the network-manager-l2tp package in that PPA.

The other workaround I forgot to mention is that xl2tpd could have been used instead of kl2tpd for Meraki devices, e.g.:

sudo apt install xl2tpd
sudo apt purge go-l2tp

go-l2tp is much more actively maintained than xl2tpd, it is also from the same authors that wrote the L2TP Linux kernel modules that xl2tpd and kl2tpd use.

I'm not the Debian Maintainer (DM) of the golang-github-katalix-go-l2tp source package. I just took the latest source package from Debian Sid and uploaded it to my PPA to build for Ubuntu 24.04.

I previously tried to submit a newer network-manager-l2tp to the official Ubuntu Backports repository, by first submitting a Launchpad bug report using the BPO Bug Template and providing BPO packages. On my nm-l2tp PPA page I previously wrote a message that this PPA is temporary, and provided a link to the backports bug report and wrote I needed Ubuntu users to click on the bug heat icon to increase the points, the more points the more likely I would get a sponsor to have the package added to the official Ubuntu Backports repository. The bug report languished on Launchpad for 1.5 years before I closed it after only receiving 6 user clicks. Would need a lot more clicks than that to get the attention of an Ubuntu sponsor. Guess I could have been more proactive in contacting a sponsor by others means, but content now in just using the PPA. You need a lot more than 6 users for Ubuntu Backports process to progress, unlike the Ubuntu Updates repository which has patches to existing packages.

To get the existing go-l2tp 0.1.7-1ubuntu0.1 package fixed, the following patches will need to be added to the source package:

• https://github.com/katalix/go-l2tp/commit/628104d956cb83ee9b9dd4dd50a9a18962c7639f.patch
• https://github.com/katalix/go-l2tp/commit/5720acff49c0deda96b132c21c7431ae5300a56a.patch
• https://github.com/katalix/go-l2tp/commit/8550c3a9c6ed0f64f89f096942d11df3040ee2d1.patch
• https://github.com/katalix/go-l2tp/commit/6404a134f8e4c8e6057ba79cc37349711d492d06.patch

Not sure if all 4 of the above patches are required for your avpMsgTypeSli issue, but they are all the differences between 0.1.7 and 0.1.8.

Will require a Meraki user to submit an Ubuntu Launchpad bug report with the issue, then have at least 2 other users confirm in Launchpad that it is a bug and maybe have them add a few comments.

Then a SRU (i.e. StableReleaseUpdates) request process can commence that fixes that bug, see process here:

• https://documentation.ubuntu.com/sru/en/latest/howto/
  I could provide a debdiff file and submit an SRU bug report in launchpad which involves getting a sponsor:
• https://wiki.ubuntu.com/SponsorshipProcess

For the SRU bug report, it helps immensely with getting a sponsor if at least 2 Meraki users respond to that bug report and confirm the SRU package fixes the bug.

Thanks for the donation offer, its fine, no need, but I appreciate it.

[Lonniebiz]

Ubuntu Bug Report:
https://bugs.launchpad.net/ubuntu/+source/network-manager-l2tp/+bug/2107270

[dkosovic]

I can't get to that bug report, but there is an existing go-l2tp missing avpMsgTypeSli message_type bug report :

• https://bugs.launchpad.net/ubuntu/+source/golang-github-katalix-go-l2tp/+bug/2068687

I might use that one instead for the SRU request.

[Lonniebiz]

@dkosovic I changed that bug report's access from private to public. Everyone should be able to see it now.

[dkosovic]

Sorry I never completed the Ubuntu Stable Release Updates (SRU) request for a newer go-l2tp package which contains the fix.

I did do up a SRU package back in April that I was going to submit:

• https://launchpad.net/~dkosovic/+archive/ubuntu/go-l2tp-sru

then got sick, went on holiday, came back and didn't have luck finding a sponsor.

Sorry, not sure how to proceed or have time. I might leave it for someone else to try and get the newer go-l2tp package into Ubuntu 24.04.