Bug #95

pluto sends new mode_cfg pull request when rekeying phase 1 and phase 2 SAs exist

Added by Ray Kohler over 2 years ago. Updated about 1 month ago.

Status:Closed Start date:02.10.2009
Priority:Normal Due date:
Assignee:Andreas Steffen % Done:

0%
Category:pluto
Target version:-
Affected version: Resolution:Invalid

Description

(This problem is made more frequent and obvious by the fix for #94, though it is not actually caused by that patch.)

I have a roadwarrior config with multiple tunnels through the same peer. All of them share the same leftsourceip (my end). When it is time to rekey the ISAKMP SA, pluto sends a mode_cfg pull request (if configured to do so). However, if there are still any IPSEC SAs active with that same peer and using that same leftsourceip, the peer will not send a mode_cfg reply back, instead wanting me to inherit the old mode_cfg reply data as long as some IPSEC SA still uses that leftsourceip. I am then unable to create any new ISAKMP SAs, so my IPSEC SAs slowly expire. When all IPSEC SAs have expired, the peer will now permit me to send mode_cfg pull requests again.

The peer is a Cisco of some sort that I don't have access to. In the case where it refuses to send the mode_cfg reply, it instead sends INFO_EXCHANGE messages that pluto can't (or won't?) decode. Sometimes I get many of these at once:
Oct 2 04:23:44 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA
Oct 2 04:24:04 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA
Oct 2 04:24:06 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA
Oct 2 04:24:08 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA
Oct 2 04:24:10 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA
Oct 2 04:24:10 asenath pluto26882: packet from 128.2.5.228:500: Informational Exchange is for an unknown (expired?) SA

Would it make sense to preserve mode_cfg reply data across renegotiations of phase 1, unless we are starting from a fresh state, as the peer seems to want? If not, would it be effective to fall back to preserving old mode_cfg reply data in any case where it exists and a new mode_cfg request has just failed? (I don't know if the peer invalidates our state in some way after refusing a mode_cfg request. It at least does not ask us to delete the ISAKMP SA afterward.)

History

#1
Updated by Andreas Steffen over 2 years ago

I've been running such a multiple Mode Config test scenario with a pluto gateway for hours (with an ISAKMP rekeying and a subsequent Mode Config Phase 1.5 every 10 minutes) and this without any problems. On the gateway the setting rekey=no must be enforced. Otherwise multiple Phase 1 SAs are created.

Andreas

#2
Updated by Ray Kohler over 2 years ago

I am unable to do any configuration of the gateway I connect to - it will rekey with me no matter what I might set locally.

I wondered if this was not really a bug in strongSwan's pluto at all, but a bug or misconfiguration on the Cisco side. It seems that you agree with this. If that's the case, I accept that. I won't try to make you fix something that isn't a bug.

#3
Updated by Tobias Brunner about 1 month ago

  • Status changed from New to Closed
  • Resolution set to Invalid

Also available in: Atom PDF