IP Networking: Enable Point-to-Point Tunneling Protocol (PPTP) VPN on Your Server
Posted on April 23, 2015 — 6 Minutes Read
What follows will be a walk-through on enabling Point-to-Point Tunnelling Protocol (PPTP, RFC 2637) on your server to connect your clients in a virtual private network (VPN) over the internet, and to serve as a web proxy for any client connected to it.
Despite its out-of-the-box support on almost all major Operating Systems and as such the popularity, the well-known security vulnerabilities with the encryption and authentication methods e.g. MPPE-128 (RFC 3078) and MS-CHAPv2 (RFC 2759), used by the most common implementations of PPTP, render it an obsolete virtual private network (VPN) protocol, and should be used at best for demonstration or proof of concept purposes. For a production network or any other real-world application, WireGuard VPN should be used instead for its simplicity, performance advantage and tightened security.
Installing PPTP
First, let’s install PPTP on the server.
$ apt install pptpd
Configuring PPTP
Next is configuration.
Private IP Addresses
One private IP address (RFC 1918) for the PPTP server and each of the PPTP clients in the same subnet will need to be reserved. This is done by the localip and remoteip parameters in the PPTP server configuration.
Edit the pptpd.conf file with the nano text editor
$ nano /etc/pptpd.conf
The private IP addresses of 10.0.0.1 and 10.0.0.100-200 under the subnet of 10.0.0.0/24 will be used for the server and clients respectively in this writing.
localip 10.0.0.1
remoteip 10.0.0.100-200
Control + x to exit, and y and enter to save.
DNS Server
In addition to being assigned a private IP in the same subnet as the PPTP server, the connected PPTP clients will need to have a valid DNS server to send DNS query to. Google and Cloudflare DNS servers are some excellent choices.
$ nano /etc/ppp/pptpd-options
Locate the ms-dns parameter by control + w and type in the parameter name. Add the parameter if unfound.
ms-dns 8.8.8.8
ms-dns 1.1.1.1
Control + x to exit, and y and enter to save.
Network Address Translation (NAT)
Most implementations of PPTP clients send all traffic to the PPTP server once the VPN is established and as such there is no need to manipulate the routing for the purpose of leveraging the server as a web proxy for the client. Internet traffic will as such be sent from the PPTP client to the PPTP server and then off to the internet. For the return traffic to know the way back to the PPTP server before being forwarded subsequently to the PPTP client through the PPTP tunnel, a rule in the routing table (RFC 1812) at the PPTP server will need to be added to translate the source IP address of any outgoing network traffic originating from the PPTP client, to the public IP address of the internet-facing network interface of the PPTP server. This IP address conversion is called Network Address Translation (NAT, RFC 1631) and it allows a great many of network devices to connect to the internet on a single shared public IP address.
Adding a rule to the routing table on the internet-facing network interface, which is eth0 in this writing, of the PPTP server will enable this.
$ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
NAT should now be enabled for all PPTP clients. You can verify this by invoking the iptables command and have it list all of the rules under the postrouting chain in the nat table.
$ iptables -t nat --list POSTROUTING
An output similar to the below will be printed.
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- anywhere anywhere
The routing table resets and wipes itself of this rule however if the server reboots. Persisting this NAT rule requires iptables-persistent.
$ apt install iptables-persistent
iptables-persistent is a neat tool that reads routing rules from the /etc/iptables/rules.v4 file and applies them on boot. Invoking the iptables-save command with the output redirected to this file will allow you to save all the existing routing rules.
$ iptables-save > /etc/iptables/rules.v4
Restart iptables-persistent for the save to take effect.
$ service iptables-persistent restart
IP forwarding needs to be enabled on the PPTP server as well to allow the connected PPTP clients to access the internet through it. This requires modifying a runtime kernel parameter stored in the sysctl config file.
$ nano /etc/sysctl.conf
Locate the net.ipv4.ip_forward parameter by control + w and type in the parameter name. Then change its value from 0 to 1.
net.ipv4.ip_forward = 1
Control + x to exit, and y and enter to save.
Once the config is saved, load the new setting with the sysctl command.
$ sysctl -p
IP forwarding should be enabled with the new setting. You can verify this by invoking the iptables command and have it list all of the rules under the forward chain in the routing table.
$ iptables --list FORWARD
An output similar to the below will be printed.
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
PPTP Username and Password
A username paired with a password should be created for each PPTP client to be connected to the server. These are stored in the chap-secrets file on the PPTP server in the following format.
username server password ip
The server parameter should read pptpd. The ip parameter is the private IP address reserved in the assigned remoteip range for this particular username, or you can use the wildcard parameter (*) to instruct the PPTP server to pick an unoccupied private IP address from the range instead.
$ nano /etc/ppp/chap-secrets
Enter the username, password, and the rest.
kurtcms pptpd (redacted) *
Control + x to exit, and y and enter to save.
Restart the PPTP server for the config to take effect.
$ service pptpd restart
You should now be able to connect to the PPTP server with the username and password on a PPTP client.
Thoughts
Notwithstanding the security vulnerabilities, the out-of-the-box support on almost all major Operating Systems (OS) and its ease of setup and of use make it still a rather good choice for VPN for trial or demonstration purposes. For a production network or any other real-world application again, WireGuard VPN should be used instead for its simplicity, performance advantage and tightened security.