I’ve had a pretty solid IKEv2 VPN connection installed on my iPhone that allows me to administer my home network from wherever, using my iPhone. Love it! It’s super simple to use, and I never have to do anything beyond a simple ssh shell, so it’s perfect for my needs.
I’ve never had any issues with the connection until recently when I installed the iOS 13 beta, and it looks like Apple has changed their security requirements for certificate signing: https://support.apple.com/en-us/HT210176
Whenever I try to connect through the VPN, my iPhone says “User Authentication Failed”, but no errors pop up in my router’s log. The ikev2 connection is established, and an IP is provisioned. So it seems like the phone is cutting the connection off. FWIW, I’m using an RB2011.
And although the newest routerOS versions are set up a little differently than back when that guide was written, the config is the same.
I can not figure out what to change/update, however, to get my VPN tunnel to work again. When I generate and self-sign the certificate on my router, the default encryption is RSA, and the encryption proposal in “ipsec/ proposal” is sha256. From the little that I know about certificates, it doesn’t look like anything major has changed for Apple? At least, nothing that would break my VPN tunnel.
Has anyone else run across this issue? Is there something I can do to re-issue my VPN certificates with the proper encryption? Thanks in advance!
That tutorial is pre-6.44/6.45 and has a lot of irrelevant commands now that they’ve redone the IPSec stuff a bit in RouterOS.
Here’s a presentation from someone who gave this at Malaysia MUM 2019. I followed this and got it working 100% with these instructions (though I’m on iOS 12).
Also, for the router logs, you want to specifically go in and enable logging (System > Logging) to memory for ipsec and debug but add !packet also (in the same entry) so it doesn’t flood the memory with packet debug info.
If I had to guess, your certs probably expire after 10 years (3650) instead of 825 days or less.
Cool, thanks for that link! I’ll check it out and re-hash my config to fit (no pun intended). My certs are all valid for only a year, so that requirement is taken care of, however. Hopefully it comes down to just a bug in the iOS beta.
Finally got around to re-doing my IKEv2 implementation with this guide, and it definitely works now. However, the client (iPhone) disconnects after a few minutes. I think it’s after the same amount of time, every time. Any chance you could point me in the right direction for an issue like this? I’m sure it has something to do with how iOS manages re-authentication, but I am not as familiar with the protocol as I’d like to be. No worries either way, thanks!
Huh, that’s interesting! The 8-minute timeout was happening for me even with the common name settings applied to the certificates (and re-issued). The solution for me was to change “PFS Group = none” to “PFS Group = modp2048” in the IKEv2 proposal. With this applied, I can watch the ipsec logs and see that re-keying happens successfully, which it never did before. For some reason, iOS 13 allows an initial successful authentication even with mis-matched proposal and mode configs. Is your proposal set to PFS Group = none?
I had been beating my head against the wall trying to figure this out. Great that iOS now supports PFS—but not so great that it wasn’t openly advertised. Works great now—thanks for sharing.
Shoot, I thought that might fix it, but no dice. Can you explain why the encryption algorithms might have an effect on the length of time the client is authorized for? That might help me finally figure this out. Thanks!