When we decided to offer Active Directory-based managed infrastructures for our clients, we decided there was a lot of benefit to be had if we created a single centralized infrastructure as opposed to autonymous Directories for each customer. I’ll save the rational for this for another day, but suffice it to say that we needed a way to create tunnels between our client’s sites and our datacenter.

Being a huge fan of open source solutions, we tried a bunch of open source firewall implementations (pfSense, m0n0wall, IPCop, vyatta, ClarkConnect, Ewido, Shorewall, Smoothwall, Untangle, and probably 10 more I can’t recall). Eventually, we realized that although there were a few contenders that did almost everything we needed (pfSense, m0n0wall, and Untangle, specifically), they were all pretty locked into their feature-set.

If we’re going to deploy a solution across our client-base, we want flexibility to use this solutions for future needs without having to redeploy a new solution. For instance, I can see us adding content filtering for our clients’ employee web browsing in the near future, and we decide to use a filtering solution that is not bundled in whichever distrobution we choose, then we’ll have some trouble.

All that said, we ultimately decided to use a base Ubuntu installation with OpenVPN to provide our site-to-site connectivity. Here’s how we did it.

First, we installed a plain-jane installation of Ubuntu server and included the OpenSSH server packaged during install. We installed Shorewall, Squid, and Webmin from the commandline once we were up and running.

We did this on a server in our datacenter as well as a test box in our office. We used Webmin to manage the OpenVPN configurations, including the creation of a Certificate Authority to sign the OpenVPN certificates and to manage the client and server configurations.

We setup the OpenVPN connection as a routed tunnel (as opposed to bridged) and created a new subnet strictly for the VPN network itself (we chose 10.0.30.0/24). Our datacenter maintained its internal subnet of 10.0.10.0/24, and our office 10.10.10.0/24.

Once we got the office connected to the datacenter, I was able to connect direct from my desk computer (10.10.10.102) to our Active Directory domain controller in the Datacenter (10.0.10.10). It routed from 10.10.10.102 to the internal IP of the VPN server at the office, which passed the packets across the VPN to the VPN server, which then routed to the Active Directory domain controller.

That was a pretty cool feeling. We had a effectively created a branch office of our datacenter network.

I then setup Shorewall to appropriately manage inbound and outbound connections and ensure the security of each network both from each other and from the Internet itself.

As I write this, I’m sitting at Starbucks, connected to my datacenter via the Windows OpenVPN client, and routing from the datacenter back to my office and accessing our QuickBooks data remotely.

I can also connect via internal IP to any of our managed machines using a Remote Desktop Connection or even transfer files from any of our servers to my laptop via the VPN.

Pretty cool, eh?