Hi Simon,
> Is it possible that charon is searching for matches from pluto's
> connections? Why should charon have knowledge of
> pluto's connections?
Yes, that's exactly what's happening here. By default, charon loads all
connections whether they have keyexchange set to ikev2 or not. But it
uses IKEv1 connections only as responder (the reason for this was
probably to simplify configuration on gateways, as only one config would
be necessary). If you don't want this you could apply the attached patch.
> In another attempt to debug the problem, we arranged the order of the
> tunnels in ipsec.conf so that IKEv2 conn is ahead of the IKEv1 conn.
> Then connection is established. And the IKEv1 which is now second in
> /etc/ipsec.conf still works.
Yep, that works too, as charon simply uses the first matching connection.
Regards,
Tobias
>From d1d0d878945799a0f528794852c5ed10516d2ebd Mon Sep 17 00:00:00 2001
From: Tobias Brunner <tob...@strongswan.org>
Date: Wed, 8 Feb 2012 11:31:56 +0100
Subject: [PATCH] Charon ignores IKEv1 connections received via stroke.
---
src/libcharon/plugins/stroke/stroke_socket.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/libcharon/plugins/stroke/stroke_socket.c b/src/libcharon/plugins/stroke/stroke_socket.c
index 43919b0..7f44070 100644
--- a/src/libcharon/plugins/stroke/stroke_socket.c
+++ b/src/libcharon/plugins/stroke/stroke_socket.c
@@ -216,6 +216,12 @@ static void stroke_add_conn(private_stroke_socket_t *this, stroke_msg_t *msg)
pop_string(msg, &msg->add_conn.name);
DBG1(DBG_CFG, "received stroke: add connection '%s'", msg->add_conn.name);
+ if (!msg->add_conn.ikev2)
+ {
+ DBG1(DBG_CFG, "ignoring IKEv1 connection '%s'", msg->add_conn.name);
+ return;
+ }
+
DBG2(DBG_CFG, "conn %s", msg->add_conn.name);
pop_end(msg, "left", &msg->add_conn.me);
pop_end(msg, "right", &msg->add_conn.other);
--
1.7.4.1
_______________________________________________
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
