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 <[email protected]> > 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 > >
_______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
