[strongSwan] IPsec/IKEv2 tunnels scalability issue with load-tester plugin (using strongSwan 5.0.4)

Chinmaya Dwibedy ckdwibedy at yahoo.com
Mon Aug 5 12:36:23 CEST 2013


Hi All,
We are using two Multi-Core MIPS 64 bit Processors. (One acts
as an IKE initiator and another as an IKE responder). We are running strongswan
in both systems. Both the systems have 1Gbps Ethernet cards, which are
connected to 1 Gbps L2 switch. The Linux OS runs on all these cores. We have
modified the strongswan code (5.0.4) so as to restrict one instance of
starter/charon to run on first core but the group of threads (created and
managed by the strongswan based upon configuration setting in strongswan.conf
file) in order to process a large number of tasks, will be scheduled and
distributed among multi cores. 
We are doing the stability/performance benchmark testing (i.e.,
to measure the maximum no. of IPsec/IKEv2 tunnels without traffic, Tunnel
setup/teardown rate) using the load-tester plugin.We
followed all the instructions to install and build the load tester plugin to
work. The strong swan wiki page says that, this plugin allows setting up
thousands of tunnels concurrently against the remote host. With 200 IPsec
tunnels (initiators = 10, iterations = 20 and delay = 20 in load-tester of
strongswan.conf), it works well. We mean, it could able to bring up all the
tunnels. While configuring for 300 IPsec tunnels, it cannot bring all the
tunnels. Sometimes it creates 200, 210, 198 etc. We observed that, at responder
end, it writes the following message “ignoring IKE_SA setup from 30.30.30.1,
peer too aggressive” in charon.log. Thus we increased the maximum number of
half-open IKE_SAs by configuring the block_threshold to 300 in strongswan.conf of
IKE responder side.
Although we did not encounter with aforesaid message, it could
not create all 300 IPsec tunnels. Furthermore, it caused the following error
message at responder end . In charon.log, it writes the followings 
[IKE] tried 1 shared key for 'srv.strongswan.org' - 'c13-r1.strongswan.org',
but MAC mismatched[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] 
[IKE] tried 1 shared key for 'srv.strongswan.org' - 'c15-r1.strongswan.org',
but MAC mismatched[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ] 
 
Please find our configuration below for Initiator as well as
Responder.
 
Configurations at IKE initiator
strongswan.conf 
# number of worker threads in charon
        threads = 16
        replay_window =
32
    
        plugins {
        load-tester {
                     enable = yes
                     initiators = 10
                     iterations = 30
                     delay = 100
                     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
                       }
 
ipsec.secrets
@srv.strongswan.org %any : PSK "strongSwan"
 
Configurations at IKE responder
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
        auto=add
strongswan.conf
        # number of
worker threads in charon
        threads = 16
        replay_window =
32
        block_threshold=300
 
We went thru  http://permalink.gmane.org/gmane.network.vpn.strongswan.user/6057 and found that,  Martin has told (in his response
to Victor) strongswan can handle several ten thousand tunnels (IPsec/IKEv2) when
configured  properly. Can anyone please suggest
where we are wrong or is it the limit?   
Regards,
Chinmaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20130805/bf57b06a/attachment.html>


More information about the Users mailing list