How to Build Secure VPN Between iOS and OS X with OpenVPN

GuizmoVPN on iOS requires the iOS device to be jailbroken. This is an unfortunate limitation since iOS can't be jailbroken. And it is becoming much more difficult going forward to jailbreak iPhones as Apple beefs up iOS security.

Hopefully, Apple can implement OpenVPN in iOS natively in the future.

You can now use OpenVPN natively on iOS devices: https://itunes.apple.com/app/openvpn-connect/id590379981

Apple's own VPN server is using the open-source Racoon software. I have discovered this can be configured to use Cisco IPSec rather than L2TP or PPTP. See http://blog.dest-unreach.be/2011/03/03/iphone-compatible-ipsec-vpn-on-an-ubuntu- server-with-ldap-authentication

It appears that Racoon can also be configured to use certificate based authentication rather than MS-CHAP see http://bsdsupport.org/configuring-racoonipsec-tools-to-use-x509-certificates/

Therefore by (manually) configuring Racoon to use Cisco IPSec and certificate authentication it should be possible to achieve the same goals as the above mentioned OpenVPN solution but to do so without the need to use an additional thirdparty VPN client. Furthermore this should work for both iOS and OS X clients.

If I am right and please correct me if I am not, then this would seem a preferable solution to OpenVPN. Would anyone be able to write up detailed instructions for implementing this on a Mountain Lion Mac?

PS. Clearly the best option would be for Apple to build into Server.app this as an option.

Hello,

First of all, your article helped me greatly in setting up my openVPN server. Thanks!

I'm currently using pfctl instead of ipfw, and running into issues configuring the NAT configurations to correctly forward packets from the VPN to the local network and the internet.

Ive attempted to mimic what

natd -interface en0

ipfw add divert natd ip from any to any via en0

