Description of problem: In ipsec-tools, pfkey_open() in libipsec/pfkey.c sets a 128K receive buffer size. This only allows about 600 SPD entries to be dumped without buffer overflow. Customer needs ipsec-tools to be able to handle ~9000 SPD entries (400 targets with 24 SPD entries per target), which corresponds to a buffer size of 2 MB. Version-Release number of selected component (if applicable): ipsec-tools 0.6.5-13.el5-13.1 How reproducible: 100% with enough SPD entries Additional info: Upstream code has a 1 MB buffer: http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/src/libipsec/pfkey.c?rev=1.15&content-type=text/x-cvsweb-markup Upstream patch is here: http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/dist/ipsec-tools/src/libipsec/pfkey.c.diff?r1=1.14&r2=1.15
Created attachment 426403 [details] Proposed patch Increased buffer size to 2 MB. Based on upstream patch mentioned in Description.
I do not like this change as this has the consequence of higher memory requirements in kernel. But I've found that upstream CVS already contains a different patch that allows setting the pfkey receive buffer size in the racoon configuration. I would like to add this patch. This bug should be proposed for 5.5.z so we can include the patch in the 5.5.z errata that is in the works.
Added a patch from upstream that allows to configure the pfkey socket buffer size. https://brewweb.devel.redhat.com//buildinfo?buildID=136057
Tom, I can't verify this bug-fix since I see no difference between old (ipsec-tools-0.6.5-13.el5_3.1) and new (ipsec-tools-0.6.5-14.el5_5.4) version. My testing environment is as follows: * two virtual machines (A and B) * PSK IPsec connection from A to B and vice versa via ifcg/ifup * racoon in configured with "pfkey_buffer 4000;" on both A and B * SPD rules are as follows: A (2 rules): flush; spdflush; spdadd 192.168.122.68/32 192.168.122.26/32 any -P out ipsec esp/transport//requ\ ire ; spdadd 192.168.122.26/32 192.168.122.68/32 any -P in ipsec esp/transport//requi\ re ; B (552 rules): flush; spdflush; spdadd 192.168.122.98/32 192.168.1.1/32 any -P out ipsec esp/tunnel/192.168.0.1\ [4500]-192.168.1.2[30000]/require ; ... (548 different tunnel rules) ... spdadd 192.168.122.98/32 192.168.2.253/32 any -P out ipsec esp/tunnel/192.168.0\ .1[4500]-192.168.1.2[30000]/require ; spdadd 192.168.122.26/32 192.168.122.68/32 any -P out ipsec esp/transport//requ\ ire ; spdadd 192.168.122.68/32 192.168.122.26/32 any -P in ipsec esp/transport//requi\ re ; Starting IPsec via ifup correctly starts racoon. On A all SPD rules are loaded, on B only first ~512 rules are loaded and the others are missing (especially two last and most important) and hence 'ping B' from A does not work since there are no matching rules on B. Moreover, if this fix is intended for racoon, it should also fix setkey, since both old and new version on B give me the following: # setkey -DP | grep any | wc -l recv: Resource temporarily unavailable 513 Is there something I missed? According to 'man racoon.conf' I should have allocated ~4MB for SPD rules (instead of default 252kB). Whenever I decrease number of rules to <512, it works fine. BTW: kill -9 `pidof racoon` causes removing 'include "A.B.C.D.conf" ;' from racoon.conf, it seems to be buggy behaviour to me, isn't it?
(In reply to comment #9) > BTW: kill -9 `pidof racoon` causes removing 'include "A.B.C.D.conf" ;' from > racoon.conf, it seems to be buggy behaviour to me, isn't it? Sorry for silly question, this is correct behaviour.
Created attachment 439907 [details] Output of 'strace setkey -f setkey.conf-huge'
Created attachment 439908 [details] setkey input containing ~800 SPD rules
Created attachment 439911 [details] Output of 'strace /usr/sbin/racoon -l /var/log/racoon.log -d -d -d > /var/log/racoon.strace.log 2>&1' from ifup-ipsec
Created attachment 439913 [details] Output of 'strace /usr/sbin/racoon -l /var/log/racoon.log -d -d -d > /var/log/racoon.strace.log 2>&1' from ifup-ipsec
I am not sure why would you need that. Did the customer properly configured the buffer size in the racoon.conf? If they have the problem with the setkey command, they can load the rules in more consecutive setkey calls.
Loading via consecutive calls would required adapting shell scripts and so on, as far as I'm aware of. Customer didn't test it yet. It has been made available to him today. I'll keep you posted if it works.