[Swan] No PARENT proposal selected

[Bob Miller]

Greetings,

I am trying to set up ikev2 with windows road warriors, but I am having
an error "No PARENT proposal selected". When I google this all I find
is the ikev2_spdb_struct.c file that the error comes from. I tried to
chase it back in the code to find what could cause the message, but I am
pretty sure this is written in vulcan...

Is there a clue as to what could be wrong when this message comes up?

[Paul Wouters]

I am trying to set up ikev2 with windows road warriors, but I am having an
error "No PARENT proposal selected". When I google this all I find is the
ikev2_spdb_struct.c file that the error comes from. I tried to chase it back
in the code to find what could cause the message, but I am pretty sure this
is written in vulcan...
Is there a clue as to what could be wrong when this message comes up?

Probably you are having a mismatched AUTH scheme? You should not use EAP
but "Machine Certificate".

Paul

[Bob Miller]

Hi Paul,

Thanks for the response.

Post by Paul Wouters

Post by Bob Miller
I am trying to set up ikev2 with windows road warriors, but I am
having an error "No PARENT proposal selected".
Is there a clue as to what could be wrong when this message comes up?

Probably you are having a mismatched AUTH scheme? You should not use EAP
but "Machine Certificate".

I am definitely using machine certificate.

I have recreated the CA, firewall, and user cert. I have installed all
three certs on the firewall, and the CA has CTu,u,u and the fw and user
cert have u,u,u. I have ensured the cert on windows is installed in
local machine, and the CA is listed in the Trusted Root. I have ensured
the fw cert has a SAN and CN that matches its DNS name.

I am using the new format for the NSS DB sql:/etc/ipsec.d as specified
on the wiki, and I have compared my ipsec.conf to the ikev2 one on the
wiki as well.

Any other suggestions where I might look for the problem?

Post by Paul Wouters
Paul

[Paul Wouters]

Post by Bob Miller
I am definitely using machine certificate.
I have recreated the CA, firewall, and user cert. I have installed all three
certs on the firewall, and the CA has CTu,u,u and the fw and user cert have
u,u,u. I have ensured the cert on windows is installed in local machine, and
the CA is listed in the Trusted Root. I have ensured the fw cert has a SAN
and CN that matches its DNS name.
I am using the new format for the NSS DB sql:/etc/ipsec.d as specified on the
wiki, and I have compared my ipsec.conf to the ikev2 one on the wiki as well.
Any other suggestions where I might look for the problem?

Run with plutodebug=all and see what's going on?

Paul

[Bob Miller]

Hi Paul,

Post by Paul Wouters

Post by Bob Miller
I am using the new format for the NSS DB sql:/etc/ipsec.d as specified
on the wiki, and I have compared my ipsec.conf to the ikev2 one on the
wiki as well.
Any other suggestions where I might look for the problem?

Run with plutodebug=all and see what's going on?

Seems libreswan doesn't load the fw certificate, but it's a little bit
odd because ipsec auto --listall shows all the certs like I expect. I
will retrace my steps to see what I missed.

Oct 9 10:02:02 fw-kz pluto[30128]: | Added new connection rw-ikev2 with
policy
RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_PROPOSE+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW
Oct 9 10:02:02 fw-kz pluto[30128]: | loaded certificate 'fw-kz.kza.yk.ca'
Oct 9 10:02:02 fw-kz pluto[30128]: | certificate is valid
Oct 9 10:02:02 fw-kz pluto[30128]: | get_pluto_gn_from_nss_cert:
allocated pluto_gn 0x563ea31fad00
Oct 9 10:02:02 fw-kz pluto[30128]: | get_pluto_gn_from_nss_cert:
allocated pluto_gn 0x563ea322c5b0
Oct 9 10:02:02 fw-kz pluto[30128]: | get_pluto_gn_from_nss_cert:
allocated pluto_gn 0x563ea3227ba0
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | unreference key: 0x563ea31ff1d0
C=CA, ST=Yukon, O=Kobayashi & Zedda Architects, OU=Network Admin,
CN=fw-kz.kza.yk.ca, E=***@computerisms.ca cnt 1--
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | unreference key: 0x563ea322c250
@fw-kz.kza.yk.ca cnt 1--
Oct 9 10:02:02 fw-kz pluto[30128]: | counting wild cards for
@fw-kz.kza.yk.ca is 0
Oct 9 10:02:02 fw-kz pluto[30128]: | certificate not loaded for this end
Oct 9 10:02:02 fw-kz pluto[30128]: | counting wild cards for %fromcert is 0

