I've been asked to migrate from CentOS 6.8 to 7.4 on all of our Linux devices. I'm running into an issue with loading Security Associations into the Linux kernel. I'm using ipsec-tools' implementation of setkey to do this. Originally in CentOS 6.8 this worked fine with the key and algorithm defined (3des-cbc 192-bit key) in out setkey.conf file. I could enter "setkey -D" and see the SA listed there.

In CentOS 7.4 it fails to load the SA. In both cases I have the "fips=1" parameter set in the Grub command line statement at bootup which is supposed to force FIPS compliance. I've found that if I remove the "fips=1" parameter in the grub command line statement on my box running CentOS 7.4 then it will successfully load the SA. This causes me to think that FIPS compliance has changed between CentOS 6.8 and CentOS 7.4 and that 3des-cbc is no longer an approved algorithm.

I've attempted to move away from using ipsec-tools' implementation of setkey and instead use ip xfrm to load it but I get the same results. I have not attempted to use openswan yet but I figure it attempts to accomplish the same thing by loading the SA into the kernel and; therefore, I expect to run into the same problem.

Here are further details:


  • CentOS 6.8
  • Kernel: 2.6.32-642.6.2.el6.x86_64
  • ipsec-tools 0.8.2-1
  • Grub command line statement includes fips=1

setkey.conf file contains:

# Flush the SAD and SPD

# ESP SAs using 192 bit long keys (168 + 24 parity)
add esp 0x201 -E 3des-cbc

# Security policies
spdadd [any] [1960] any -P in ipsec


  • CentOS 7.4
  • Kernel: 3.10.0-693.11.1.el7.x86_64
  • ipsec-tools 0.8.2-1
  • Grub command line statement includes fips=1
  • setkey.conf file is same as above.

In this configuration setkey -D returns an error saying: "No SAD Entries" If I attempt to read the setkey.conf file into the kernel with "setkey -f /etc/setkey.conf" then I get an error saying: "The result of line 10: (NULL)."

Is there a better way to load SAs into the Linux Kernel? Is 3des-cbc no longer considered FIPS compliant? Should we change to a different encryption algorithm that is FIPS compliant? If so, which algorithm is expected to remain compliant for the foreseeable future?


The lack of support in the RHEL/CentOS world of distros is intentional. Redhat decided to deprecate support for ipsec-tools and mentions this on their main pages for RHEL 6/7:

The ipsec-tools package was deprecated in favor of openswan. There is currently no active upstream development or maintenance for the ipsec-tools project.

NOTE: This applies to CentOS 6/7 as well.

I'd suggest making use of one of the *SWAN projects such as OpenSWAN, LibreSWAN, or StrongSWAN.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.