Configuring OpenVPN on a Micro AWS instance

The results are in, running OpenVPN on an AWS Micro instance works flawlessly, with the one exception that Apple does not have support for OpenVPN, only L2TP, PPTP, and IPSEC unless you jailbreak your phone.

OpenVPN on Micro AWS Instance

I had planned on writing instructions on how to setup AWS on a free Micro instance but a very nice set of instructions already exists here (run the commands under the root account, Sudo will only cause problems)

Micro instances on AWS are free up to 750 hours (that’s 24/7) and 15GB of bandwidth (across all AWS services).  If you wanted you could create a cron job to shutdown the instance and then turn it on when you needed it (via a nice app on your smartphone) you could preserve your micro instance hours.

Also, make sure you open the right ports on the Ubuntu AMI, (TCP 443, TCP 943, UDP 1194) and of course don’t forget SSH 22 so you can access your server.

Straight form OpenVPN

Long answer: By default OpenVPN Access Server has 2 OpenVPN daemons running. One of them on UDP port 1194 and another on TCP 443. We recommend that you use the UDP port because this functions better for an OpenVPN tunnel. However, many public locations block all sorts of ports except very common ones like http, https, ftp, pop3, and so on. Therefore we also have TCP 443 as an option. TCP port 443 is the default port for https:// (SSL) traffic and so this is usually allowed through at the user’s location.

TCP port 943 is the port where the web server interface is listening by default. You can either approach this directly using a URL like https://yourserverhostnamehere:943/ or by approaching it through the standard https:// port TCP 443, since the OpenVPN daemon will automatically internally route browser traffic to TCP 943 by default. (https://yourserverhostnamehere/).

The only thing I would recommend is setting a root password and changing to root before following the guide above

sudo passwd root

Set a root password when prompted and then changing to the root account before beginning


Enter the newly created root password when prompted.  The reason I suggest this is that you cannot run ./vars without root access and sudo ./vars will fail, change to root and save the trouble.


Don’t forget, not even private IPs persist through stop/start of AWS EC2 instance

Well, I knew that the public DNS would not persists through a stop/start of an EC2 instance, easy enough to get around, use an Elastic IP.  I do most of my AWS work inside of a VPC, I had to step outside of that for a project setting up a web app & sql server, I used the private IP of the EC2 instance, not thinking I would need to change the instance type (small -> medium) but when I did….  🙂  no db connectivity on app server.

I do most of my work inside a VPC, my advice is to launch your instances inside a VPC, I never have figured out why I cannot change the size of an EC2 instance with a simple restart though.. thereby preserving my DNS settings.

Better still, use Route53 to setup a CNAME, point that to the internal IP of the instance and voila, still avoid the bandwidth usage and no need to modify connection strings.

Posted in |

Bringing the power of AWS to my blog

I’ve been an IaaS (Infrastructure as a Service) fan for some time now and I thought it would be cool to incorporate some of AWS (Amazon Web Services) into my blog, for both personal exploration and to share things I pick up along the way.

I’ve read a few different blogs about people running their WordPress instances from AWS but reading and doing our two different things and WordPress blogs are dynamic…not static pages, subsequently it becomes a little more involved.

Over the past couple years I have used AWS to run a handful of Windows/Linux servers running things like Typo3/Joomla, Bugzilla, SES, etc.. This experimentation phase for cloud adoption has lasted longer for me than say virtualizing on VMWare but what’s the rush.

Future AWS explorations:

1) My next goal is to move the static content from this blog to the cloud, which is made easy by plugins
2) Setup OpenVPN instance for personal use
3) Explore moving Exchange 2010 Edge Transport Server role to AWS
4) Setup VPC (haven’t had a need to utilize this feature yet but I would like to look into how I could take advantage of this at work)
5) Along the VPC lines, what about moving Active Directory to the cloud? I can think of a few issues off-hand but I’m sure others have thought about this.
6) How can I take advantage of AWS and use it as a platform to serve up content for unattended self-service kiosks and digital signage
6) So many other things…….

And so it begins.

Quick……To the cloud!