Project

General

Profile

Issue #2417

Infinite task requeue in IKEv1 Aggressive mode

Added by Emeric Poupon about 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
ikev1
Affected version:
5.5.3
Resolution:
Won't fix

Description

Hello,

We are using certificates in IKEv1 aggressive mode.
However, the authentication hook on the responder side prevents the IKE SA to be established.

Here is the scenario that leads to the problem:
1/ The IKE SA is established on the connection initiator. It immediately starts to negotiate a QUICK mode
2/ The authorize hook prevents the IKE SA to be established on the responder side (it calls an external script for that). It sends a IKE SA DELETE message
3/ the connection initiator receives the IKE SA DELETE and immediately enqueue new connection tasks

Please find attached the relevant logs on initiator and responder sides

initiator.debug (130 KB) initiator.debug Emeric Poupon, 01.09.2017 16:23
responder.debug (167 KB) responder.debug Emeric Poupon, 01.09.2017 16:23

Related issues

Has duplicate Issue #2469: IKEv1: strongswan tries to reconnect the tunnel repeatedly during connection.Closed

History

#1 Updated by Tobias Brunner about 5 years ago

  • Status changed from New to Feedback

You probably have closeaction=restart configured.

#2 Updated by Emeric Poupon about 5 years ago

Tobias Brunner wrote:

You probably have closeaction=restart configured.

Sorry, here are the configuration files used:

conn "TUNNEL" 
    type = tunnel
    auto = route
    keyexchange = ikev1
    aggressive = yes
    mobike = no
    left = 172.25.0.2
    right = 172.25.0.3
    leftauth = pubkey
    rightauth = pubkey
    leftcert = /tmp/Initiator1.cert.pem
    rightid = %any
    esp = aes256-sha2_256-modp2048-noesn,aes256-sha1-modp2048-noesn!
    ike = aes256-sha2_256-modp2048,aes128-sha2_256-modp2048!
    lifetime = 3600
    ikelifetime = 21600
    margintime = 720
    rekeyfuzz = 100%
    leftsendcert = yes
    rightsendcert = yes
    dpdaction = hold
    dpddelay = 0
    fragmentation = no
    replay_window = 2016
    leftsubnet = 192.168.25.0/24
    rightsubnet = 192.168.26.0/24

On the other host:

conn "TUNNEL" 
    type = tunnel
    auto = route
    keyexchange = ikev1
    aggressive = yes
    mobike = no
    left = 172.25.0.3
    right = 172.25.0.2
    leftauth = pubkey
    rightauth = pubkey
    leftcert = "/tmp/Responder3.labo.int.cert.pem" 
    rightid = %any
    esp = aes256-sha2_256-modp2048-noesn,aes128-sha2_256-modp2048-noesn!
    ike = aes128-sha2_256-modp2048,aes256-sha2_256-modp2048!
    lifetime = 3600
    ikelifetime = 21600
    margintime = 720
    rekeyfuzz = 100%
    leftsendcert = yes
    rightsendcert = yes
    dpdaction = hold
    dpddelay = 0
    fragmentation = no
    replay_window = 2016
    leftsubnet = 192.168.26.0/24
    rightsubnet = 192.168.25.0/24

#3 Updated by Tobias Brunner about 5 years ago

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

#4 Updated by Emeric Poupon about 5 years ago

Tobias Brunner wrote:

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

Is that a kind of regression introduced by the closeaction support in IKEv1?

#5 Updated by Tobias Brunner about 5 years ago

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

Is that a kind of regression introduced by the closeaction support in IKEv1?

Why?

#6 Updated by Emeric Poupon about 5 years ago

Is that a kind of regression introduced by the closeaction support in IKEv1?

Why?

Actually, I did not understand your first answer.
For us there is a real issue. For you is this a real issue or is there a workaround for it?

#7 Updated by Tobias Brunner about 5 years ago

Actually, I did not understand your first answer.

Which one?

For us there is a real issue. For you is this a real issue or is there a workaround for it?

You are using IKEv1, what do you expect?

#8 Updated by Emeric Poupon about 5 years ago

Tobias Brunner wrote:

Actually, I did not understand your first answer.

Which one?

This one:

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

For us there is a real issue. For you is this a real issue or is there a workaround for it?

You are using IKEv1, what do you expect?

Do you mean that you do not plan to fix it?

#9 Updated by Tobias Brunner about 5 years ago

Actually, I did not understand your first answer.

Which one?

This one:

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

What did you not understand?

#10 Updated by Emeric Poupon about 5 years ago

Tobias Brunner wrote:

Actually, I did not understand your first answer.

Which one?

This one:

It's actually not related to the config. Since the IKE_SA was fully established, but there was still a quick mode task queued the IKE_SA gets reestablished when deleted by the peer (see source:src/libcharon/sa/ike_sa.c#L2060, which was added with some patches - b79fdab878, 68db844f99 and a9ffb48f21 - that added support for closeaction to IKEv1).

What did you not understand?

I understand it is not related to the config, but I don't understand if you think it is a bug or not.

#11 Updated by Tobias Brunner about 5 years ago

I understand it is not related to the config, but I don't understand if you think it is a bug or not.

It's a protocol bug and its solution is IKEv2 (or at least Main Mode). The problem is that in Aggressive Mode the last message is sent by the client. So if the authentication or authorization fails the server can't abort the SA with an AUTHENTICATION_FAILED notify. The client already "successfully" established the IKE_SA when it sent the last AM message. So the only option for the server is to delete the IKE_SA (there is no retransmit for that delete).

#12 Updated by Tobias Brunner almost 5 years ago

  • Has duplicate Issue #2469: IKEv1: strongswan tries to reconnect the tunnel repeatedly during connection. added

#13 Updated by Tobias Brunner over 4 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to Won't fix

Also available in: Atom PDF