[strongSwan] Upgrade issue

[Peter Sagerson]

Hi Tobias,

Thanks for getting back to me. I should have mentioned that the different keyids are just an artifact of the automatic process we have for provisioning clients. I've gone back and used the same identity on both servers just to be sure, and see the same results. I've also been trying to clean up anything in the logs that looks like a warning, such as not finding CRLs.

I'm attaching the full control+controlmore logs from both versions in case anyone's interested (IP redacted). A diff shows them effectively identical until after the "full match" lines. Perhaps you could interpret the "no match"/"full match" lines for me? Is it significant that 4.5.2 lacks the "offered CA:" line? Is there a document that I haven't found describing the necessary and sufficient conditions for a connection to be considered "suitable" for a peer? (Connection matching looks like a dark art from the outside). I'm trying to think of specific and useful questions to ask so I'm not just dumping logs on someone and hoping for a solution.

Thanks,
Peter


| unref key: 0xb7b9ccf8 0xb7b9dc40 cnt 1 'C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=test at example.com, 55:04:2e=285c05bfc6341f1e1c4d65fa3d28d87f'
|   ref key: 0xb7b9d4f8 0xb7b9daa0 cnt 0 'C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=test at example.com, 55:04:2e=285c05bfc6341f1e1c4d65fa3d28d87f'
| XAUTHInitRSA check passed with keyid d3:0b:d6:8d:7c:8d:8a:3b:a2:65:63:ef:a1:6a:39:4a:4c:24:88:a3
|   ref key: 0xb7b9d4f8 0xb7b9daa0 cnt 1 'C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=test at example.com, 55:04:2e=285c05bfc6341f1e1c4d65fa3d28d87f'
| peer CA:      "C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=Cloak Public IPSec CA"
| requested CA: %any
| ipsec:  no match (id: no, auth: ok, trust: ok, request: ok, prio: 2048)
| ipsec: full match (id: ok, auth: ok, trust: ok, request: ok, prio: 1216)
"ipsec"[2] xx.xx.xx.xx:223 #2: no suitable connection for peer 'C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=test at example.com, 55:04:2e=285c05bfc6341f1e1c4d65fa3d28d87f'
"ipsec"[2] xx.xx.xx.xx:223 #2: sending encrypted notification INVALID_ID_INFORMATION to xx.xx.xx.xx:223



-------------- next part --------------
A non-text attachment was scrubbed...
Name: strongSwan-4.4.0.log
Type: application/octet-stream
Size: 12459 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120326/9fbf995d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: strongSwan-4.5.2.log
Type: application/octet-stream
Size: 13082 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20120326/9fbf995d/attachment-0001.obj>
-------------- next part --------------



On Mar 26, 2012, at 9:49 AM, Tobias Brunner wrote:

> Hi Peter,
> 
>> With 4.4.0, this works great; here's a relevant snippet from pluto.log (after all the certs have checked out):
>> 
>> | XAUTHInitRSA check passed with keyid 08:f4:bf:b9:2d:e8:da:89:48:51:70:dc:1a:e8:a8:93:33:02:a1:3c
>> ...
>> 
>> Now when I use the same config on 4.5.2, I get a slightly different and less encouraging result:
>> 
>> | XAUTHInitRSA check passed with keyid d3:ab:cf:e0:aa:0d:4d:c3:9c:19:d0:6c:7f:99:9b:a5:04:b4:d1:75
>> ...
> 
> The logged keyid is different.  Did you also change the certificates?
> 
> Try adding 'controlmore' to plutodebug, this should give you more
> information when pluto tries to find a suitable connection.
> 
> Regards,
> Tobias