[Swan] No PARENT proposal selected

Bob Miller bob at computerisms.ca
Sun Oct 11 00:12:54 UTC 2015


Matt,

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

> 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...



>
> Matt
>


More information about the Swan mailing list