Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#74553 - [strongswan] 5.9.5-1 broken with networkmanager >= 1.36

Attached to Project: Community Packages
Opened by Douglas Kosovic (dkosovic) - Monday, 25 April 2022, 02:09 GMT
Last edited by David Thurstenson (thurstylark) - Wednesday, 27 April 2022, 22:39 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Christian Rebischke (Shibumi)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 2
Private No


Description: L2TP/IPsec connection no longer works with networkmanager 1.36

Additional info:
* package version: 5.9.5-1 and earlier
* link to upstream bug report:

see networkmanager-l2tp bug report :

Table of strongswan plugins which lists which ones are experimental :

Arch Linux seems to enable/load a lot more strongswan plugins compared to other Linux distributions, and some of these plugins are now causing problems with networkmanager >= 1.36, especially the experimental plugins that deal with routing like bypass-lan and forecast.

I would recommend not loading plugins that are known to have problems by default. If anybody needs to use them, they can explicitly load the plugin by editing the corresponding config file.

Can the package() section of the strongswan PKGBUILD file have something like the following added (it is based on what Fedora strongswan package doesn't enable or load) :

# do not load certain plugins by default that are known to have problems
for p in bypass-lan connmark forecast sha3; do
sed -i 's/load = yes/load = no/' "${pkgdir}/etc/strongswan.d/charon/${p}.conf"

This task depends upon

Comment by Douglas Kosovic (dkosovic) - Wednesday, 11 May 2022, 11:08 GMT
I totally forgot with this strongswan broken plugins issue, I had to enable the "Use this connection only for resources on its network" checkbox in the VPN connection's IPv4 settings (which corresponds to the ipv4.never-default setting) to reproduce the issue. strongswan works fine if I don't enable that checkbox.

I was surprised when someone else wasn't able to reproduce the issue and then took another look...