Hi Tobias,
Thank you so much for your quick response. It is good to know that there is a
reason for charon to
know about IKEv1 connections. But the problem I am facing is not over yet.
Apparently root cause of my mistaken identity problem is "right=%any". Ordering
ikev2 tunnels ahead of
ikev1 helped only because there are 2 conns in ipsec.conf. Get rid of pluto
conn leave behind only 1 conn
so there is no chance for confusion. Normally I have 1000 tunnels and they are
all"right=%any".
I get the NO_PROPOSAL_CHOSEN problem easily with two IKEv2 conns that have
different
cipher suites. E.g. first one use sha1 and second one use md5:
conn first
left=192.168.3.193
right=%any
rightid=@1000-1
ike=aes128-sha1-modp1536!
keyexchange=ikev2
...
conn second
left=192.168.3.193
right=%any
rightid=@1000-2
ike=aes128-md5-modp1536!
keyexchange=ikev2
...
Here is the syslog:
charon: 11[NET] received packet: from 192.168.3.195[500] to 192.168.3.193[500]
charon: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP)
N(NATD_D_IP) ]
charon: 11[CFG] looking for an ike config for 192.168.3.193...192.168.3.195
charon: 11[CFG] candidate: 192.168.3.193...%any, prio 5
charon: 11[CFG] candidate: 192.168.3.193...%any, prio 5
charon: 11[CFG] found matching ike config: 192.168.3.193...%any with prio 5
charon: 11[IKE] 192.168.3.195 is initiating an IKE_SA
charon: 11[IKE] IKE_SA (unnamed)[3] state change: CREATED => CONNECTING
charon: 01[JOB] next event in 29s 999ms, waiting
charon: 11[CFG] selecting proposal:
charon: 11[CFG] no acceptable INTEGRITY_ALGORITHM found
charon: 11[CFG] received proposals:
IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
charon: 11[CFG] configured proposals:
IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
charon: 11[LIB] size of DH secret exponent: 1534 bits
charon: 11[IKE] received proposals inacceptable
charon: 11[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
From the syslog, it would seem once a possible candidate is picked (by their
order in ipsec.conf), the proposal
selection would not look at the other conns that are also 192.168.3.193...%any.
Is this true?
If true, any suggestion how I can get tunnels with different ciphers co-exist?
Ideally modify the code to go back and pick another <my_ip>...%any candiate is
best for my application. Or perhaps I ban strict mode when right=%any?
Thank you again for your help.
Simon
________________________________
From: Tobias Brunner <[email protected]>
To: Simon Chan <[email protected]>
Cc: "[email protected]" <[email protected]>
Sent: Wednesday, February 8, 2012 2:35:33 AM
Subject: Re: [strongSwan] NO_PROPOSAL_CHOSEN error when IKEv1 and IKEv2 has
closely resemble but not exact suites
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
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
