I have a "road warrior" IPSec IKEv2 VPN setup that is working for me, at least when it comes to split-tunnelling. I have been trying to get it to work with a split-DNS configuration so that VPN clients only use the VPN-provided DNS servers for the local VPN DNS domain and all other DNS requests (for domains other than that) should use the client's default DNS resolver. It's the split-DNS setup that isn't working for me.
Can anyone confirm whether or not they've got this working with the built-in IKEv2 client in macOS Big Sur or newer? If so, what was the magic needed to get this working?
I use Apple Configurator to create IKEv2 VPN profiles for macOS, so I don't mind if the solution involves that.
Here is an update on this from me:
Well, it appears that split-DNS was actually "largely working" for me with the macOS IKEv2 built-in client. It was the way I was testing it that made it seem like it wasn't working at all.
"Largely working" means that resolver-based client DNS resolution works. More simply, hostname resolution works for commands such as ssh, ping, curl, etc. Where DNS resolution fails is for tools such as host and dig. These use the wrong resolver at the client side. (I had been testing with host and dig.)
Although it would be nice for everything to work, I can live with the "largely working" state right now. :)
One thing that I did actually have to do to get split-DNS (or any IPSec VPN DNS) working is to add the IPSec client network range as an explicit access list in Services -> Unbound DNS -> Access Lists. I believe this is because IPSec is not available as an interface to select in Services -> Unbound DNS -> General -> Network Interfaces, and so doesn't get included in the "Internal" access lists. Without this explicit access list entry, I was getting REFUSED responses to DNS lookups from the VPN client to the server.
PS: If anyone has any insight on how to get DNS tools like host and dig to work from the client side I'd be glad to hear about it.
I've also been wrestling with Apple & IPsec.
https://forum.opnsense.org/index.php?topic=31330.0
I read you have a working .mobileconfig that uses cert + XAuth I'd be very happy.
I was able to get IKEv2 EAP-RADIUS to work with iOS with all traffic over the VPN without a .mobileconfig file and macOS/iOS devices where each device gets its own IP based o the RADIUS User info. The key elements were:
- In FreeRADIUS Users:
- Provide the IP Address and the Subnet Mask
- In Routes, add the IP-range of your LAN
- In Mobile Clients:
- Do not provide a range in Virtual IPv4 Address Pool (if you do, it overrides the RADIUS settings)
- Provide a domain name and a list of split domain names (probably not important)
- In Phase 1:
- Connection method: default, Key Exchange V2
- Method EAP-RADIUS, My Identifier: Distinguished Name and name is the reverse resolvable FQDN
- encryption algorithms: AES256, hash algorithms: SHA1 & SHA256, DH: 14
- In Phase 2:
- set Local Network to "Network, 0.0.0.0/0" (all traffic over the tunnel)
- encryption algorithms: AES256, hash algorithms: SHA1 & SHA256
- In Firewall settings:
- Disable force gateway turned on
On the device (macOS, iOS) make sure the certificate and the 'certificate authority' certificate are installed. Make sure in macOS that they are trusted.
Are you guys using EAP-RADIUS to get these IKEv2 connection working with macOS and iOS? I decided to migrate from pfSense to OPNsense on the weekend and can't for the life of me get my VPN working following all the guides for OPNsense. I've even tried a direct copy on my config from pfSense where I had EAP-TLS working with nothing but certificates and Apple Configurator profiles but for some reason same config won't work on OPNsense.
Best progress I can make is EAP-RADIUS but the tunnels never some up after successful RADIUS authentication. I'd prefer an EAP-TLS connection but VPN logs say it is not supported on the client, which is wrong as I had it working on pfSense. This is the error I get in OPNsense VPN logs.
16[IKE] <con1|11> configured EAP-only authentication, but peer does not support it
Finally figured it out after a day of troubleshooting certificate extended usage keys. I now have EAP-TLS working through the EAP-RADIUS profile so I am passwordless with client/server certs only.