[strongSwan] Automated test ha/both-active fails

[Daniel Palomares]

Thanks for the reply Willi,

What I have seen is that replay IPsec SA counters are increased by a big
number so there are no troubles with the IPsec SA counters. That's good!..
but....

But, imagine the following scenario: SG1 is  overloaded (big amounts of
IKE_SA connections). If the SG1 crashes just after he has answered some IKE
request and didn't have the time to synchonize this information to other
members in the cluster (SG2); then SG2 must close those IKE_SAs due to
unsynchronization of IKE_SA counters. I'm I right? The good point here is
that just those IKE_SA message replies that couldn't be synchronized with
SG2, are those which will be terminated. The rest of IKE_SA will continue
working.

Another subject that I'm working on: IKEv2/IPsec Traffic Management.

If we focus in a different problem, we can propose to manage some
IKEv2/IPsec traffic from SG1 to SG2 by using Redirect Mechanism and adding
a kind of transfer of IKEv2/IPsec context between gateways as well. Of
course, this is a much more research subject than an email for the
"User-mailinglist" of strongSwan, but I thinks this is still interesting.
ISPs will face the problem of peer mobility (mobility in terms of Access
Network, not just IP as MOBIKE already does) and I was thinking in a
solution to IPsec traffic management.

Regards
Daniel P


2012/6/29 Martin Willi <martin at strongswan.org>

> Daniel,
>
> > Is this the new feature of High Availability for IPsec RFC-6311 ?
>
> Our HA solution works different and is not based on RFC 6311. In fact,
> we don't need any additional protocol support in IKEv2 between server
> and client, all the synchronization is done between the cluster nodes
> directly.
>
> > Does this patch generate IKE exchanges to increases IPsec Counters?
>
> We use ClusterIP to keep the sequence counters up to date, no IKE
> exchange is involved. This has the big advantage that it works with any
> IKEv2 client.
>
> > I thought that the first patches didn't increase the IPsec replay
> > counters. Is this a new feature in ha3.3? Or since when did you
> > developed this capability?
>
> One issue that might arise with the ClusterIP sequence update is that we
> might miss some packets due to packet loss. This can be problematic for
> outgoing packets, as the peer might reject a few packets after failover,
> breaking connections.
>
> As a work-around, I've implemented a "failover advance" mechanism with
> these last two commits: After a failover, we advance the replay counter
> for outgoing messages by a certain window. This will make sure we don't
> use sequence numbers for packets already processed by the responder.
> Doesn't change anything fundamental, but certainly can improve
> connection reliability after a failover.
>
> Regards
> Martin
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120707/a8caaa0f/attachment.html>