VPN Enabler for El Capitan
Setting up the VPN Server
De-Installing VPN Enabler
3.0 October 6th 2015. VPN Enabler for El Capitan released. I coundn’t get the VPN Server to authenticate the client using MSCHAP2 on El Capitan. So, in order to have something usable on El Capitan again, I downgrade the authentication protocol to PAP, whereby passwords are sent in the clear. Obviously not so good.
3.0.1 October 8th 2015. I’ve got authentication using MSCHAP2 working again, so the authentication process cannot be snooped. Download this version and do a De-Install from the Help menu to get things working again the way it should.
3.0.2 October 10th 2015. VPN Enabler now supports PPTP, for those needing to support devices that don’t work well with L2TP. Thanks, Gordon Aspin, for sharing :) Currently, VPN Enabler allows you to set one or the other protocol, but not both at the same time. Also, you can now generate mobile config profiles for PPTP (but of course). I love this one-click way of setting devices. Must import the technique into my other “enabler” apps. This version also brings back the ability to sign the mobileconfig profiles, if you have either a real cert or a test cert in /usr/local/cutedge/ssl (as you would have if you’re using the other “enabler” apps, like MailServe or WebMon).
3.0.3 October 13th 2015. Some minor bug fixes. Added info about forwarding port 1723 for PPTP. If you’re lucky with the router, you can skip this step entirely.
3.0.4 October 15th 2015. Fixed a bug with the de-install process, whereby the login dialog box makes a strange re-appearance.
3.0.5 July 18th 2016. Minor bug fixes.
3.0.6 August 12th 2016. VPN Enabler had a bug whereby if a user, when asked to choose a name for the VPN User, enters the name of the admin user he is currently using to log on to his Mac (he is supposed to enter a name that has not been used at all and it will be created as a non-admin account, because you don’t want to log on to your VPN as an admin user, from any device, anywhere in the world). I had actually checked for this, and in most cases the check will work (i.e., VPN Enabler won’t allow you to use an existing account as the VPN User). But there is one case where the check will fail – when the user enters an admin account name that has capitals in it. I had assumed that all OS X user short names are in small letters, no caps – because that’s the way the system will set it by default when it creates a short name from a user long name. But I hadn’t known that you could go back and force-capitalise some and any of the letters. So when I check my lower-case VPN user name against the list of existing names, and I’m doing a case-sensitve Unix grep by default, it will fail to spot that a mixed-case variant already exists among the user names. The worst case is that this is the admin user, himself. VPN Enabler will then clobber his admin user’s account settings (with the settings intended for the standard, non-admin VPN user), hiding the admin user account from the login screen and changing his userID, and thus render the admin account inaccessible, unusable and locked out of his Mac. An altogether terrible situation. I’m really sorry for this bug, all those who’ve suffered from it. I’ve now fixed this in version 3.0.6, by simply doing a case-insensitive check against the existing user names, so as to find a mixed-case variant of the one that the user has chosen as the VPN User, and so protect the existing user account from damage. Thanks to Jeremy Lewis for patiently taking me through all the steps he had taken, so I can reproduce the bug.