Douglas Kosovic

I've created NetworkManager-ssh 1.2.12 Fedora 36 RPMs built with this pull request applied as a patch and put them up on a COPR repository, see : * https://bugzilla.redhat.com/show_bug.cgi?id=2061693#c13

For the custom `ipsec.conf` file that gets generated, it is currently using `left=%defaultroute` : * https://github.com/nm-l2tp/NetworkManager-l2tp/blob/1.20.4/src/nm-l2tp-service.c#L948 according to https://wiki.strongswan.org/projects/strongswan/wiki/connsection : > Prior to 5.0.0, specifying `%any` for the local endpoint...

Running `ss` and `netstat` both confirm strongwan's charon daemon is listening on `0.0.0.0`, i.e. all interfaces for UDP port 500: ```sh $ sudo ss -tunlp | grep :500 udp UNCONN...

Most Linux distros include both strongswan and libreswan, on Ubuntu to switch to libreswan, just issue: ```sh sudo apt install libreswan ```

NetworkManager-strongswan uses a daemon called `charon-nm` which runs independently of the regular daemons `charon-systemd` or `charon` and to avoid conflicts, it doesn't use ports 500/udp and 4500/udp. `charon-nm` also uses...

I'll close this issue as there isn't much I can do with how strongswan listens on multiple interfaces for UDP port 500 with the custom ipsec.conf file that gets generated....

I'm assuming it was working for you before with an earlier version of Ubuntu, if so, the bug is probably NetworkManager 1.36 introducing a spurious route and in some cases...

I'll assume you were experiencing the aforementioned upstream NetworkManager 1.36 bug with spurious route and/or spurious IP address. I'll close this issue as there is not much I can do,...

I would try switching from strongswan to libreswan with : ``` sudo apt install libreswan ``` I would have thought it was a PSK issue if you didn't mention the...

Could you try clicking "Enforce UDP encapsulation" in the IPsec advanced options?