Post by Paul Wouters
Paul

[Matt Rogers]

Post by Bob Miller
Seems libreswan doesn't load the fw certificate, but it's a little bit
odd because ipsec auto --listall shows all the certs like I expect. I
will retrace my steps to see what I missed.
Oct 9 10:02:02 fw-kz pluto[30128]: | Added new connection rw-ikev2 with
policy
RSASIG+ENCRYPT+TUNNEL+PFS+DONT_REKEY+IKEV2_ALLOW+IKEV2_PROPOSE+IKEV2_ALLOW_NARROWING+SAREF_TRACK+IKE_FRAG_ALLOW
Oct 9 10:02:02 fw-kz pluto[30128]: | loaded certificate 'fw-kz.kza.yk.ca'
Oct 9 10:02:02 fw-kz pluto[30128]: | certificate is valid
allocated pluto_gn 0x563ea31fad00
allocated pluto_gn 0x563ea322c5b0
allocated pluto_gn 0x563ea3227ba0
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | unreference key: 0x563ea31ff1d0
C=CA, ST=Yukon, O=Kobayashi & Zedda Architects, OU=Network Admin,
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | id kind mismatch
Oct 9 10:02:02 fw-kz pluto[30128]: | unreference key: 0x563ea322c250
@fw-kz.kza.yk.ca cnt 1--
Oct 9 10:02:02 fw-kz pluto[30128]: | counting wild cards for
@fw-kz.kza.yk.ca is 0
Oct 9 10:02:02 fw-kz pluto[30128]: | certificate not loaded for this end
Oct 9 10:02:02 fw-kz pluto[30128]: | counting wild cards for %fromcert is 0

This debug logging may be a little misleading. There's an attempt to load a certificate
for each end, so if you have leftcert=fw-kz.kza.yk.ca and no rightcert=, then the
"certificate not loaded for this end" line happens for the 'right' end.

You should check further down in the logs to see what is happening when the proposal
is rejected.

Matt

[Bob Miller]

Matt,

Thank you sooo much for giving me a proper interpretation, probably
saved me a pile of time chasing that to no conclusion.

Post by Matt Rogers
You should check further down in the logs to see what is happening when the proposal
is rejected.

It looks like this is the part you are referring to. There are a couple
dozen stanzas like the following:

