Bug 26716

This link might help:

https://aur.tuna.tsinghua.edu.cn/packages/libreswan/


Apparently NSS is the culprit, even though I have not digged deep into it :]

Quoting:

Compile with nss 3.51 then you can immediately upgrade to nss 3.52. The nss 3.52 headers are the problem. nss 3.51 headers work for nss 3.52.

Thank you Muhammad for the report, and the background information.
I hope you have downgraded 'libreswan' to carry on with.

Assigning to Stig for libreswan.

Whiteboard: (none) => MGA7TOO
Summary: ipsec.service would not start due to security error => ipsec.service would not start due to security error with libreswan 3.32 which is upset by nss 3.52
Assignee: bugsquad => smelror

This may be an upstream issue.

Have you checked there and/or submitted a bug report?

https://github.com/libreswan/libreswan

Cheers,
Stig

(In reply to Lewis Smith from comment #2)
> Thank you Muhammad for the report, and the background information.
> I hope you have downgraded 'libreswan' to carry on with.
> 
Thank you actually;

Yes I already did..the company cannot go without VPN ;)

(In reply to Stig-Ørjan Smelror from comment #3)
> This may be an upstream issue.
> 
> Have you checked there and/or submitted a bug report?
> 
> https://github.com/libreswan/libreswan
> 

Unfortunately I had not the chance because of the work-load. :( sorry

I might check it later

Hello,
There is indeed a report: https://github.com/libreswan/libreswan/issues/334
which point to a patch: https://github.com/libreswan/libreswan/commit/db7715407efa43cd2a66caed67c02d8f7bb90b35

CC: (none) => yves.brungard_mageia

Hello everyone,

I HAD same issue, but I solved by downloading libreswan 3.32 from their website and add it to the package.

wget https://download.libreswan.org/libreswan-3.32.tar.gz



Issue is that current libreswan of mga7 (even is called libreswan3.32 - still has 3.27 libreswan) 
So I changed .tgz file from SOURCES and edited a bit the .spec file


[root@mga7-test][~/rpmbuild/SOURCES]# ls
ikev1_dsa.fax.bz2  ikev1_psk.fax.bz2  ikev2.fax.bz2  libreswan-3.27-package/  libreswan-3.27-package.tar.gz  libreswan-3.32.tar.gz  libreswan-tmpfiles.conf
[root@mga7-test][~/rpmbuild/SOURCES]#

new package can be found on: https://repo.yate.ro/mageia/updates/mga7/x86_64/libreswan-3.32-2.mga7.x86_64.rpm

also the .src file is there - is someone else needs it.

CC: (none) => servere

[root@mga7-test][~/rpmbuild/SPECS]# diff libreswan.spec libreswan32.spec
28c28
< %define rel 4
---
> %define rel 2
33c33
< Version: 3.27
---
> Version: 3.32
200a201,203
> * Fri Jul 17 2020 afkpaul <paul@afk.ro> 3.32-1.mga7
> + upgrade to Libreswan 3.32
> 
[root@mga7-test][~/rpmbuild/SPECS]# cd ../SOURCES/
[root@mga7-test][~/rpmbuild/SOURCES]# wget https://download.libreswan.org/libreswan-3.32.tar.gz

What Paul posted doesn't make sense, as we already have 3.32, but perhaps it means a fresh build is enough to fix it.  Probably wouldn't hurt to add the patch from Comment 6 though.

(In reply to David Walser from comment #9)
> What Paul posted doesn't make sense, as we already have 3.32, but perhaps it
> means a fresh build is enough to fix it.  Probably wouldn't hurt to add the
> patch from Comment 6 though.

I actually downloaded the source RPM from a Mageia mirror and rebuilt it locally. I installed it and everything works fine.

Thank you all :)

I am not marking this bug as resolved, though, because the binary RPM of Mageia still does not work!! :(

Advisory:
----------------------------------------

Due to an incompatibility with updated nss versions, libreswan stopped working.

The libreswan package has been patched and rebuilt to fix this issue.

References:
https://github.com/libreswan/libreswan/issues/334
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
libreswan-3.32-1.1.mga7

from libreswan-3.32-1.1.mga7.src.rpm

CC: (none) => luigiwalser
Whiteboard: MGA7TOO => (none)
Assignee: smelror => qa-bugs
Version: Cauldron => 7

MGA7-64 Plasma on Lenovo B50
No installation issues.
After installation, at CLI:
# systemctl start ipsec
[root@mach5 ~]# systemctl -l status ipsec
● ipsec.service - Internet Key Exchange (IKE) Protocol Daemon for IPsec
   Loaded: loaded (/usr/lib/systemd/system/ipsec.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2020-10-14 16:19:05 CEST; 33s ago
     Docs: man:ipsec(8)
           man:pluto(8)
           man:ipsec.conf(5)
  Process: 22571 ExecStartPre=/usr/libexec/ipsec/addconn --config /etc/ipsec.conf --checkconfig (code=exited, status=0/SUCCESS)
  Process: 22573 ExecStartPre=/usr/libexec/ipsec/_stackmanager start (code=exited, status=0/SUCCESS)
  Process: 22938 ExecStartPre=/usr/sbin/ipsec --checknss (code=exited, status=0/SUCCESS)
  Process: 22957 ExecStartPre=/usr/sbin/ipsec --checknflog (code=exited, status=0/SUCCESS)
 Main PID: 22968 (pluto)
   Status: "Startup completed."
    Tasks: 4 (limit: 4915)
   Memory: 6.0M
   CGroup: /system.slice/ipsec.service
           └─22968 /usr/libexec/ipsec/pluto --leak-detective --config /etc/ipsec.conf --nofork

Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: watchdog: sending probes every 100 secs
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: listening for IKE messages
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: Kernel supports NIC esp-hw-offload
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: adding interface wlp9s0/wlp9s0 (esp-hw-offload not supported by kernel) 192.168.2.5:500
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: adding interface wlp9s0/wlp9s0 192.168.2.5:4500
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: adding interface lo/lo (esp-hw-offload not supported by kernel) 127.0.0.1:500
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: adding interface lo/lo 127.0.0.1:4500
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: adding interface lo/lo (esp-hw-offload not supported by kernel) [::1]:500
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: loading secrets from "/etc/ipsec.secrets"
Oct 14 16:19:05 mach5.hviaene.thuis pluto[22968]: no secrets filename matched "/etc/ipsec.d/*.secrets"

Looks OK if I understand the problem correctly.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA7-64-OK

It would be better to confirm that clients can actually connect, get an ip and can ping or reach the machine at least.

The fact that the ipsec service starts is no indication on the correct functionality of the service.

I'll try to test it later.

Status of this testing?

CC: (none) => ouaurelien

Validating based on above testing.

CC: (none) => davidwhodgins, sysadmin-bugs
Keywords: (none) => validated_update

Advisory pushed to SVN.

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2020-0220.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED