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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
