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

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.

1
2

# apt-get install dnsmasq
# ufw allow from 192.168.42.0/24 to 192.168.42.1 port 53

pptpd

The default configuration installed by pptpd only needs a couple of customisations, and the creation of a password file.

Install the package:

1

apt-get install pptpd

Update /etc/pptpd.conf to specify local and remote addresses.

1
2

localip 192.168.42.2
remoteip 192.168.42.250

The localip will be assigned to the ppp0 interface created by pptpd. The remoteip value can specify a range of addresses; as I’m only supporting a single client, I’ve only listed one.

(Optionally) update /etc/ppp/pptpd-options to return the address where dnsmasq is listening.

1

ms-dns 192.168.42.1

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

# Secrets for authentication using CHAP
# client    server    secret      IP addresses
username    pptpd     password    192.168.42.250

Open the firewall and start the service:

1
2

ufw allow 1723
service pptpd start

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

tell application "System Events"
  tell network preferences
      tell current location
          tell service "My VPN"
              connect
              tell current configuration
                  repeat until get connected = true
                      delay 1
                  end repeat
              end tell
          end tell
      end tell
  end tell
end tell

do shell script "route change default 192.168.1.1" with administrator privileges

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.

Next Steps

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 managing /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.