Bug 1342841

hmm, looks like the error happens in the NSS library.

Is this system running in FIPS mode?

> Is this system running in FIPS mode?

not really: 

# cat /proc/sys/crypto/fips_enabled
0

> looks like the error happens in the NSS library.

yes, libfreeblpriv3.so is a part of nss-softokn-freebl package - especially of nss-softokn-freebl-3.14.3-23.el6_7.i686 in my system. and this package version wasn't upgraded during last system upgrade to RHEL 6.8. thus I opened bugreport libreswan.

perhaps the nss migration is not happening properly?

Can you try:

- stop ipsec service
- upgrade packege
- run ipsec checknss
- start ipsec service

and tell me if the problem is still happening?

seems your steps working. I tested it on UAT:

# ipsec checknss
Migrating NSS db to sql:/etc/ipsec.d
database already upgraded.
NSS upgrade complete

# /etc/init.d/ipsec start
Starting pluto IKE daemon for IPsec: .                     [  OK  ]

from /var/log/messages:
Jun  7 21:58:25 vpnc2 kernel: : padlock: VIA PadLock not detected.
Jun  7 21:58:25 vpnc2 kernel: : padlock: VIA PadLock Hash Engine not detected.
Jun  7 21:58:25 vpnc2 kernel: : Intel AES-NI instructions are not detected.
Jun  7 21:58:25 vpnc2 kernel: : Intel AES-NI instructions are not detected.
Jun  7 21:58:25 vpnc2 kernel: : padlock: VIA PadLock not detected.
Jun  7 21:58:25 vpnc2 kernel: : sha512_ssse3: Neither AVX nor SSSE3 is available/usable.
Jun  7 21:58:25 vpnc2 kernel: : sha256_ssse3: Neither AVX nor SSSE3 is available/usable.
Jun  7 21:58:25 vpnc2 kernel: : Intel AES-NI instructions are not detected.
Jun  7 21:58:25 vpnc2 kernel: : Intel PCLMULQDQ-NI instructions are not detected.
Jun  7 21:58:25 vpnc2 kernel: : sha256_ssse3: Neither AVX nor SSSE3 is available/usable.
Jun  7 21:58:25 vpnc2 kernel: : sha512_ssse3: Neither AVX nor SSSE3 is available/usable.

this night I will do the same on production VPN Box and let you know.

thank you!

if it said "already upgraded" then it means it did not do anything though.....

If you are re-testing this bug, note that starting the ipsec service normally should cause the nss db to be converted from dbm to sqlite. You can tell by the filenames. key3.db and cert8.db are the old ones and key4.db and cert9.db are the new ones. So for proper testing, if you now have key4/cert9 files, you should remove those as those are the converted ones.

seems I get different results between systems PROD (vpnc1) and TEST/BACKUP (vpnc2). On TEST daemon starts correctly without any additional step except upgrade itself. 
On PROD, with same package versions, same config, I get: 

pluto[21205] trap invalid opcode ip:7f0159103d60 sp:7fff53dd6678 error:0 in libfreeblpriv3.so[7f01590b1000+72000]


but now I found this: https://bugs.centos.org/view.php?id=10930

seems there is similar report for "libfreeblpriv3.so". and issue is reproducible on systems running on Xen hypervisor. and this is exactly my case:

PROD (vpnc1) is running on Xenserver, but TEST system is running on Proxmox which is based on KVM. and thats why I get different results, even if they both share completely same /etc/ipsec.d/ folder and other related files.

Can you try and add

Environment=NSS_DISABLE_HW_GCM=1

to the service file, by either adding it to /lib/systemd/system/ipsec.service or by copying that service file into /etc/systemd/system/ and then issue:

systemctl daemon-reload 
systemctl start ipsec.service

this might be rhbz#1249426

Sorry. rhel6 is still upstart/sysvinit. So:

Add following lines  file: /etc/sysconfig/ipsec

NSS_DISABLE_HW_GCM=1
export NSS_DISABLE_HW_GCM

yes, with this parameter, pluto started successfully with libreswan-3.15-5.3.el6.x86_64 on Xen-virtualized VM.

An nss update is scheduled that addresses this issue.

This was addressed in rhbz#1337821 with an nss package update

*** This bug has been marked as a duplicate of bug 1337821 ***