[strongSwan] Ballpark number of users and Load balancing

[kgardenia42]

On Wed, Oct 10, 2012 at 10:01 AM, Martin Willi <martin at strongswan.org> wrote:
> Hi,
>
>> The biggest bottleneck I've found around number of users involves the
>> peer lookup at IKE authentication time. If you configure static traffic
>> selectors for each individual peer (as I do) then it's a linear search
>> across the set of KNOWN possible peer IDs.
>
> While this is true, it only applies if you configure many individual
> ipsec.conf connections. ipsec.conf does not scale to hundreds of
> connections very well. But if you have a few connections only, this
> lookup doesn't have any impact.
>
> Alternatively you could use a single connection and write a better
> scaling plugin that narrows down traffic selectors for each peer.
>
>> I run 5000 clients with 1024b RSA pubkey auth on a 1GB VM guest of a
>> 2GHz core i5 machine and peer lookup is around 200ms on average.
>
> If IKE_SA lookup tuning [1] is configured properly, and your
> configuration backend does not slow down this process, much more is
> possible. I've tested configurations that served several hundred
> connection setups per second. The limiting factor is usually raw crypto,
> namely the Diffie-Hellman exchange. [2] has some numbers about public
> key operations.
>
>> Can anyone give me a rough idea of how many clients I can expect (say)
>> an Amazon EC2 large instance to handle.
>
> charon scales well to several ten thousand tunnels, but this depends all
> on your configuration and requirements. There is no fixed limit of
> concurrent tunnels, but each tunnel requires about 5-8KB of memory.

I'm actually using IKEv1 (pluto) as per

   http://wiki.strongswan.org/projects/strongswan/wiki/IOS_%28Apple%29.

Should I expect similar numbers?
>
>> I found the integrated load test tool docs and intend to run this
>> tomorrow but I am not sure to what extent it emulates *real* users.
>
> It emulates real users just fine using different authentication methods.
> If you request virtual IPs, make sure to not actually install them
> (charon.install_virtual_ip = no), as it slows down the client
> significantly. Load-tester tests tunnel establishment only, but does not
> send traffic on those tunnels.

Great.  I will test with this tool.

>
>> Secondly, I am investigating load balancing possibilities. Ideally I
>> would like a pool of (say) 4 strong-swans all of which can share a
>> load.  I'm not sure if sharing load would mean user stickiness or some
>> hared state across nodes but source ip stickiness would be acceptable
>> I guess.
>
> Of course you can set up load balancing on a higher level, say DNS, or a
> dedicated load balancer. Each strongSwan then acts independently and
> handles just those clients that connect to them.

I'm not sure how the DNS load balancing would work.  If I had 2
strongswans "foo" and "bar" then if the DNS gave out "foo" and a VPN
tunnel was established then couldn't the same DNS momentarily
afterwards give out "bar" and so packets would go to the wrong VPN
server?

Or is it the case that once the tunnel is established then all traffic
will implicitly go there (by ip address) until the tunnel is finished?
 I suspect this is a dumb question and of cource the tunnel will will
stick once established but I just wanted to double-check.

When you say a "dedicated load balancer" I assume you mean one which
just forwards packets rather than one which terminates connections?
Otherwise how would the load-balancer know which pool member to select
for an established tunnel?  Not sure if I'm being clear in my
quesiton.

> If you need a failover mechanism, too, you could take a look at our HA
> solution [3]. It can share load, but also migrate clients transparently
> while the tunnel is active. It currently works for 2 nodes only.

I will read more about this.  Thanks.

>
>> Will this even work in a cloud (EC2) environment where the LAN IPs are
>> not under my control (unless perhaps VPC).
>
> HA depends on ClusterIP with a shared IP address. I don't know if this
> is possible in EC2. The switches must tolerate a multicast ARP for the
> shared IP, but usually this is no problem.
>
> Martin
>
> [1]http://wiki.strongswan.org/projects/strongswan/wiki/IkeSaTable
> [2]http://wiki.strongswan.org/projects/strongswan/wiki/PublicKeySpeed
> [3]http://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability
>

Great information/feedback.

Thanks!