First things first: PPTP, as a protocol, has a number of serious security issues. As a general rule, don’t use it. I’m aware of the risks, and am accepting them for this implementation.
PPTP’s main advantage is that it’s very easy to configure. I briefly investigated the state of IPsec/L2TP, and found a lot of advice to build things from source because the distro packaged versions are too old. That’s fine advice, but I wanted to get something started quickly. Once I’ve built a build box, I’ll be revisiting this decision.
Dnsmasq is a forwarding resolver that also answers queries based on
the contents of
/etc/hosts. This is a simple way of providing
resolvable names for VM guests, and it seemed appropriate to use it
for the VPN.
The default configuration is a good starting point.
The default configuration installed by
pptpd only needs a couple of
customisations, and the creation of a password file.
Install the package:
/etc/pptpd.conf to specify local and remote addresses.
localip will be assigned to the
ppp0 interface created by
remoteip value can specify a range of addresses; as I’m
only supporting a single client, I’ve only listed one.
/etc/ppp/pptpd-options to return the address where dnsmasq is listening.
Use a long, random string for the password. Specifying the IP address is optional – an asterisk would have the same effect here.
1 2 3
Open the firewall and start the service:
I read several HOWTO’s when setting this up, but none was quite what I needed. I imagine that others will have the same problem with this one, so I’ll recommend the pptpd manpage.
OS X VPN client
At that point, everything was ready to connect the client. Not coincidentally, that’s also the point where frustrations emerged.
The basic OS X configuration is simple – add a new VPN connection in Network Preferences, enter address and authentication details, and hit Connect. I did that, the connection came up, and I was able to ping other hosts on the NAT network (192.168.42.0/24).
However, the resolver configuration hadn’t been updated with the nameserver specified by PPP. It appears that this is governed by the order of the connections in Network Preferences – the resolvers specified by the first active connection will be used.
After re-ordering the connections to place the VPN first, my client started resolving via the dnsmasq server. This was good.
Unfortunately, it now also changed my default route to point over the VPN. This was less good.
Beyond the fact that it wasn’t necessary (and slowed down my web browsing), hitting Google via the VPN gave me the Russian language page.
The Advanced settings for the VPN connection have a checkbox, “Send all traffic over VPN connection”. It turns out that OS X will create a default route to the connection whether or not this is set – it merely increases the routes priority. ie, if the VPN is first in the list of connections, it is already at the highest priority and the checkbox has no practical effect.
The Current, Grudging Solution
A post on SuperUser offered an AppleScript to connect a VPN, then adjust routing. My slightly tweaked version looks like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Using this to bring up the connection, I end up with a resolver pointing to dnsmasq, and a default route via my home router.
It’s not ideal. If I forget to use the script and instead connect the “normal” way, my routing is broken. If I do use the script, I’m confronted with a dialog box requesting an an administrator password.
Adding insult to injury, the dialog box doesn’t have focus when displayed.
Giving up the use of dnsmasq for the VPN connection would neatly
sidestep the issues above, and I’m tempted to do just that. Manually
/etc/hosts wouldn’t be too onerous in this case.
As noted above, I’m planning to implement IPsec/L2TP before long, and I’m holding out hope that OS X will deal with default routes differently for those connections. Not a lot of hope, but it’s there.