Blog

Home / Rackspace / Interconnecting Rackspace Private Cloud Networks

Interconnecting Rackspace Private Cloud Networks

In Rackspace
0

Background

Last year Rackspace released a simple but very powerful Virtual Private Cloud service called “Cloud Networks” based on their SDN enabled cloud. This Rackspace service is included in their public cloud offering and available to all.

Basically Rackspace’s Cloud Network enables the end users to create a private IP subnet that can be attached to any virtual instance launched in their public cloud account.

Once created, this virtual private network is accessible via yet another virtual Ethernet interface in the instance and is populated with one of the addresses from that private IP subnet. So basically you get an additional eth(n) interface for every private network you associate the instance with.

Network Cloud Interface Table

An example for an interface table of an instance associated with a Cloud Network

The security benefits of using Cloud Networks are obvious, but the nice thing about this feature is that it takes just one or two clicks to set it up and it works very well.

There are still few missing pieces, that one might needs in order to make this service more usable.

  • The private networks are not deployable across datacenters, so communication between instances running in two different regions is still dependent on having a public IP address on the instance, which makes the instance more vulnerable and the private subnet less secure.
  • There is no way (that is offered as part of the virtual private network offering) to securely connect a Cloud Network to the ‘outside world’. The alternative of having a public IP address for each and every instance, is of course taking the whole point from the virtual private cloud idea.
  • There is no way to centrally control the routing table of the private subnet. Routing can be controlled within each and every instance by configuring the desired routes statically.
  • There is no way to assign/remove IP addresses once an instance is created.
  • No Private DNS services are available in the private CIDR block.

In the following, I will focus on what can be done with the first and second items from the above list, as they are somewhat related and have both operational and security impacts.

So what can we do?

Actually there are few simple things one can do to make the private network a bit more practical and yet secure.

Based on VPN and related technology we can improve the isolation of the Cloud Network instances, eliminate the need to associate a public IP on each instance, connect multiple virtual private networks (from the same or different data-centers) and even enable user based access control to the Cloud Networks.

In the next section I will demonstrate how the above can be done based on few open-source tools.

From use case perspective, I’m looking to operate two virtual private datacenters running in two different regions. Where instances are able to communicate across datacenter but w/o exposing my application and instances to the public internet (so basically have two connected private datacenter).

Here is the network design that I was thinking of based on Private Cloud Network Capabilities:

Rackspace Network Diagram

As you can see, only one instance, a gateway (virtual router) is actually connected to the public network (with a public IP address). This instance acts as a Virtual Router/Jump host. All other instances are connected to the virtual private network as well as to the Rackspace service network, so Rackspace services will be available to them.

Step by step installation and setup

In this example I am using Ubuntu 12.10 for the Virtual Routers (GW). The image can be found in the Rackspace image repository. The Virtual routers will act as both the jump host to the private network and the VPN GW for connecting the two Cloud Networks, one in LON (UK) region and one in Dallas (DFW) region.

Launching the UK Virtual Router instance

Using the Rackspace console or API create a new instance in the following manner:

  • In the “Image Type” pane choose -> Linux -> Ubuntu -> 12.10
  • In the “Flavor” pane choose whatever flavor you would like to work with (I am using the standard flavor)
  • In the Network pane click on “Create Network” to create a virtual private network to use for private communication between all instances and the gateway.  Provide a  name and in the CIDR field enter “172.16.20/24”.
  • Click on “Create Network” to create the network
  • Once the network is created, make sure that publicNet, serviceNet and the newly created private networks are checked in the Networks pane (once the instance is launch this can’t be changed).
  • Click on “Create Server”

Image Selection - Cloud Network

Cloud Network  – Image Selection

Private Network Creation

Cloud Network  – Private Network Creation

Installing and setting up the software

Once the gateway is running use SSH to login into the Ubuntu instance you just created (the access credentials should be provided via Rackspace console or API)

We’ll use Openswan to connect the two private subnets. To install Openswan do the following

Basics

sudo apt-get update

