Cisco Router as a PPTP VPN Server

It’s not often that I end up writing things about networks. Especially as my network credentials only stretch as far as a Computer Science degree and a CCENT. However, I thought it might be worth sharing how you run a PPTP VPN server on some Cisco IOS devices.
First thing you need to be sure of is that your firmware and licence supports this. If you don’t have that sort of thing lying around, I’d recommend making use of the PPTP server available on Linux systems. It’s what we used before we were given an old router to experiment with.
Once you’re sure you’ve got the required bits, it’s time to crack on with the configuration. Log into the router and enter enable mode.
If you haven’t already, it might be worth enabling service password-encryption. This will encrypt any passwords you configure on the router. Turns out this is a big deal in our case as we’ll be using local authentication for simplicity.
Talking of which, let’s set up those user accounts right now by running the following commands:

configure terminal
username foo password bar

While we’ve used “foo” as a username and “bar” as a password, I’d highly recommend you pick something a lot stronger. Oh, and best change it regularly as well.
It’s also best practice to give each user a different username and password combination. In fact, it’s better to use something like LDAP/AD and a fully featured PPTP server. We’re just setting this up as an experiment.
Anyway, the next step is to set up a pool of IP addresses for VPN connections to use:

ip local pool PPTP

You’ll need to adjust this to match your own local IP address space. Cut and paste without thinking here won’t work.
Now that we’ve got some user accounts and some IP addresses, let’s start setting up the actual VPN. The following is a good place to start:

vpdn enable
vpdn-group 1
protocol pptp
virtual-template 1

All this does is enable PPTP. It’s doesn’t actually configure it on an interface or set up encryption. To do that, you’ll need the following commands:

interface Virtual-Template 1
description Demo VPN
ip unnumbered Dialer0
peer default ip address pool PPTP
no keepalive
ppp encrypt mppe auto
ppp authentication chap ms-chap ms-chap-v2

Note that the virtual template numbers must match for this configuration to work. Either way, that’s a lot of commands so let’s go through what they do.
The first two commands are simply setting up the template for PPTP connections your users will be making.
The ip unnumbered Dialer0 line configures which interface the PPTP service will live on. In our example, it’s the ADSL interface (Dialer 0). You can make this any appropriate world-facing interface on your router.
The peer default ip address pool PPTP line tells the PPTP service to use the PPTP IP address pool we set up earlier.
The no keepalive is as you’d expect. No “keep alive” packets are sent.
The ppp encrypt mppe auto line is one you’ll want to think about though. It configures MPPE encryption on on VPN connection. Used as we are, it allows the other end to dictate the encyption level. This include no encryption at all.
A more secure option is ppp encrypt mppe 128, forcing 128 bit encryption on your VPN connections.
You can specify a specific level of encryption to use instead but the catch is that no all devices will necessarily support it. That means you’ll need to think about who and what you’re willing to support with VPN connections.
The final line of interest is ppp authentication chap ms-chap ms-chap-v2 which specifies which authentication methods you’ll allow. While it is possible to allow PAP authentication, I’d recommend against it.
The reason for this recommendation is down to how the two systems work. PAP sends a username plus optionally encrypted password to the server. If no encryption is used, the passwords are sent plain text.
The CHAP system requires the server to generate a random “challenge” and send it to the client. The client then uses this “challenge”, the server’s hostname and the user’s password (or technically secret) to generate a string. This is sent through a one-way hashing function. Assuming all is good, the client and the server (both doing the computation) will get the same result.
It’s a bit more involved but is somewhat secure. That said, MS-CHAP is generally considered insecure nowadays with MS-CHAP v2 recommended if you really want to use MS-CHAP.
EAP-TLS is the generally recommended approach for authentication of PPTP VPNs. Catch is that to do it requires  you to set up some form of Public Key Infrastructure (PKI) and is well beyond the scope of this walk-through.
That said, I would recommend at least considering it if you wish to deploy this in real life.
Anyway, once you’ve made your decision about authentication protocols and encryption levels, your PPTP server is now setup on your Cisco IOS router.
If you’re deploying this in the real world, I’d highly recommend some form of logging and monitoring be configured for this system. It’s possible to configure a Linux box to act as a syslog server then run logcheck on it. With a bit of tweaking, it will e-mail you about anything unusual happening on your router(s).
On the Cisco side, enabling logging to a syslog server is fairly simple. After punching in configure terminal, you’ll need the following commands:

logging trap warnings
logging facility local3
logging ip.of.syslog.server

I’d highly recommend looking into the level of logging appropriate for your systems and configuration. The above is a good place to start though.
Finally, if you’ve got any form of firewall in the way (as you really should), you’ll need to allow GRE (the tunnel protocol) packets to get through, as well as PPTP on TCP port number 1723. Otherwise all that effort will be for nothing.

You may also like...

1 Response

  1. Jafar says:

    If your using a Cisco 2610 router as a basic PPTP VPN server. We will be demonstrating this using a local username/password database. The functionality is included to have the Cisco router go to a RADIUS server (like Microsoft IAS server) and authenticate with Windows Active Directory (AD) usernames/passwords. That type of configuration would be ideal with any more than a handful of VPN users.