Please note that some carriers might block PPTP traffic. I experienced problems with using the VPN connection via 3G, while connecting through Wifi works for me. On 3G I can connect to the server, but no data is being transferred. On the server I see a lot of messages of the type “Protocol-Reject”. So if your device seems to be connected to the VPN but you get no traffic, it might be blocked by your carrier. You then need to find a Wifi Hotspot to use the VPN.

iOS Devices

Setting up the VPN is pretty straight forward:

1. Go to Settings and open the “General” settings
2. Select “Network”
3. Select “VPN”
4. Choose “Add VPN Configuration…”
5. On this screen make sure you activate “PPTP”. Now you can name your VPN connection and enter the address of the server, your login and your password. Ensure that “Send All Traffic” is “ON”. Now save your settings.
6. Now you can turn on the VPN connection. An active connection is indicated by a blue “VPN” icon in the status bar.

Android Devices

On Android, the steps are quite similar:

1. Go to “Settings” and open “Wireless & networks”
2. Select “VPN settings”
3. Select “Add VPN”
4. Choose “Add PPTP VPN”
5. Enter the “VPN name” and the server address in “Set VPN server”. Encryption should be enabled and DNS search domains not set. Now pull up the menu and save your changes.
6. Click on connect and enter your login and password.
7. An active VPN connection is indicated by a key icon in the status bar.

The EC2 Micro Instance is an ideal way to operate your own VPN-server, when you need it only a couple of hours per month. Let’s assume, that you want to use it for about 50 hours per month with around 10 GB of traffic, this means $1.00 for computation time + $1.50 for 15 GB of storage + $1.50 for 10 GB outgoing traffic. So for $4 this is quite a good offer. Granted, you can find commercial VPN providers for $5 per month, but it is more fun to do it yourself. In this article I will describe, how to setup an EC2 instance as a VPN-server.

I choose to setup a PPTP server. PPTP is not the most secure type of VPN, but it has the big advantage, that it is the most compatible. Nearly every OS is able to open a PPTP connection without additional software and this includes mobile devices like iPhones/iPads.

First, you need to choose a base image to boot in the Micro Instance. I have selected an 32-bit Ubuntu 10.04 server image. The AMI-ID of this image is ami-6c06f305. Start this image in a Micro Instance and log in with your SSH-key. For more details on these steps, refer to the AWS documentation.

Once you are logged in, you can install the pptp-daemon:

sudo aptitude install pptpd

Configuring the pptp-daemon is a breeze. First you to define an IP address range which will be used for connected clients. This can be any IP range, but keep in mind, if you want to avoid routing problems, choose a private IP range. Uncomment and modify 2 lines at the end of /etc/pptpd.conf:

localip 192.168.240.1
remoteip 192.168.240.2-9

With the above settings, the pptpd server will get the address 192.168.240.1 and there are 8 possible client addresses 192.168.240.2 to 192.168.240.9.

It is also a good idea to specify the address of at least one DNS server. You can use the DNS server of amazon (172.16.0.23) or the Google Public DNS. I choose the latter. Open the file /etc/ppp/pptpd-options and make sure it contains the following settings:

ms-dns 8.8.8.8
ms-dns 8.8.4.4

The last step for configuring the pptpd-daemon is to add a user account for the service:

sudo echo "USERNAME pptpd PASSWORD *" >> /etc/ppp/chap-secrets

Replace USERNAME and PASSWORD with whatever credentials you like. It is possible to add as many users as you like.

Now restart the pptp-daemon:

sudo /etc/init.d/pptpd restart

It is already possible to open a PPTP-connection to the server, although no traffic will be forwarded to the Internet. We still need to enable packet forwarding and network address translation on the server.

To enable packet forwarding, uncomment the following line in /etc/sysctl.conf:

net.ipv4.ip_forward=1

Now reload this config:

sudo sysctl -p

The last step is to enable network address translation:

sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

This setting is reset on every reboot, so make sure that you add the following line above exit 0 in the file /etc/rc.local:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Now the VPN server is fully functional. The only small problem is, that the server will get a new IP address every time you reboot it. I would recommend using a dynamic dns-provider to assign this machine a unique domain name. I am using DynDNS.

The ddclient is a great little tool to update the current IP address on a number of different dynamic DNS services. Installation is done as usual:

sudo aptitude install ddclient

Once installed, the configuration is done in the file /etc/ddclient.conf. It will already contain some usefull settings, because the installer will require you to enter some information about the DNS service you are using. In the end the configuration should look something like this:

protocol=dyndns2
use=web, web=checkip.dyndns.com/, web-skip='IP Address'
server=members.dyndns.org
login=LOGINNAME
password='PASSWORD'
DOMAINNAME.dyndns.org

Replace LOGINNAME, PASSWORD and DOMAINNAME.dyndns.org with your own settings. The most important line is the one starting with use=. This defines that the registered IP-address is detected by DynDNS itself. This is neccessary, because the virtual machine is running with a private IP address.

That’s it! Now you have your own VPN-server up and running. Just start the instance in the AWS Management Console whenever you need it.

Update:

Here is a screenshot of the security groups setup I am using:

Update 2:

Please take a look at my follow up posting on how to connect to the VPN from an iOS or Android device.

One option is to move the SSH daemon to a non-standard port. But this means that you might get problems connecting yourself to the server if you are working from a restricted network. So another solution would be to use certificates for login. But then you need to make sure that you carry the certificates with you when you want to login to your server.

Now a good solution is to limit access to the SSH server. One way would be to use the so called port-knocking approach. Here the access to the SSH port is blocked until you use some kind of secret knock-sequence. Then the port will be unblocked for your IP for a certain time. This is very effective but has the downside that you always need to use this knock mechanism before connecting to your server.

What I prefer is a mechanism which works the other way around. The access to the SSH port is open until there are a number of failed login attempts detected. If this is the case, the IP address these login attempts came from will be blocked for a couple of hours. This approach is less secure then the port knocking approach but is a lot more convenient for me. As long is I don’t mess up multiple times with the login, I do not even notice any security restrictions. Brute force attacks on the other hand are blocked right away.

The most common tool for this task is the excellent fail2ban. On a Debian system it can be installed via aptitude:

aptitude install fail2ban

The default configuration is already useful. It will secure the SSH daemon with a blocking time of 10 minutes after 6 failed login attempts. The configuration files can be found in the directory /etc/fail2ban.

You can change the blocking time in the file /etc/fail2ban/jail.conf:

[DEFAULT]
bantime  = 7200
maxretry = 4

This will change the default settings which apply if not specified otherwise in the application settings. The setting bantime is specified in seconds and defines how long the blocked IP will not be able to connect to the blocked service. maxretry is the number of failed login attempts.

Lets take a look at the ssh setting:

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 3

You can enable or disable the monitoring of specific services (ports). The ssh monitoring uses the auth.log file to detect failed login attempts.

To activate changed configuration settings, just reload the service:

/etc/init.d/fail2ban force-reload

So what happens when an IP is blocked? Once the login attempt limit has been reached, the IP address will be blocked via iptables. Here is the output of iptables on my system:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-ssh  tcp  --  0.0.0.0/0            0.0.0.0/0           multiport dports 22
 
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
 
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
 
Chain fail2ban-ssh (1 references)
target     prot opt source               destination
DROP       all  --  123.456.789.012        0.0.0.0/0
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

I have replaced the blocked IP address with some default numbers, but you can see that all traffic from this IP address to the port 22 will be blocked. This iptables rule will be automatically removed after the specified blockout time.

fail2ban is an effective tool to lock out brute force login attempts. It is really easy to setup and can be used to monitor multiple services besides SSH.