What boggles me about the VPN implementation on Mac is the massive amount of functionality that is not accessible unless you are using Apple Configurator to create a profile. Then you have to install the profile, and for any configuration change, you have to repeat the process.
For example, even though you can create a basic IKEv2 config, most of the parameters that are needed to actually make it work with a given router are not accessible except in Configurator. You cannot configure the encryption or hash algos, DH Group, group identifiers, etc.
And there is no access at all to other VPN types, such as a number of vendor-specific options, custom SSL, etc., even though they are supported.
Why can't there be advanced options for this stuff? It makes no sense.
You're supposed to be managing the deployment/delivery of Apple Configurator profiles through Server.app's MDM features. If that is in play, then the workflow looks like:
1. You navigate your device to the MDM web portal served from the Mac running Server.app;
2. the MDM portal recognizes your MAC address as a new device, and allows you to register it;
3. an MDM profile is auto-generated for you, which you download and install;
4. the MDM profile transparently manages/updates a real (Apple Configurator) profile, which has been customized by the MDM for any settings keyed specifically to your computer's MAC address.
Using Apple Configurator without MDM, just using Configurator .profile files, would be like using Windows Group Policy without Active Directory, just using GPO .cab files. It's possible, but just kinda silly.
> Using Apple Configurator without MDM, just using Configurator .profile files, would be like using Windows Group Policy without Active Directory, just using GPO .cab files. It's possible, but just kinda silly.
I totally agree. But let's say that I setup an IKEv2 server in pfSense on some VPS. And now I want to connect to that with my macOS VM. There's no Mac server anywhere involved. And Apple Configurator is in fact the only way to configure the macOS client.
You are assuming that every use of VPN is captured in your scenario. It's not.
And I understand MDM perfectly well. I am the CIO of a company with 350 Macs managed through JAMF. Also, nobody in enterprise who knows what they are doing uses Mac Server. It's been a toy and a joke ever since Mavericks.
But what if I need a VPN connection for somewhere else? What if I'm a consultant with a Mac and trying to connect to a Windows shop?
Why silly? In one .mobileconfig file, I created complex VPN config for my provider, with my own preferences, and loaded it without any MDM, to all my macs and iPhones.
Because, what happens when you want to update that config? Even if you're just doing it for your personal stuff, MDM means centralized push-based management.
I guess I just don't like the idea of forgetting to update a device that I rarely touch (e.g. my iPad) and then being unable to VPN home with it later when I do go to use it, from a café on vacation or something.
Much easier to just leave Server.app running on my iMac. (It's basically what Server.app is built for; it's certainly not targeted at enterprises!)
I've been trying to deploy configuration profiles containing IKEv2 VPN configs to macOS devices through MDM (Meraki SM) without success, even though the exact same profile works fine for iOS devices. There's very little logging on the device to help me diagnose the issue and it's been very frustrating.
An opaque profile file that you double click and your VPN connectivity works makes as much, if not more sense for end users than endless screens of incomprehensible parameters.
No. There are plenty of setting an end user shouldn't normally poke around in, that are still accessible under something like an Advanced button, or are an Option-click away. This should be no different.
What if I'm a consultant, with a Mac, and I need to access a client's VPN? They aren't going to change their router just for me, and they aren't going to provide me an MDM profile.
Why wouldn't they provide you an MDM profile? Lots of companies have committed in writing to ensuring that anyone with access to prod is using an endpoint registered with MDM; that comes up on self-assessment questionnaires.
The fact that opaque configuration makes it harder for randos to get temporary access to VPNs does not seem like a hardship from my vantage point of managing security teams.
> For example, even though you can create a basic IKEv2 config, most of the parameters that are needed to actually make it work with a given router are not accessible except in Configurator. You cannot configure the encryption or hash algos, DH Group, group identifiers, etc.
It seems like some of these, such as encryption, hash algorithm, and DH group, should be configured on the server side, not the client side. I know that in the IPSec world the peers are roughly equal, but in this scenario the Mac is definitely playing the role of client. Likewise, there is no ability to configure the traffic selectors, and I'd argue that there probably shouldn't be.
I agree that there should be more configuration exposed in the UI though.
EDIT: I spent about a half hour trying, unsuccessfully, to configure an IKEv2 connection on MacOS to a StrongSwan server. I suspect a configuration problem on the StrongSwan side, but the MacOS side is so opaque that it makes it hard to match up the configs properly.
EDIT2: I remember why I stopped trying to get IKEv2 working - the fact that Split-DNS is not in the protocol yet, but with IKEv1 I can use the Cisco Unity extensions to do it.
There is no such thing as a client in IPsec - only peers. Both peers must agree to the encryption and authentication parameters before the security association can form. Because of this it is crucial that you are able to adjust to match. Also, while modifying the encryption domain is probably not super likely, I don’t see a reason it shouldn’t be editable.
However, with a Mac you are most likely using the VPN in a roadwarrior scenario. In this case, I'd argue that one of the peers should decide on what encryption, authentication, etc should be used and the other peer (the roadwarrior Mac, in this case) should accept it.
In server-to-server or network-to-network scenarios, configuring both peers to match makes sense.
> other peer (the roadwarrior Mac, in this case) should accept it
The goal of proposals in not matching - it is finding minimum security both sides agree on. I would not accept it, if previously strong settings were suddenly downgraded. I, roadwarrior, have same rights and requirements as any server :)
I don’t disagree and this is why things like Wireguard are so attractive to people. But IPsec works the way it does mostly due to legacy and mostly because once you figure out the magic words it does work pretty well.
Yes, indeed, and this is what I was expecting to see in the article. Sadly not so.
I can't imagine why they've done this. I suppose that it makes sense for enterprises that setup employees' devices. But if I'm using some third-party VPN service, it's a pain. And it's a special pain if I'm not using the latest macOS release, because then there's no way to install Apple Configurator!
Another thing to consider is Apple’s convergence of macOS and iOS. For better or worse this probably makes things much easier for them in terms of code sharing and hiding advanced features from users.
You can do all that in Apple Configurator profile. For IKEv2, all crypto parameters, DH, for child SA too, perfect forward secrecy, connect on demand, EAP auth. Works for me, I use same profile for Mac and iOS.
Are there any reasonably straightforward open source VPN servers compatible with Apple’s clients? For cloud and VPS setups, I always end up mucking around with OpenVPN/Tunnelblick.
The strongSwan configuration generated by pfSense works out of the box with macOS and iOS IKEv2 support in its default config. This has quickly become my VPN solution of choice as it works without a third party app, it’s extremely quick to connect and the connection is super stable.
I found SoftEther easy to install on a bargain VPS. Supposedly it has much better throughput than OpenVPN, but I am not certain that it has had enough scrutiny to insure that it as worthy of trust as OpenVPN. Since I don't really know anything about my bargain VPS provider either, I am not using it for great privacy, I just turned it on when I imagined there was suspicious throttling, which probably didn't exist anyway. (Getting the latest cable modem model from Comcast seemed to solve more of my latency issues than opening a VPN tunnel ever did.)
More specifically, it is L2TP over IPSec on MacOS and iOS devices.
I tried the OSX VPN stuff and gave up really quickly. It all just felt really clunky, without much control.
Tunnelblick and http://www.pivpn.io/ work great. PiVPN targets Pi installations, but I found it works just fine on any modern ubuntu install. The cli tools to generate / revoke configs are very easy to use.
> straightforward open source VPN servers compatible with Apple’s clients
I wish there were so that I can have one for iOS, but I've been using OpenVPN easily since long enough on macOS that the alternatives always seem terribly cumbersome and brittle.
I've been meaning to try tinc since forever, but it won't integrate with Apple clients either.
Strongswan (Linux and FreeBSD) and iked (OpenBSD), for use with native Apple's IKEv2 clients. Don't try to use IKEv1 (1998, isakmp), its broken and old. And Apple does not provide native support for OpenVPN protocol.
Interesting - do I remember that macOS 10.12 (or maybe 10.13) was supposed to allow for per-app VPN access? Does that use this API, or something else (assuming it actually exists)? Also, quite the cliffhanger on VPNStatus, which sounds promising (any chance it could also support Wireguard?)
The Network Extension framework mentioned in the post is that API. It's been an iOS thing for a while and came to macOS more recently (10.12, I think).
It's possible to build a macOS app that manages an IKEv2 connection using the public NEVPNManager, NEVPNProtocolIKEv2 and related APIs. This also gives you full control over DH group, algorithms, dead peer detection etc.
I highly doubt it. Most vendors try to sell it as an USP and as an "it is easy because it is TLS and runs over 443 so inflexible environments will allow you to work"-type of solution which is trying to fix symptoms instead of causes.
For anyone who is reasonable at *nix configuration, setting up OpenVPN, IKEv2 or classic IPSec tunnels is not 'easier' than any SSL/TLS VPN, which makes it lose a lot of it's value vs. other VPN options.
For example, even though you can create a basic IKEv2 config, most of the parameters that are needed to actually make it work with a given router are not accessible except in Configurator. You cannot configure the encryption or hash algos, DH Group, group identifiers, etc.
And there is no access at all to other VPN types, such as a number of vendor-specific options, custom SSL, etc., even though they are supported.
Why can't there be advanced options for this stuff? It makes no sense.