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=t...@example.com, 55:04:2e=285c05bfc6341f1e1c4d65fa3d28d87f' | ref key: 0xb7b9d4f8 0xb7b9daa0 cnt 0 'C=US, ST=Washington, O=Bourgeois Bits LLC, OU=Cloak, CN=t...@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=t...@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=t...@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
strongSwan-4.4.0.log
Description: Binary data
strongSwan-4.5.2.log
Description: Binary data
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
_______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