|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 5
|failed integ=(policy:AUTH_AES_XCBC_96(-2) vs offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 4
|failed prf= (policy:PRF_AES128-XCBC(-2) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|failed integ=(policy:AUTH_AES_XCBC_96 vs offered:AUTH_HMAC_SHA1_96)
|failed prf= (policy:PRF_AES128-XCBC vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)

This one is the closest I see to a success:

|considering Transform Type TRANS_TYPE_ENCR, TransID 12
|IKEv2_KEY_LENGTH attribute 128
|encrid(12), keylen(128), encr_keylen(-1)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 2
|succeeded integ=(policy:AUTH_HMAC_SHA1_96(-1) vs
offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 2
|succeeded prf= (policy:PRF_HMAC_SHA1(-1) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|succeeded integ=(policy:AUTH_HMAC_SHA1_96 vs offered:AUTH_HMAC_SHA1_96)
|succeeded prf= (policy:PRF_HMAC_SHA1 vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)

So I looked through all the lines that say failed dh=, and the lowest
policy is OAKLEY_GROUP_MODP1536, but I am guessing from this that
windows is requiring modp1024. I found in the man page that ike should
allow modp1024, modp1536, and modp2048, and that modp1024 will be
removed in the near future. I also find in my logs attempts with
modp4096 and modp8192, which are not mentioned in the man page. And the
man page says I should use a value of ipsec_spi(8)'s --ike option, but
man 8 ipsec_spi has no reference to ike in it. So I am not sure if I am
referencing the correct bit of documentation to match the problem.

for that matter, I am not sure that my assessment that windows is
providing too low a level of OAKLEY_GROUP_MODP is correct. I tried
adding a few lines like ike=3des-sha1;modp1024 to my conn, but all the
things I tried seemed to get stuck at STATE_PARENT_R1.

I have been using openswan/libreswan almost a decade and I have never
had to dig into this side of the docs before. Pointers would be
appreciated; I will keep seeing what I can figure in the meantime...

Post by Matt Rogers
Matt

[Bob Miller]

For the benefit of anyone having trouble with getting this incantation
just right, adding to my conn:

ike=aes256-sha384-modp1024

made my windows 7 client work. Seems windows 7 only supports modp1024,
which is disabled by default in libreswan3.14+.

Post by Bob Miller
Matt,
Thank you sooo much for giving me a proper interpretation, probably
saved me a pile of time chasing that to no conclusion.

Post by Matt Rogers
You should check further down in the logs to see what is happening when the proposal
is rejected.

It looks like this is the part you are referring to. There are a couple
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 5
|failed integ=(policy:AUTH_AES_XCBC_96(-2) vs
offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 4
|failed prf= (policy:PRF_AES128-XCBC(-2) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|failed integ=(policy:AUTH_AES_XCBC_96 vs offered:AUTH_HMAC_SHA1_96)
|failed prf= (policy:PRF_AES128-XCBC vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|considering Transform Type TRANS_TYPE_ENCR, TransID 12
|IKEv2_KEY_LENGTH attribute 128
|encrid(12), keylen(128), encr_keylen(-1)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 2
|succeeded integ=(policy:AUTH_HMAC_SHA1_96(-1) vs
offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 2
|succeeded prf= (policy:PRF_HMAC_SHA1(-1) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|succeeded integ=(policy:AUTH_HMAC_SHA1_96 vs offered:AUTH_HMAC_SHA1_96)
|succeeded prf= (policy:PRF_HMAC_SHA1 vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
So I looked through all the lines that say failed dh=, and the lowest
policy is OAKLEY_GROUP_MODP1536, but I am guessing from this that
windows is requiring modp1024. I found in the man page that ike should
allow modp1024, modp1536, and modp2048, and that modp1024 will be
removed in the near future. I also find in my logs attempts with
modp4096 and modp8192, which are not mentioned in the man page. And the
man page says I should use a value of ipsec_spi(8)'s --ike option, but
man 8 ipsec_spi has no reference to ike in it. So I am not sure if I am
referencing the correct bit of documentation to match the problem.
for that matter, I am not sure that my assessment that windows is
providing too low a level of OAKLEY_GROUP_MODP is correct. I tried
adding a few lines like ike=3des-sha1;modp1024 to my conn, but all the
things I tried seemed to get stuck at STATE_PARENT_R1.
I have been using openswan/libreswan almost a decade and I have never
had to dig into this side of the docs before. Pointers would be
appreciated; I will keep seeing what I can figure in the meantime...

Post by Matt Rogers
Matt

_______________________________________________
Swan mailing list
https://lists.libreswan.org/mailman/listinfo/swan

[Paul Wouters]

Thanks! I'll add it to the faq

Sent from my iPhone

Post by Bob Miller
ike=aes256-sha384-modp1024
made my windows 7 client work. Seems windows 7 only supports modp1024, which is disabled by default in libreswan3.14+.

Post by Bob Miller
Matt,
Thank you sooo much for giving me a proper interpretation, probably
saved me a pile of time chasing that to no conclusion.

Post by Matt Rogers
You should check further down in the logs to see what is happening when the proposal
is rejected.

It looks like this is the part you are referring to. There are a couple
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 5
|failed integ=(policy:AUTH_AES_XCBC_96(-2) vs
offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 4
|failed prf= (policy:PRF_AES128-XCBC(-2) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|failed integ=(policy:AUTH_AES_XCBC_96 vs offered:AUTH_HMAC_SHA1_96)
|failed prf= (policy:PRF_AES128-XCBC vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|considering Transform Type TRANS_TYPE_ENCR, TransID 12
|IKEv2_KEY_LENGTH attribute 128
|encrid(12), keylen(128), encr_keylen(-1)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|considering Transform Type TRANS_TYPE_INTEG, TransID 2
|succeeded integ=(policy:AUTH_HMAC_SHA1_96(-1) vs
offered:AUTH_HMAC_SHA1_96(-1))
|considering Transform Type TRANS_TYPE_PRF, TransID 2
|succeeded prf= (policy:PRF_HMAC_SHA1(-1) vs offered:PRF_HMAC_SHA1(-1))
|considering Transform Type TRANS_TYPE_DH, TransID 14
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
|proposal 1 failed encr= (policy:AES_CBC(-2) vs offered:3DES(-1))
|succeeded integ=(policy:AUTH_HMAC_SHA1_96 vs offered:AUTH_HMAC_SHA1_96)
|succeeded prf= (policy:PRF_HMAC_SHA1 vs offered:PRF_HMAC_SHA1)
|failed dh= (policy:OAKLEY_GROUP_MODP2048 vs
offered:OAKLEY_GROUP_MODP1024)
So I looked through all the lines that say failed dh=, and the lowest
policy is OAKLEY_GROUP_MODP1536, but I am guessing from this that
windows is requiring modp1024. I found in the man page that ike should
allow modp1024, modp1536, and modp2048, and that modp1024 will be
removed in the near future. I also find in my logs attempts with
modp4096 and modp8192, which are not mentioned in the man page. And the
man page says I should use a value of ipsec_spi(8)'s --ike option, but
man 8 ipsec_spi has no reference to ike in it. So I am not sure if I am
referencing the correct bit of documentation to match the problem.
for that matter, I am not sure that my assessment that windows is
providing too low a level of OAKLEY_GROUP_MODP is correct. I tried
adding a few lines like ike=3des-sha1;modp1024 to my conn, but all the
things I tried seemed to get stuck at STATE_PARENT_R1.
I have been using openswan/libreswan almost a decade and I have never
had to dig into this side of the docs before. Pointers would be
appreciated; I will keep seeing what I can figure in the meantime...

Post by Matt Rogers
Matt

_______________________________________________
Swan mailing list
https://lists.libreswan.org/mailman/listinfo/swan

_______________________________________________
Swan mailing list
https://lists.libreswan.org/mailman/listinfo/swan

[Paul Wouters]

Matt,
Thank you sooo much for giving me a proper interpretation, probably saved me
a pile of time chasing that to no conclusion.
for that matter, I am not sure that my assessment that windows is providing
too low a level of OAKLEY_GROUP_MODP is correct.

It seems that is correct and Windows, at least in some configurations,
only proposed modp1024 in IKEv2, which libreswan no longer allows in its
default proposal. You will need an ike= line that matches the windows
proposal, possibly: ike=aes128-sha1;modp1024

I tried adding a few lines
like ike=3des-sha1;modp1024 to my conn, but all the things I tried seemed to
get stuck at STATE_PARENT_R1.

You need to fix the ike= line, not the esp= line.

Paul

[Tuomo Soini]

On Thu, 24 Dec 2015 00:10:10 -0500 (EST)

Post by Paul Wouters
It seems that is correct and Windows, at least in some configurations,
only proposed modp1024 in IKEv2, which libreswan no longer allows in
its default proposal. You will need an ike= line that matches the
windows proposal, possibly: ike=aes128-sha1;modp1024

Sorry, that doesn't work. Windows wants aes256-sha2_256;modp1024.
I have all the details in log so I'll update wiki instructions for
windows ikev2 when I have time to test (next week).