![]() The NAT-T implemented by Apple is of a previous draft to what all current ipsec-tools implementations are using: However, another problem appears to stop the connection moving on to Phase 2. Unlike authentication with SSL certificates, the PSK definitely succeeds in completing the Phase 1 negotiation. When I get a moment I'll try to set up a connection with PSK just for grins, to see how this may complete. I don't have the time to start patching the OSX kernel just for this use case, so we'll have to wait and see what Apple may come up with in the future. Linux doesn't have these problems when using racoon as a VPN client. The Apple Mac logs complained that the kernel is not configured to deal with esp_frag, although racoon was reading and modifying the packet sizes. So it seems to me the problem is caused by the way OSX fails to deal with packet fragmentation with ESP and NAT-T. ![]() ![]() Message 6 would not complete no matter what MTU and esp-frag values I used. This had a direct effect on how much of the certificate(s) would be transmitted on messages 5 and 6 before the connection failed. I experimented with different MTU values and also set esp_frag in the racoon configuration file. The exchange of certificates would not complete according to the Netvanta logs, although the Apple Mac logs showed it reaching exchange of message 6. I found out the connection would fail on the exchange of message 5 between the two peers when using SSL certificates. I looked at the logs and ran tcpdump on the Apple Mac to check the packets exchanged between the peers. However, the connection failed in a similar fashion like the iPad mentioned above in this thread. Then I changed the include directive in the default /etc/racoon/nf to read the new config file. To set all this up I had to copy /var/run/.conf to /etc/racoon/ in the Apple Mac and modify its parameters accordingly. I tried connecting to a 3120 VPN, on main mode, no xauth, with SSL certificate authentication. I managed to get my hands on a MacBook Pro, running OSX El Capitan. Once each peer's ID is exchanged and verified as matching the specified configuration at both ends, you should see the Phase 2 negotiation taking place (Quick Mode). Play around with this until Phase 1 succeeds. If you use the subjectAltName field take note that you may need to change local-id and remote-id to correspond to the type of ID shown in the subjectAltName, e.g. Of course replace the content of asn1-dn between the "double quotes" in the line above, with the full DN field of your client certificate. Can you try something like:Ĭrypto ike remote-id asn1-dn "C=US, ST=blah-blah, O=some_org, CN=" ike-policy 199 crypto map VPN 199 xauth nat-t v2 force You have defined your ike remote-id as fqdn "*." in your configuration. This is when the IKE IDs are sent and verified by each end point. Your connection fails at the last stage of the IKE negotiation between peers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |