Creating a VPC network? Come back to the future!
The hallmarks of deploying public cloud computing are simplicity, agility and rapidity. Start to finish, you can deploy a virtual machine on just about any public cloud provider in less than 5 minutes. Thanks to today’s automation and orchestration tools, you can literally deploy 100’s of freshly minted virtual machines in a public cloud like Amazon AWS in less time than it takes to unpack, rack and boot-up a new single physical server. The cloud has made feats of IT dexterity that were not imaginable just a few years ago a reality today. Just don’t try to connect those shiny new VMs across the WAN using your cloud provider’s VPC networking options.
Setting up a hybrid or multi-cloud VPC today on just about any public cloud service is like dialing the IT time machine back to Y2K. So, we decided to try it for ourselves and compare the steps it takes to deploy an Amazon AWS VPC versus Pertino’s cloud network based solution.
Let’s start with AWS
First, you have to use the AWS control panel to create a VPC and then configure security groups. Seams pretty simple so far. But to do that, you have to:
- Create a DMZ
- Configure port access for each security group and assign the correct group to the front-end and back-end VPC subnet
- Next, you need to launch VPN instances to servers on each VPC and assign a VPN server to the DMZ.
- Once all that is set up, you have to associate elastic IPs to the front-end server and configure route tables in the VPC to point default traffic to the VPN server
- Then, you associate the new route table with the private subnet
- Stay with me now, and finally you go to EC2 and change the source and destination on the front-end server and configure Openswan
That was about 3-4 hours of work for Tom, our crack IT guy here at Pertino. If you’re not a certified network nerd, then it’s going to be a long night. Admittedly, you could choose to use the AWS VPC Wizard (just calling it a “wizard” is an admission of crushing complexity), but you still need to configure security groups, elastic IPs, and use their cryptic naming structure—like "vpc-0fd883fc”, which makes it more difficult to troubleshoot.
Since you’re going over the WAN, you’ll need to get an IPSec VPN interface setup on your end of the network. Again, this is a straightforward process for network nerds, but DevOp and CloudOps types will be scratching their heads at the gyrations involved. To get things rolling, you will either need to pay homage to the network Gods within your organization or buy, rack, cable and install an IPSec VPN appliance. Thankfully, Tom can be had for a good bottle of wine—startups tend to work a lot with such alternative forms of currency.
Watching over Tom’s shoulders, I see there’s a set of CLI commands that has his fingers dancing across the keyboard. Best as I can tell, CLI means “Cryptic Language of Incantations”. You've got to know more than a dozen commands to bring your end of a simple VPC connection to life. For more complex VPC configurations, there’s 100’s of command options to navigate. To get a sense of the fun that awaits, check out the command reference for the Vyatta software router commonly used to create Rackspace VPC networks.
Here are just a few of the parameters that Tom configured in our Cisco appliance:
- Setting global lifetimes for IPSec (in seconds or kilobytes)
- Router(config)# crypto ipsec security-association lifetime seconds <seconds> (OR)
- Router(config)# crypto ipsec security-association lifetime kilobytes (kilobytes)
- Defining transform sets (making sure that particular data flows are protected) and understanding the allowed transform combinations
- Router(config)# crypto ipsec transform-set <transform-set-name transform1 [transform2 [transform3]]
- Router(cfg-crypto-tran)# mode [tunnel | transport]
- Creating Crypto map entries (which traffic should be protected, where it should be sent, which transform set should be applied, and if possible security associations should be applied manually or via IKE)
- Router(config)# crypto map <map-name> <seq-num> ipsec-manual
- Router(config)# match address <access-list-id>
- Router(config-crypto-m)# set transform-set <transform-set-name>
- Router(config-crypto-m)# set session-key inbound esp <spi> cipher <hex-key-string> [authenticator <hex-key-string>]
If you can survive this techno-gauntlet, now it’s time to define your IP addresses and public to private address translations paying close attention to avoid any address space overlaps.
Finally, you’re ready to add users and policies through our new friend, Mr. CLI. Depending on your configuration, this process can take up to 23 separate "top-level" commands to execute. Now is not the time for fat fingers.
If you’ve managed to hit all the green lights on this circuitous route (and you have someone like Tom as your network sherpa), you’re up and running after spending 5 to 8 hours of your life that you will never get back.
Time to Try Pertino
OK, let’s jump back to the future and build a the same hybrid VPC network using Pertino’s Cloud Network Engine, a cloud-based networking service. Here are the simple steps:
- If you’re new to Pertino, you would go to pertino.com and signup for a free trial account
- Once registered, a new default virtual network is instantly created with IP addressing, NAT, DNS, PKI and other network details automagically configured behind the scenes for you (at this point, you can rename your network if you’re feeling useless)
- Lastly, remotely access both the AWS and datacenter VMs using SSH, RDP or a similar tool and download, install and authenticate the Pertino client stack user your Pertino ID credentials
SIDENOTE: Step 3 can be completely automated using Puppet or Chef scripts and a Device Authorization Key generated from the SETTINGS menu for your network on the Pertino web console.
That’s it, you’re done with an elapsed time of less than 15 minutes.
Welcome back to the future! You’ve just created a secure, guest OS-level VPC overlay. Since Pertino virtual overlay networks have their own private address space and use only outbound connections on port 443, there’s no need for public IPs or AWS VPC route table modifications, and you can lock down VMs by disabling all inbound connections.
The only question that remains—what are you going to do with your extra time and flux capacitors?