Enabling packet forwarding

sudo sysctl -w net.ipv4.ip_forward=1

Installing Openswan

sudo apt-get install –y openswan

You’ll need to update the following 2 files to get OpenSwan working:
1)    /etc/ipsec.config
2)    /etc/ipsec.secret
Examples for both files can be downloaded here:

Note that you’ll need to complete both the left and right properties. Left should be the public IP address of your instance and right should be the public IP of the 2nd Virtual Router we’ll be installing in the Dallas data-center. Since you haven’t yet created the 2nd Virtual Router you can keep the right property empty until you’ll have all the data available.

To obtain the private IP address of the instance just type the following in the instance’s command line and take the IP address that is associated to eth0

ip addr show

Setting up the Dallas virtual router

All steps described above should be repeated in order to setup the virtual router in the Dallas region. Please note the following exceptions and things you’ll need to change in the ipsec.conf file:

  • When creating the Dallas private network the network CIDR must be 172.16.10.0/24 (and not 172.16.20.0/24)
  • Fill in the right and left properties using the same logic that was applied to the first instance, which means that left will be the local (Dallas) public IP address and right will be the remote (UK) public IP address
  • Leftsubnets and rightsubnets properties should be reversed so leftsubnets=172.16.10.0/24 and rightsubnets=172.16.20.0/24

Now that both virtual routers are up and configured correctly, you should run the following set of commands in each one of them (it doesn’t matter with which instance you start):

sudo service ipsec stop 
sudo service ipsec start 
sudo ipsec auto –add vpc2vpcConnection 
sudo ipsec auto –up vpc2vpcConnection

Now that the tunnel is up it will connect the instances from the two remote private networks w/o forcing the instance to have a public IP address

Make sure your FORWARD chain in iptables is configured to forward all traffic:

sudo iptables –P FORWARD accept

Ground rules and example for creating instances in the virtual private networks

  • Instances should be created without a public IP address – unchecking the “publicNet” checkbox before launching the instance will do this.
  • Each instance’s route table will have to be changed so traffic meant for the remote private network will be routed via the Virtual Router (similar approach can be applied in order to use the Virtual Router as internet gateway)

Server example

Launching instances

To get started please launch one instance in the UK data-center and one instance in the DFW data-center.

Before creating the instances (before clicking on the “Create Server” button) make sure that the Networks pane is showing:

  • “publicNet” is unchecked
  • The private network is checked
  • The “serviceNet” is checked

Once the instances are running you’ll need to login into each of them.

Since they don’t have a public IP address (we unchecked the publicNet), you will have to use another instance (the Virtual Router) in that region as a jump host.

To do so login using SSH to the Virtual Router and then login into the server instance using it’s service network address (should looks like a 10.x.x.x addresses)

Once logged into the instance you’ll need to change the routing table in the following manner (the following example is an Ubuntu based example)

Ip route add <remote subnet> via <gw private address>

Assuming our virtual routers have the following private IP addresses

LON Virtual Router 172.16.20.1

DFW Virtual Router 172.16.10.1

In our example this should look like the following for the UK data-center

Ip route add 172.16.10.0/24 via 172.16.20.1

And for the Dallas data-center

Ip route add 172.16.20.0/24 via 172.16.10.1

Once this has been configured all you need to do is to ping the remote server using it’s private IP address.  If you’ve followed the above procedure you should have the remote instance answer the ping request.

In summary

  • We now have a virtual private cloud deployment with instances that are not directly exposed to the public Internet – they don’t have public IP addresses but they can still access the Rackspace service network.
  • We have a deployment across two data-centers that can intercommunicate in a secure manner.
  • And we have a jump host that we use as a gateway for accessing the instances from the public internet.

Security aspects that you still need to consider

  • Hardening the jump host
  • Adding firewall for the service network traffic
  • Adding VPN access to the virtual private cloud deployment.

That’s all for now.

Amir Naftali

Subscribe to newsletter

 

Recommended Posts

Free Trial

Request a Demo