[strongSwan] [strongSwan-dev] problem with a cisco891 after reauthentication
sacho.polo at gmail.com
Tue Apr 14 22:53:53 CEST 2015
Hi Tobias, Andreas,
Thank you for your reply. I have a few more questions inline.
On Tue, Apr 14, 2015 at 5:32 AM, Tobias Brunner <tobias at strongswan.org>
> > I notice the problem when the cisco attempts reauthentication of phase1.
> > It seems that the existing phase1 is first down-ed before the new one is
> > created. In most other firewalls, i see that a new phase1 is created
> > before the old one is killed.
> Yes, charon does that too when reauthenticating IKEv1 SAs. For IKEv2 we
> do what the Cisco box does and first terminate the existing IKE SA
> before recreating it with all CHILD_SAs. That's where 5.3.0 with its
> optional make-before-break reauthentication comes in (as mentioned by
> Andreas). But that's irrelevant for IKEv1 as we did this all along.
> However, it's also how we expect other IKEv1 implementations to
> reauthenticate SAs.
Just to make sure I understand what is expected of IKEv1 connections,
(sorry I had to ask again)
Are IKEv1s are expected to break all connections before making a new one?
Are they expected to make a new one before breaking the old one.
I have seen Juniper firewalls and Cisco ASA make a new one before
terminating an old one.
> > The problem with how the cisco891 does this is that when phase1 that is
> > being reauthenticated is deleted, the phase2s are also killed on
> > strongswan.
> Yes, CHILD_SAs in charon are strictly associated with an IKE_SA, that
> is, they can't exist without one (possible that pluto handled this
> differently). So when the IKE_SA with a peer is closed its CHILD_SAs
> are destroyed too (there are no DELETES sent for them because we act on
> the request of the other peer).
> > Is there anyway to workaround this in strongswan?
> I suppose you could change the process_r() method of the isakmp_delete_t
> task so that DELETES for ISAKMP SAs are ignored (i.e. simply return
> SUCCESS without doing anything else there). That way the original SA
> and its CHILD_SAs are not closed but a reauthentication should still be
> detected when the Cisco box creates the new SA (the old CHILD_SAs are
> then adopted and the original IKE_SA gets closed). The only
> disadvantage is that IKE_SAs can't be closed by peers anymore.
I was thinking of two ways to workaround this, the first being similar to
what you suggest. Please let me know your opinion.
1. Ignore an Phase 1 delete if it still has phase2s. This is for IKEv1 only
since we are testing with ikev1 firewalls only.
2. Instead of silently deleting Phase2s, do a proper delete that sends out
a DELETE to the other side. Would this be difficult to implement?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users