Red Hat Bugzilla – Bug 441714
Racoon fails to create loopback SAs using existing SPD configuration
Last modified: 2010-10-22 19:53:57 EDT
Description of problem: Using the attached configuration it was possible to create to create loopback SAs with the LSPP evaluated release of RHEL5. However, using the RHEL5.2 snapshot 3 it is no longer possible using the existing configuration. The problem appears to be related to the ipsec-tools-0.6.5-loopback.patch which was included to address BZ 218386. It appears that this patch hardcodes certain loopback SA attributes and no longer honors the user specified configuration which appears to be causing the problem. There does not appear to be any documentation in the racoon or setkey man pages to indicate what the correct configuration would be to allow loopback SAs. Version-Release number of selected component (if applicable): ipsec-tools-0.6.5-8.el5 How reproducible: Everytime Steps to Reproduce: 0. Install a RHEL5.2 snapshot 3 system using the HP LSPP configuration 1. Configure racoon with the supplied configuration, restart 2. Configure the kernel's SPD using the supplied configuration 3. Attempt 'ping -c 3 127.0.0.1' Actual results: Relevant snippet from syslog ... Apr 9 12:24:32 cert-i4 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=9) Apr 9 12:24:32 cert-i4 racoon: INFO: 127.0.0.1[500] used for NAT-T Apr 9 12:24:32 cert-i4 racoon: INFO: 16.116.90.34[500] used as isakmp port (fd=10) Apr 9 12:24:32 cert-i4 racoon: INFO: 16.116.90.34[500] used for NAT-T Apr 9 12:24:32 cert-i4 racoon: INFO: ::1[500] used as isakmp port (fd=11) Apr 9 12:24:32 cert-i4 racoon: INFO: fd7b:826d:f2:0:217:a4ff:fe99:adc1[500] used as isakmp port (fd=12) Apr 9 12:24:32 cert-i4 racoon: INFO: 2001:1890:1109:a01:217:a4ff:fe99:adc1 [500] used as isakmp port (fd=13) Apr 9 12:24:32 cert-i4 racoon: INFO: fe80::217:a4ff:fe99:adc1%eth0[500] used as isakmp port (fd=14) Apr 9 12:24:38 cert-i4 racoon: INFO: security context doi: 1 Apr 9 12:24:38 cert-i4 racoon: INFO: security context algorithm: 1 Apr 9 12:24:38 cert-i4 racoon: INFO: security context length: 51 Apr 9 12:24:38 cert-i4 racoon: INFO: security context: staff_u:lspp_test_r:lspp_harness_t:s0-s15:c0.c1023 Apr 9 12:24:38 cert-i4 racoon: ERROR: pfkey UPDATE failed: No such file or directory Expected results: No errors in syslog and a usable IPsec SA. Additional info: This can be considered a regression against the RHEL5 LSPP evaluation. Documentation may make this less of an issue but none appears to exist in the usual places (man pages).
Created attachment 301847 [details] Racoon configuration [/etc/racoon/racoon.conf]
Created attachment 301848 [details] SPD entries [setkey -f setkey.loopback]
I will try and take a look at this during the weekend or Monday.
I can confirm the loopback ipsec failures on RH5.2. We are also seeing very serious loopback/local IP SA creation issues on rawhide. Some loopback/local IP SA creations are fast, some take minutes. The machine is idle during the wait, so it looks like some sort of race condition.
Created attachment 303871 [details] Working racoon.conf for rawhide The attached racoon.conf works in rawhide. 192.168.20.101 is the IP address of eth0. If hmac_sha1 is changed to non_auth in the two ip specific sainfo clauses, no associations form. Loopback SA creation performance is poor.
The configuration above generates 2 SAs for each unique type/context. One is unused (by byte count).
Joe, what version of ipsec-tools do you have when it works? The version of ipsec-tools in rhel5u2 appears to the be same version we included in our evaluation (updated from rhel5) so now I'm confused about what's different. Have you been using the rhel5 version (0.6.5-6) or the one we evaluated (0.6.5-8)?
I tried this in RHEL5.2 snap6, IBM LSPP config and it worked ok with Paul's ipsec config files. The version of racoon is ipsec-tools-0.6.5-9.el5. Paul, I am investigating the error message you got... according to the code, the kernel failed to update the SA and sent an ENOENT... but I am baffled as to where the ENOENT came from when doing an update so I need to look some more at kernel code. I think the racoon code is the same from when I first added the change for LSPP. I had hard-coded the attributes since it was a late patch and wanted to clean it up but just never got the time.
Joe, were you seeing the same problems in RHEL5.0?
This is odd since the userspace code should be exactly the same...
Joy, I'm puzzled by that too. Is there any difference in the kernel code? Sounds like the attributes are still hard-coded in the user-space code? I haven't looked at the latest snap but snap3 has 0.6.5-8 so what's new in -9?
RHEL5.0 and 5.1 were fine. This is from a 5.1 VM: [root@laptop ~]# !setk setkey -D | grep context: security context: system_u:system_r:jcdx_qp_t:s0-s15:c0.c1023 security context: system_u:system_r:inetd_t:s0-s15:c0.c1023 security context: system_u:system_r:jcdx_qc_t:s15:c0.c1023 security context: system_u:system_r:jcdx_qm_t:s0-s15:c0.c1023 security context: system_u:system_r:jcdx_qs_t:s0-s15:c0.c1023 security context: system_u:system_r:jcdx_qalertd_t:s15:c0.c1023 security context: system_u:system_r:jcdx_ebee_t:s5:c0.c511 security context: system_u:system_r:jcdx_ebe_t:s5:c0.c511 security context: system_u:system_r:jcdx_procmon_db_t:s15:c0.c1023 security context: system_u:system_r:jcdx_cen_mon_t:s15:c0.c1023 security context: system_u:system_r:jcdx_procmon_alerts_t:s15:c0.c1023 security context: system_u:system_r:jcdx_qm_t:s15:c0.c1023 security context: system_u:system_r:jcdx_uniquenum_t:s5:c0.c511 security context: system_u:system_r:jcdx_hta_t:s5:c0.c511 security context: system_u:system_r:jcdx_dirchan_t:s5:c0.c511 security context: system_u:system_r:jcdx_jetsindex_t:s5:c0.c511 security context: system_u:system_r:jcdx_ped_t:s0-s5:c0.c511 security context: system_u:system_r:jcdx_imf_t:s5:c0.c511 security context: system_u:system_r:jcdx_ocm_t:s5:c0.c511 security context: system_u:system_r:jcdx_olog_t:s5:c0.c511 security context: system_u:system_r:jcdx_qp_t:s15:c0.c1023 security context: system_u:system_r:jcdx_icm_t:s5:c0.c511 security context: system_u:system_r:jcdx_ilog_t:s5:c0.c511 security context: system_u:system_r:inetd_t:s15:c0.c1023 security context: system_u:system_r:jcdx_qs_t:s15:c0.c1023 security context: system_u:system_r:jcdx_tagd_t:s5:c0.c511 security context: system_u:system_r:jcdx_tdbm_t:s5:c0.c511 security context: system_u:system_r:jcdx_tagd_t:s0-s5:c0.c511 security context: system_u:object_r:jcdx_mtdb_t:s0-s5:c0.c511 security context: system_u:system_r:jcdx_tdbm_t:s5:c0.c511 security context: system_u:system_r:ntpd_t:s0-s15:c0.c1023 security context: system_u:system_r:sshd_t:s0-s15:c0.c1023 [root@laptop ~]# setkey -D | grep context: | wc -l 32 [root@laptop ~]# rpm -q ipsec-tools ipsec-tools-0.6.5-8.el5 [root@laptop ~]# rpm -q kernel Note the 1 SA per type/level.
rpm -q kernel for above kernel-2.6.18-53.1.14.el5
[root@xw4100 ~]# more /etc/redhat-release Red Hat Enterprise Linux Client release 5.2 Beta (Tikanga) [root@xw4100 ~]# setkey -D 127.0.0.1 127.0.0.1 esp mode=transport spi=66680689(0x03f97771) reqid=0(0x00000000) seq=0x00000000 replay=0 flags=0x00000000 state=larval created: Apr 28 18:35:13 2008 current: Apr 28 18:35:35 2008 diff: 22(s) hard: 30(s) soft: 0(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 0(bytes) soft: 0(bytes) allocated: 0 hard: 0 soft: 0 security context doi: 1 security context algorithm: 1 security context length: 49 security context: system_u:system_r:jcdx_talertd_t:s0-s15:c0.c1023 sadb_seq=0 pid=11517 refcnt=0 [root@xw4100 ~]# rpm -q ipsec-tools ipsec-tools-0.6.5-8.el5 [root@xw4100 ~]# rpm -q kernel kernel-2.6.18-84.el5
This seems like a regression in kernel as evident from comments #15, #16, and #17. The difference between RHEL-5 ipsec-tools version and current Fedora (rawhide) is that the loopback patch in current RHEL-5 ipsec-tools automatically creates the loopback SAs without the full ISAKMP negotiation. The rawhide patch just allows to complete the regular negotiation of the racoon with itself. But I wouldn't be surprised that the rawhide approach is racy.
Have you been able to duplicate the problem?
I am trying to reproduce the problem just now and unfortunately I was not able to reproduce it on the RHEL-5.2 kernel: Linux 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 I will port the loopback patch from RHEL-5 to rawhide ipsec-tools version to try it there.
Updating PM score.
Reporter, are you still able to reproduce the problem with 5.3 kernel & ipsec-tools versions?
Not immediately. I'll have to build a RH5.3 system. We've been using Fedora 10 lately.
Unfortunately I was not able to reproduce the problem and I do not have enough necessary information to do so and fix the bug.