is doing by adding the following in pf.conf below "nat-anchor "com.apple/*"

nat on tun0 from any to any -> en0

Is there something I'm missing or doing wrong? Any help would be appreciated.

Or you might want to just try a different VPN server (pfSense is open source, rock solid and plays well in a Mac-centric environment). I've put up an article on this topic that I hope will help others:

see Setting Up an iOS 7 On-Demand VPN

For what it's worth since my previous reply on 9th Feb 2013 I have now got a fully working and deployed solution running.

I was able to get Racoon working with certificates for iOS clients but when I extended this to include VPN on Demand I discovered that Apple would not let you save the password. I therefore switched to using StrongSwan5 and Xauth-noauth to disable the username/password authentication leaving just the certificate authentication. It was then possible to use the built-in IPSec client, a certificate, VPN on Demand and not get nagged each time for a password.

My own write up is here http://jelockwood.blogspot.co.uk/2014/03/how-to-do-vpn-on-demand-for-ios-at-zero .html

Actually, the instructions I've put up tell you how to have IPSec running, including "on-demand" without the user having to enter a password every time the VPN connects -- see and search the page for "having to enter" and you'll find the detail -- and you can "track back" from there, depending upon what you're using.

BTW, your requirement point 3 is not true. I also was under the impression that a device had to be "managed" before you could use the VPN on-demand capabilities. However, it seems that's not true. My instructions omit the step of making a device managed (though it's a nice capability, for a small number of units, it's a serious "pain" and a huge amount of overhead -- but a boon for enterprise-level use, I'm sure).

I agree that Apple could do better at making VPN on-demand work more easily, especially in the case of an all-Apple environment (which we try to be).

In the end, what I found is that OpenVPN works far better than IPSec, at least for mobile (we continue to use IPSec for an always-on inter-office VPN). One of the things I liked about OpenVPN is that you can have a series of servers on different ports in case the network the mobile is on is blocking ports. The clients will then try all servers in round-robin sequence. In our case I set up 4 UDP servers (best for performance) with a final one being TCP:443. Since that looks like HTTPS (unless you start seriously inspecting traffic/patterns), it's unlikely to be blocked -- and if it is, maybe you don't want to be on that network. #;-)

It's interesting how close your solution appears to be to the one which I also developed. A case of "great minds think alike" ... or just "idiots seldom differ?" BTW, if you're interested in adding an "Alternative Solutions" heading I'd be interested in adding the same and we could cross-link our articles. After all, it's all about being connected! <sic>

<Link Edited By Host>

It is true you don't have to enrol a device to an MDM but you do need to use a profile which could in theory either be totally written by hand or more likely initially produced by something like iPhone Configuration Utiltiy. This produces a mobileconfig file which is basically an XML plist file containing the settings for in this case -

• Certificate to use for the VPN connection
• VPN configuration
• VPN on Demand settings

I see you are using Apple Configurator

I have seen of course your article suggesting using OpenVPN and a couple of others but I have been somewhat puzzles by this as it is not one of the VPN types listed by Apple as being supported. The ones listed by Apple are the built-in Cisco IPSec client which I used, or Cisco AnyConnect, and several SSL solutions including Cisco, Juniper, SonicWall, F5.

Are you using OpenVPN as a Cisco IPSec compatible VPN server? If so I don't know how it can use multiple ports. Is it instead acting as a Cisco AnyConnect compatible system? (Which uses SSL.)

I see you are getting round the Cisco IPSec password issue in a different way but actually hand editing it in to the XML plist like the following.

add the following entry to the IPSec dict(tionary) section:

<key>XAuthPassword</key>
  <string>myVPNuserPassword</string>

I had not seen this documented elsewhere, it is not in the official Apple document. This is a different approach to what I used and has the advantage of keeping two levels of authentication i.e. certificate and password, but requires either you not to change the password, or to have to regularly install a new mobileconfig file. My approach has the advantage of not needing to be updated for password changes. Personally I think what Apple should do is not require the username and password to be in the mobileconfig, to allow these to be entered and saved by the user, and when the password is changed and therefore no longer valid to re-ask and re-save the new password - just like a normal setup works.

Re: ... but I have been somewhat puzzles by this as it is not one of the VPN types listed by Apple as being supported.

---

Well, the free OpenVPN Connect app is supported -- it's just not documented by Apple (at least in any technical documentation I've seen from Apple). [getting on the soapbox] While Apple tends to be exemplary at developing good software architectures, they're absolutely terrible at producing good (i.e., complete) release notes and some kinds of technical documentation. [stepping off the soapbox] According to some posts on the OpenVPN forums, a part of the OpenVPN team is working closely with Apple (non-disclosure close), so that's good.

Though it won't be complete for another couple of days, if you look there's already enough there to see how to support the OpenVPN Connect VPN type. All the hardware, software and documentation I've used is documented on

http://www.derman.com/blogs/VPN-Hardware-and-Software-Used

Hey, I know there's a lot of stuff there, but I'm trying to be complete and rigorous (e.g., the graphics and examples should be consistent across the collection, etc.).

Yeah, I don't even remember how I came to the

XAuthPassword

Re: Personally I think what Apple should do is not require the username and password to be in the mobileconfig ...

---

I'm guessing this is due to conforming with the "Cisco way."

FYI, with OpenVPN you can have only account (username/password -- without on-demand, of course), only certificate (with on-demand) or both account and certificate (with on-demand) for authentication. You can also force a check to ensure that the user certificate is the same as the one associated with the user's account and that the root certificate is validated within a certain number of levels. As I said, OpenVPN seems to excel in almost all aspects.

Re: ... allow these to be entered and saved by the user, ...

---

Yeah ... it seems like of those "du-oh" things. Can't imagine what the reasoning is, but having to manually enter a password for every on-demand connection in many usage scenarios would only encourage the user to either turn off the VPN or get frustrated enough to destroy the phone. $;-) However, having said that, I've been a software developer for over 35 years and learned a long time ago that there are often very valid reasons for things where those reasons are not obvious until you get down to the details. When confronting such things with the people responsible, I generally use the "Can you help me understand why ... is so?" approach, as opposed to the "Well that's stupid!" approach. Of course, I'd have to admit to dining on some foot and some crow before I got to that approach. #:-)

Re: I may receive some form of compensation, financial or otherwise, from my recommendation or link. <Edited by Host>

---

Yes, we do run some (non-animated) ads on some parts of our sites to help defray the costs. However, that's not the reason for putting up the information -- if it was, I'd be working for fractions of a cent per hour. Spending the dozens of hours it's taken to put together and put up the information is really just trying to help others avoid having to spend so much time. I appreciate it when others "share" and, as I have time, try to do the same in return. Thanks for considering the value of the links and not just deleting the comments outright.

<Link Edited By Host>