Currently Being ModeratedSep 21, 2012 8:56 AM (in response to Yukiru)
Interesting detail: If I disable NAT traversal (by setting "nat_traversal = no" in ipsec.conf), the VPN connection get's established (without letting me on the othervise NATted servers, of course, so it's no solution).
Currently Being ModeratedSep 22, 2012 12:33 AM (in response to 3g91ld3a)
Hi to all...
Problem solved! Because OSX and IOS have the same problem, i dived into the deep of IKE and found
The problem is, that the new IPSEC system has problems with handling "big" certificates (search for
IKE UDP fragmentation, if you are interested in).
So, the solution is quiet simple- create a certificate with the absolute MINIMUM of the required data
(for Example: C=AT, CN=HS, E=hs). I tested only with 1024Bit Public Key size- and this works on
IOS and OSX as well.
Currently Being ModeratedSep 22, 2012 1:15 AM (in response to haraldfromenns)
Thanks for the tip, but I don't know how to handle this from within Keychain Access. Could you tell us a bit more, please ?
Currently Being ModeratedSep 24, 2012 6:27 AM (in response to christophefrom25)
This could NOT be solved within the keychain.The certificate has to be issued in a way, that its size
is so small, that it will be not fragmented during IKE negotiation.
If your certificate is issued by an IT administrator, tell him, that You need a certificate, where the
required fields (normally EMail and Common Name) should be as short as possible to reduce
the size of the certificate.
Currently Being ModeratedSep 24, 2012 6:32 AM (in response to haraldfromenns)
Currently Being ModeratedSep 24, 2012 7:46 AM (in response to haraldfromenns)
Ok, thanks a lot for your answers.
Currently Being ModeratedSep 25, 2012 8:45 AM (in response to haraldfromenns)
Thanks for this workaround!
Next problem: Safari doesn't resolve .local DNS names via VPN (under iOS 5.1, it did). Thanks again to M$ for proposing .local as default :-(
Currently Being ModeratedSep 30, 2012 5:18 PM (in response to 3g91ld3a)
You can use "crypto isakmp fragmentation" command on yours Cisco VPN router.
It's enough to resolve problem.
Currently Being ModeratedOct 1, 2012 8:40 AM (in response to Anisim)
Does somebody know an equivalent solution for VPN routers running StrongSwan?
Currently Being ModeratedOct 3, 2012 3:23 AM (in response to cpohle)
Yes, just create a certificate with 1024bits or less. That helps. Got it working with this.
And use XAUTH in your ipsec.secrets.
Currently Being ModeratedDec 12, 2012 6:31 PM (in response to haraldfromenns)
Harald, thanks for your work in finding the cause.
Has anyone heard news if this will be fixed in the client? I'm sure I'm not the lone voice in the wilderness that believes 1024-bit certificates to be inadequate. Especially since earlier OSX versions did not have suffer from this limitation.
Currently Being ModeratedFeb 2, 2013 3:30 PM (in response to 3g91ld3a)
Anyone still watching this thread, I posted the following two discussions in hopes of getting attention of someone internally on the team.
Currently Being ModeratedFeb 3, 2013 5:28 AM (in response to 3g91ld3a)
Yes, I am still watching this thread!
For every OSX update released I'm hoping for a fix for this bug, but so far nothing.
Poorly managed Apple!
What is even more annoying is that it was an Apple update on OSX 10.7 that forced me to rebuild my internal PKI infrastructure from 512 to 2048 certificate Key Size:
(After this update, certificates with a Key Size less then 1024 was rejected)
Currently Being ModeratedFeb 24, 2013 2:02 AM (in response to beamzz)
Hi, i have the same problem, and debugged it in depth.
I use 2048 bit ssl certs.
Iphone and ipad both work with these certificates, so there must be a difference in the racoon source.
First i enabled the debugging at file: /etc/racoon/racoon.conf
(be sure,that racoon is not running, or you will get err (61). Reboot to fix)
path logfile "/var/log/racoon.log";
did as root:
chown root:admin /var/log/racoon.log
chmod 640 /var/log/racoon.log
So the error at the end after hashing the cert:
2013-02-24 10:48:51:  DEBUG: hmac(hmac_sha1)
2013-02-24 10:48:51:  DEBUG: HASH (init) computed:
2013-02-24 10:48:51:  DEBUG:
4c36a99e e9ddb045 03d54006 92b5c9ff c9732e72
2013-02-24 10:48:51:  ERROR: error -25308 errSecInteractionNotAllowed.
2013-02-24 10:48:51:  ERROR: failed to sign.
2013-02-24 10:48:51:  ERROR: failed to get sign2013-02-24 10:48:51:  ERROR: failed to allocate send buffer2013-02-24 10:48:51:  ERROR: failed to process packet.
2013-02-24 10:48:51:  ERROR: phase1 negotiation failed.
2013-02-24 10:48:51:  DEBUG: IV freed
The CA cert and the client are are trusted. (verified in the keystore, showing valid cert)
I also played around with turning dpd off, and ike_frag to on.
No change. Seems like the dog bytes in his tail.
Any updates in this issue ?
Currently Being ModeratedApr 5, 2013 1:41 PM (in response to Frankenburger)
If you're still having this issue, find the corresponding private key in your keychain, double click it and select the "Access Control" tab. These settings may be preventing racoon from accessing your private key which causes the error you are seeing.
Hope it helps