Road Warrior Setup: PPTP

Although SSH is pretty useful for occasional connectivity, it's not intended to be a VPN and it's a bit limiting for doing file shares and more advanced connectivity.  I decided to look into setting up a VPN on a Windows Server running on my home network, however, several firmware versions out there support PPTP, such as DD-WRT.  Scott Hanselman has a blog post about that here.

Before I dive into the details of this post, I want to point out that I'm not interested -- at least in these posts -- of debating various potential security issues of any VPN protocol.  Certainly security is a HUGE concern, as it should be, but I'm primarily interested in the technical setup and feasibility of these options from a road warrior's perspective.  Perhaps in a future post, I'll dive into potential issues and pitfalls with various protocols.

My first attempt was to use PPTP by configuring RRAS (routing and remote access) -- this was for a few reasons: 1) my firmware (Tomato) doesn't support a PPTP server;  2) A VPN is CPU intensive, and the router becomes a bottleneck, and 3) for modularity reasons, I want the router to do just _route_, not function as a server.

On my Windows 2003 Server box, I configured RRAS (Control Panel -> Administrative Tools) by right clicking the computer name and selecting Configure Routing and Remote Access, and selecting VPN from the options:



The rest of the options are very straightforward and simple.  There are a few prompts for selecting the network interface, and determining whether you want RRAS to dish out IP addresses, or have your DHCP server (presumably your router) do it for you.  In my case, I had RRAS do it, and I selected a predefined range within my subnet.  When done, RRAS is up and running.

Users will need to be explicitly granted permission; since this is a road warrior setup, presumably the users are set up locally -- obviously this could done via Active Directory within a domain environment as well.  Here, I'll just grant access to MyUsername by selecting the 'Allow access' radio button:



On the client side, setup is even easier.   We'll just go into the Network and Sharing Center from the Control Panel, and select 'Connect to a network' under Tasks:



On the following screen, there's a list of all known networks -- we'll select "Set up a connection or a network" on the bottom of the dialog box, and we'll select 'Connect to a workplace' on the next screen:



The rest of the options are very straightforward.  We'll create a new connection, and we can also configure whether we want to dial in or use the internet (which is what I'm assuming).  We'll also set up the address of the server (more on this later) and username/password.  Once this is set up, we have a nice icon in our Network Connections menu that makes connecting a breeze.

Here's where the tricky part comes in.

First, to test out the functionality, we can certainly connect while we're locally connected by using the private IP of the server, for example, 192.168.1.2.  Of course, this won't work on the internet.   You can set up a DDNS (dynamic DNS) name, or memorize your IP address to connect to your home router once you're on the internet (and hope is doesn't change) -- most people use a DDNS service and in fact, most routers include the ability to update the DDNS if the IP address changes. 

This is the part where PPTP falls apart for most consumer grade equipment.  The default TCP port for PPTP is 1723.  However, and from a 50,000 foot level, PPTP uses GRE (Generic Routing Encapsulation), or IP Protocol 47, to tunnel the data.  This represents a number of difficulties -- most notably, that it's very difficult to use in a NAT environment (particularly on consumer equipment). 

If all you're ever interested in doing is connecting INTO your network from a remote location, you can configure the router to forward the appropriate packets to the server.  Most routers offer port forwarding for TCP/UDP (in which case, we can configure port 1723 to be forwarded to our server's internal IP address), but GRE is a bit more difficult.

If you log into the router using telnet or SSH (see my previous post on using SSH), you can configure the firewall/router directly -- this is assuming, of course, the router is running Linux and, if it is, most likely it's using Netfilter/iptables.  We can configure iptables to accept the incoming 1723 and GRE (proto 47) packets, and forward them to our server by executing these commands:

iptables -t nat -I PREROUTING -p tcp --dport 1723 -j DNAT --to 192.168.1.2:1723
iptables -I FORWARD -p tcp -d 192.168.1.2 --dport 1723 -j ACCEPT

iptables -t nat -I PREROUTING -p 47 -j DNAT --to 192.168.1.2
iptables -I FORWARD -p 47 -d 192.168.1.2 -j ACCEPT

This assumes our server is running at 192.168.1.2.  If you've ever set up port forwarding on your home router, essentially this is what it's doing.  The first two lines simply accept incoming TCP requests bound for port 1723, accept the request, and forward it internally.   The last two lines do the same thing, but for all protocol 47 packets (GRE).  As far as I know, this is the only way to do this reliably, unless you can set up further restrictions (such as source IP address), but this is difficult to do for a road warrior.

Now, if we try connecting from the outside, we should be able to connect fine.  Of course, executing these commands each time the router reboots is a bit painful, but many firmware versions support initialization scripts, so it's easy enough to do automatically.

The downside to this approach is connecting to another VPN once inside the network.  For example, connecting to my corporate network uses PPTP, so I'd need to disable my GRE forwarding while home.  In addition, GRE requires special NAT helpers and may not work in some hotspots or, for example, using internet connection sharing on a mobile phone.   If your router's firmware supports a PPTP server directly, some of this hassle is alleviated, however, it won't solve problems connecting from some hotspots or from some mobile devices.

So while PPTP is easy to configure and use -- I really like that it's so simply integrated into my network connections and requires no additional software for either the client of server -- it's not a very robust solution for a road warrior.  You need a backup plan, such as SSH.

Next up, I'll check out what's involved in setting up OpenVPN.
Comments are closed

My Apps

Dark Skies Astrophotography Journal Vol 1 Explore The Moon
Mars Explorer Moons of Jupiter Messier Object Explorer
Brew Finder Earthquake Explorer Venus Explorer  

My Worldmap

Month List