[strongSwan] Unable to establish all the security associations with 2000 IPsec tunnels (using 5.0.4 strongswan and load-tester plugin)

[Chinmaya Dwibedy]

Hi ,
I changed the “/proc/sys/net/core/xfrm_acq_expires” from 165
to 1000 seconds. What I understand, if an IKEv2 negotiation fails due to a
timeout (during the IKE_AUTH exchange) after a successful IKE_SA_INIT exchange,
then after the timeout (165s by default), charon will retry a new negotiation
from the beginning. I tested with 1000 IPsec tunnels successfully for 10 times.
Always it could able to bring up the tunnels and SAD count was 2000 (both
sides) always. But keeping the xfrm_acq_expires to 1000 seconds and trying to
run with 2000 IPsec tunnels, again started getting the XFRM_MSG_EXPIRE from
kernel. 
Jan  1 04:36:30
14[MGR] check-in of IKE_SA successful.
Jan  1 04:36:37
05[KNL] received a XFRM_MSG_EXPIRE
Jan  1 04:36:37
05[KNL] creating delete job for ESP CHILD_SA with SPI c0235d92 a
nd reqid {806}
Jan  1 04:36:37
03[MGR] checkout IKE_SA by ID
Jan  1 04:36:37
03[JOB] CHILD_SA with reqid 806 not found for delete
Jan  1 04:36:37
05[KNL] received a XFRM_MSG_EXPIRE
Jan  1 04:36:37
05[KNL] creating delete job for ESP CHILD_SA with SPI c3e24128 a
nd reqid {808}
 
Can anyone please clarify the followings?
1)     For increased number of IPsec tunnels
(e.g., 2000, 5000, 10000…), do I need always to change (increase the timeout) the
source code (kernel_netlink_ipsec.c) and then test to figure out which suits
best to our setup?
2)    Is this value is configurable? 
3)    I think, still 165 seconds is quite a
long time.  What might be the possible
cause behind IKE_AUTH exchange taking longer than 165s? Is it processing delay
caused by thread (running at IKE responder end)?
 
 
Here go our configurations
IKE initiator 
strongswan.conf
        threads = 16
        replay_window
= 32
        dos_protection
= no
        block_threshold=2000
        cookie_threshold=2000
        init_limit_half_open=2000
        retransmit_timeout=60
        retransmit_tries=30
        install_virtual_ip=no
        install_routes=no
        close_ike_on_child_failure=yes
        ikesa_table_size = 512
        ikesa_table_segments = 16
        reuse_ikesa =
no
 
 
 load-tester {
                     enable = yes
                     initiators = 40
                     iterations = 50
                     delay = 20
                     responder = 30.30.30.2
                     proposal = aes128-sha1-modp1024
                     initiator_auth = psk
                     responder_auth = psk
                     request_virtual_ip = no
                     ike_rekey = 0
                     child_rekey = 0
                     delete_after_established = no
                     shutdown_when_complete = no
                     #fake_kernel = yes
                  }
 
ipsec.secrets
@srv.strongswan.org %any : PSK "strongSwan"
 
IKE Responder
strongswan.conf
        threads = 16
        replay_window
= 32
        block_threshold=2000
        cookie_threshold=2000
        init_limit_half_open=2000
        half_open_timeout=2000
        dos_protection
= no
        install_virtual_ip=no
        install_routes=no
        close_ike_on_child_failure=yes
        ikesa_table_size = 512
        ikesa_table_segments = 16
        reuse_ikesa =
no
ipsec.conf
conn %default
        ikelifetime=24h
        keylife=23h
        rekeymargin=5m
        keyingtries=1
        keyexchange=ikev2
        ike=aes128-sha1-modp1024!
        mobike=no
 
conn host-host
        left=30.30.30.2
        leftsubnet=30.30.30.2/8
        rightid=%any
        leftauth=psk
        leftfirewall=yes
        right=30.30.30.1
        rightsubnet=30.30.30.1/8
        leftid=@srv.strongswan.org
        rightauth=psk
        type=tunnel
        authby=secret
        rekey=no
        reauth=no
 
ipsec.secrets
@srv.strongswan.org %any : PSK "strongSwan"
 
Regards,
Chinmaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130812/4537f4d6/attachment.html>