NO_PROPOSAL_CHOSEN error when IKEv1 and IKEv2 has closely resemble but not exact suites

[Simon Chan]

Hi all,

I am running StrongSwan 4.6.1 in Debian 6.0.3.

There is one IKEv1 conn and one IKEv2 conn. The IKEv1 cipher suites:
  ike=aes128-md5!
  esp=aes128-md5!
  pfs=yes


The IKEv2 cipher suites are almost identical except IKE has dh-group:
  ike=aes128-md5-modp1536!
  esp=aes128-md5!


The IKEv1 conn works but the IKEv2 conn gets "received NO_PROPOSAL_CHOSEN notify error".

syslog:
charon: 05[CFG] selecting proposal:
charon: 05[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found
charon: 05[CFG] received proposals: IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
charon: 05[CFG] configured proposals: IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5
charon: 05[LIB] size of DH secret exponent: 1535 bits
charon: 05[IKE] received proposals inacceptable
charon: 05[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]


At one point I changed the hash in IKEv1 suite to sha1 to isolate where that "configured proposal" come from:

  ike=aes128-sha1-modp1536!
  esp=aes128-sha1!

The IKEv2 conn is still using aes128-md5-modp1536! Still won't connect. The syslog changed to:
charon: 05[CFG] received proposals: IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536
charon: 05[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
charon: 05[IKE] remote host is behind NAT
charon: 05[IKE] received proposals inacceptable
charon: 05[ENC] generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
Is it possible that charon is searching for matches from pluto's connections?  Why should charon have knowledge of
pluto's connections?
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.

Appreciate if the experts can shed some light on this issue and give some ideas how to get the connections to
come up reliably.

We reproduced this problem on 2 difference similarly configured systems, one with StrongSwan 4.6.1, and another with 4.4.1. The full ipsec.conf file follows.

Thanks
Simon

  config setup
        charonstart=yes
        plutodebug=all
        charondebug="mgr 2, ike 2, chd 2, knl 2, net 2, lib 2, cfg 2"
        interfaces="%none"
        nat_traversal=yes

conn ikev1
        left=192.168.3.195
        right=192.168.3.193
        rekey=no
        leftsubnet=192.168.9.0/24
        rightsubnet=10.20.1.0/24
        leftfirewall=yes
        ike=aes128-md5!
        ikelifetime=7200s
        keyexchange=ikev1
        mobike=no
        keyingtries=%forever
        esp=aes128-md5!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        pfs=yes
        compress=no
        authby=secret
        auto=add

conn ikev2
        left=192.168.3.195
        right=192.168.3.193
        rightid=@differentfromright
        rekey=no
        leftsubnet=192.168.9.0/24
        rightsubnet=10.20.3.0/24
        leftfirewall=yes
        ike=aes128-md5-modp1536!
        ikelifetime=7200s
        keyexchange=ikev2
        mobike=yes
        keyingtries=%forever
        esp=aes128-md5!
        keylife=3600s
        rekeymargin=540s
        type=tunnel
        pfs=yes
        compress=no
        authby=secret
        auto=add










________________________________

[Tobias Brunner]

Hi Simon,

Post by Simon Chan
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.

Post by Simon Chan
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

[Simon Chan]

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 <tobias-***@public.gmane.org>
To: Simon Chan <***@yahoo.ca>
Cc: "users-3+4lAyCyj6DkhV4RL1hkzWD2FQJk+8+***@public.gmane.org" <users-3+4lAyCyj6DkhV4RL1hkzWD2FQJk+8+***@public.gmane.org>
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,

Post by Simon Chan
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.

Post by Simon Chan
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

[Tobias Brunner]

Hi Simon,

Post by Simon Chan
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?

Yes, the current selection algorithm is very simple and based solely on
the IP addresses. This leads exactly to the situation you described.

Post by Simon Chan
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?

We could change the code and consider the proposals sent by the client
but that would require quite some refactoring. And it wouldn't really
improve the situation much. You simply can't enforce an IKE proposal
for a specific client other than by its IP address (the IDs are exchange
only after the IKE proposal is selected).
The config in ipsec.conf might be a bit misleading on that part, as you
define IKE_SA and CHILD_SA options in the same conn section, but in
reality these are used separately by charon (first only the IKE part is
considered and once the IDs are known the proper CHILD config is
selected which might not be from the same conn section in ipsec.conf).

Therefore, you might want to rethink why you want to use strict mode as
responder for road warriors (i.e. with right=%any). If you don't like
charon's default proposal you could, of course, define a strict proposal
that contains all the proposals you allow for any of the road warriors
(e.g. ike=aes128-sha1-modp1536, aes128-md5-modp1536! which could also be
written as ike=aes128-sha1-md5-modp1536!).

Regards,
Tobias

[Simon Chan]

Hi Tobias,

Many thanks for the detailed explanation. Your proposed solution is a good fit for our system.

Simon



________________________________