The ipsec.service provided by libreswan package version 3.32 does not start due to an error testing AES_GCM_16. It is worth mentioning that versions 3.27 and 3.29 work perfectly. (This is tested on Mageia 7, but version 3.32 is crashing on Mageia 7 as well) here is a snippet of the journal: # LC_ALL=c journalctl -eu ipsec Jun 02 21:46:37 mgaqa8 pluto[60887]: DH algorithms: Jun 02 21:46:37 mgaqa8 pluto[60887]: NONE IKEv1: IKEv2: IKE ESP AH FIPS null, dh0 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP1536 IKEv1: IKE ESP AH IKEv2: IKE ESP AH dh5 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP2048 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS dh14 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP3072 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS dh15 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP4096 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS dh16 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP6144 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS dh17 Jun 02 21:46:37 mgaqa8 pluto[60887]: MODP8192 IKEv1: IKE ESP AH IKEv2: IKE ESP AH FIPS dh18 Jun 02 21:46:37 mgaqa8 pluto[60887]: DH19 IKEv1: IKE IKEv2: IKE ESP AH FIPS ecp_256, ecp256 Jun 02 21:46:37 mgaqa8 pluto[60887]: DH20 IKEv1: IKE IKEv2: IKE ESP AH FIPS ecp_384, ecp384 Jun 02 21:46:37 mgaqa8 pluto[60887]: DH21 IKEv1: IKE IKEv2: IKE ESP AH FIPS ecp_521, ecp521 Jun 02 21:46:37 mgaqa8 pluto[60887]: DH31 IKEv1: IKE IKEv2: IKE ESP AH curve25519 Jun 02 21:46:37 mgaqa8 pluto[60887]: testing CAMELLIA_CBC: Jun 02 21:46:37 mgaqa8 pluto[60887]: Camellia: 16 bytes with 128-bit key Jun 02 21:46:37 mgaqa8 pluto[60887]: Camellia: 16 bytes with 128-bit key Jun 02 21:46:37 mgaqa8 pluto[60887]: Camellia: 16 bytes with 256-bit key Jun 02 21:46:37 mgaqa8 pluto[60887]: Camellia: 16 bytes with 256-bit key Jun 02 21:46:37 mgaqa8 pluto[60887]: testing AES_GCM_16: Jun 02 21:46:37 mgaqa8 pluto[60887]: empty string Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD decryption using AES_GCM_16_128 and PK11_Decrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD encryption using AES_GCM_16_128 and PK11_Encrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: one block Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD decryption using AES_GCM_16_128 and PK11_Decrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD encryption using AES_GCM_16_128 and PK11_Encrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: two blocks Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD decryption using AES_GCM_16_128 and PK11_Decrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD encryption using AES_GCM_16_128 and PK11_Encrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: two blocks with associated data Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD decryption using AES_GCM_16_128 and PK11_Decrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: NSS: AEAD encryption using AES_GCM_16_128 and PK11_Encrypt() failed (SECERR: 2 (0x2): security library: receiv> Jun 02 21:46:37 mgaqa8 pluto[60887]: ABORT: ASSERTION FAILED: test_gcm_vectors(&ike_alg_encrypt_aes_gcm_16, aes_gcm_tests) (in test_ike_alg() at ik> Jun 02 21:46:37 mgaqa8 systemd[1]: ipsec.service: Failed with result 'core-dump'. Jun 02 21:46:37 mgaqa8 systemd[1]: Failed to start Internet Key Exchange (IKE) Protocol Daemon for IPsec. Jun 02 21:46:37 mgaqa8 systemd[1]: ipsec.service: Scheduled restart job, restart counter is at 5. Jun 02 21:46:37 mgaqa8 systemd[1]: Stopped Internet Key Exchange (IKE) Protocol Daemon for IPsec. Jun 02 21:46:37 mgaqa8 systemd[1]: ipsec.service: Start request repeated too quickly. Jun 02 21:46:37 mgaqa8 systemd[1]: ipsec.service: Failed with result 'core-dump'. Jun 02 21:46:37 mgaqa8 systemd[1]: Failed to start Internet Key Exchange (IKE) Protocol Daemon for IPsec.
Summary: ipsec.service would not start => ipsec.service would not start due to security error
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) => MGA7TOOSummary: 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.52Assignee: 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) => luigiwalserWhiteboard: MGA7TOO => (none)Assignee: smelror => qa-bugsVersion: 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.viaeneWhiteboard: (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-bugsKeywords: (none) => validated_update
Advisory pushed to SVN.
Keywords: (none) => advisory
Source RPM: libreswan-3.32-1.mga8.src.rpm => libreswan-3.32-1.mga7.src.rpm
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2020-0220.html
Status: NEW => RESOLVEDResolution: (none) => FIXED