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.
No news. I spoke with Enterprise support and they indicated there was no one, anywhere, that could help me with the VPN client, and, therefore, escalate the issue to Engineering.
So, my only hope at this point is that PM or Eng is monitoring the forums, or, someone finds a viable workaround that still uses certificates.
Interesting detail: if I connect from the LAN side to our vpn system, the ipsec connection goes up!
When I come from the WAN-Side, the connection never goes to established-state.
The error message on the server side is:
>>next payload type of ISAKMP Message has an unknown value: 132
@APPLE: you really messed something up here - please fix!
I've been able to solve this problem by copying the following three files from my last OSX 10.7 backup into the 10.8 installation:
The first file is the IPsec client binary, the second tells how to launch the client, and the third specifies what the client is allowed to do on your system.
Thanks for the idea, but it doesn't work for me.
I restored those 3 files from a Lion backup and rebooted the machine. Then the problem is worse, since launchd can't even launch racoon : "racoon: Configuration Parse Error. (cfparse: yyparse erred, filename /etc/racoon/racoon.conf). (failure: fatal parse failure)"
I also tried to restore racoon.conf and racoonctl from Lion, but with no success either ...
I ran into the same problem today while trying to fix a colleague's VPN. It turned out that he had iCloud enabled, which apparently generates a config file /var/run/racoon/<some-ipv6-address>.cfg that the old racoon doesn't understand (because it is not IPv6-ready, presumably). If you move the file out of the /var/run/racoon directory, the old client should start.
We also deactivated IPv6 on the Terminal via
networksetup -setv6off Ethernet
("Ethernet" is the network device you are using for the VPN; see networksetup -listallnetworkservices for a list). However, I am not sure if that changes anything, since we did it before moving the config file away.
And he still does have some weird problem with the server certificate not being accepted, though. On another colleague's MacBook it worked with copying the three files, and deleting and re-importing the CA certificate into the system keychain.
Hope that helps...
Yes, it helps a lot ! It (almost) works, thanks to your advices.
As you said, the problem to make the Lion version of racoon work again on Mountain Lion is the presence of those files in /var/run/racoon. (the last line of /etc/racoon/racoon.conf is 'include /var/run/racoon/*.conf')
In my case, I didn't find any .cfg file, but two .conf files. If I delete them, all is OK, but they appear again after reboot.
The first one is the one you're talking about - the "Back To My Mac" feature. I disabled it, and it's gone.
But I can't find out what is the other one. I tried the -setv6off thing on both Wi-Fi and VPN interface, but it doesn't work. I have to remove the file manually until I find the solution.
But thanks a lot for your help !
We also try, to use Cert-Based L2TP-VPN
via strongswan on 10.8.1 and also got no luck.
We have the apple-specific certificate-usage proposal (ipsec),
aswell as the DNS-name of the system built in to the certificates,
but it wont work (even without NAT/PAT).
The only thing, were not publishing is CRL's - could that be part of the solution maybe?
Anyone got CRLs published (via HTTP or elseway)?
Hi, I just update my iPhone to iOS 6, and guess what - now the IPSEC VPN does not connect anymore. On the other end of the tunnel, I have a StronSwan router, showing this
> next payload type of ISAKMP Message has an unknown value: 132
error message several times before it quits with a
> max number of retransmissions (2) reached STATE_MAIN_R2.
Thanks for any hint!