By Amir Naftali.
After my previous blog post Setting IPSec/OpenSwan in EC2, many people have asked me how they can do the same in Rackspace public Cloud. This post goes over the same procedure I described in my previous blog post, but this time on the Rackspace public cloud.
Although the majority of the steps are identical for the two clouds, I did repeat the full procedure here for readability purposes.
Again, if you are having trouble setting this up on your own, I invite you to signup for our free trial to use our product (It takes a couple for minutes). We will set everything for you and include a tutorial session on how to easily manage your cloud security.
Before starting with the technical steps here are few words on Rackspace Public Cloud architecture (compared to Amazon EC2).
Rackspace Network Architecture
The rackspace public cloud environment is much simpler than AWS EC2 since each virtual server has two network interfaces – one connected to the public Internet with a public IP address, and one interface connected to the internal (data-center) service network with a private service network IP address (the Rackspace environment is not NAT’ed). The service network can be used for communication between your servers within the same region and between your servers and Rackspace services (LB, MySQL as a service , etc.)
Since the network environment is not NAT’ed, the VPN Gateway (GW) configuration is simpler than in the EC2 case. Note that since the Rackspace Public Cloud environment does not currently support Security Groups, your benefits from working with VPN are even higher than in EC2.
The following picture reminds us what we are trying to achieve:
The following screen shot depicts how the complete setup looks like in the 40Cloud web console. The VPN Gateway (the big orange shield icon) connects two VMs (RSServer1 and RSServer2), all located at the Rackspace data-center in London UK. The IP subnet allocated for connecting road-warriors is 126.96.36.199/24 (shown as three little orange men figures). The 40Cloud web console allows monitoring of the cloud deployment in real-time as well as logging all system events for future analysis and configuration of all security related items.
A Step-by-Step Configuration Example
In this example I am building the Gateway using an Ubuntu system (this is very similar to my previous post but with small changes relevant to the Rackspace environment).
Launching a Server
First thing you’ll need to do is to launch an Ubuntu server from the Rackspace (RS) management console (Just don’t use version 13.04 since it seems that there is a regression bug related to IPSec in this version. I used 12.10 but 12.04 should be fine as well). I’m using the small 512KB instance but you can allocate a server of any size that fits your needs (please note that Rackspace rate limiting is associated with the instance size so the bigger the instance the higher the limit is).
Before you continue please make sure that you know the public IP address of the VPN GW (your eth0 address).
Setting up the VPN Gateway (in a few simple steps)
Generally, you will need to setup both the IPSec and L2TP/PPP protocol stacks and turn the Gateway into a virtual L3 router.
For L2TP I’ll be using xl2tpd which is available for most platforms.
For IPSec/IKE I’ll be using the well-known OpenSwan.
The examples for config file that I am providing should just work (but you’ll need to replace the <server ip address> in the different files with the instance public IP address (your eth0 address) provided by Rackspace.
It is highly recommended that you change the shared secret and passwords from the one I’m using in my examples (if not before, then right after you get things to work).
Step 1- Setting up xl2tp and PPP
First you’ll need to install (if not already installed) the l2tp daemon (i’m using xl2tpd).
To install xl2tpd just type
sudo apt-get install -y xl2tpd
Here is an example for an xl2tpd configuration file that works (you’ll need to fill in the <server ip address> with the public IP address of your instance (eth0)).
Download an example of /etc/xl2tpd/xl2tpd.conf (xl2tpd config file):
Download an example of /etc/ppp/options.xl2tpd:
To make sure the xl2tpd stack will use the updated configuration files just run the following commands
- service xl2tpd stop
- service xl2tpd start
xl2tpd is now running with your configuration (you can check /var/log/syslog to verify it was loaded successfully).
Step 2- Setting up user credentials for user authentication
L2TP with PPP allows you to perform user-based authentication. There are several ways to make this work, but I’ll use the simplest (and a non-secure way of managing users with L2TP/PPP).
Each user will be represented as a line in \etc\ppp\chap-secrets
The file looks like this:
<username> <servername> <password> * user1 MyGW password1 * user2 MyGW password2 * .......
Please note that
- Items are separated by a single tab
- <servername> must be identical to the name provided in xl2tpd.conf
- usernames and passwords are in the clear (as I mentioned, this is not that secure)
- the “*” allows that specific user to access from any IP address
Step 3 – Setting up OpenSwan
See the OpenSwan site for more detailed information.
To install OpenSwan just type the following:
sudo apt-get install -y openswan
(If asked by the installation process just answer “NO” to every question).
Configuring OpenSwan connections
Here is an example for an openswan ipsec.conf configuration that works (you’ll need to fill in the <server ip address> with the public IP address of your instance (eth0)).
Download an example config of /etc/ipsec.conf:
Configuring OpenSwan authentication
In this example i’ll use shared secret, which is the simplest way possible to authenticate the server, and will require writing only a single line in ipsec.secret.
Download an example of /etc/ipsec.secret:
To get ipsec to work just type the following commands:
- service ipsec stop
- service ipsec start
- ipsec auto –add RWConn
A few things to note:
- There are a few places in the different config files where you’ll need to provide the <server ip address>. This is the public address associated with your server (usually your eth0 address). this address can be obtained by typing “ip addr” and copying the IP address associated with eth0 (or from the Rackspace management console).
- The <name> in the xl2tpd.conf file must be identical to the <name> inoptions.xl2tpd
- The subnet provided in the ipsec.conf file (in my example virtual_private=%v4:172.24.0.0/13) must contain the “ip range” subnet in the xl2tpd.conf file (the “ip range” subnet must start and end with a valid host ip – no subnets should be used for stating start and end address)
- the “local ip” in xl2tpd.conf must be a valid host IP and must be outside of the “ip range” subnet (but in the subnet defined in the ipsec.conf by virtual_private parameters) otherwise one of the connecting hosts might be assigned with the same address as the server
Step 4 – Configuring IPTables in your VPN Gateway
Before we can test the Gateway we must allow creating IPSec connections by enabling the following ports for external communication:
- SSH (TCP port 22)
- IKE (UDP port 500)
- IPSEC/NAT-T(UDP port 4500)
- L2TP (UDP port 1701)
This is done by configuring the GW’s IPTables, as follows:
iptables -F iptables -P INPUT DROP iptables -P FORWARD ACCEPT iptables -P OUTPUT DROP iptables -A INPUT -p TCP --dport 22 -m state --state ESTABLISHED,NEW -j ACCEPT iptables -A OUTPUT -p TCP --sport 22 -m state --state ESTABLISHED -j ACCEPT iptables -A INPUT -p UDP --dport 500 -j ACCEPT iptables -A OUTPUT -p UDP --sport 500 -j ACCEPT iptables -A INPUT -p UDP --dport 4500 -j ACCEPT iptables -A OUTPUT -p UDP --sport 4500 -j ACCEPT iptables -A INPUT -p UDP --dport 1701 -j ACCEPT iptables -A OUTPUT -p UDP --sport 1701 -j ACCEPT
Step 5 – Turning your Gateway into a Virtual Router
Now that we’re all set for securing the traffic over the public internet and into the region, all that is left to do is to get the GW to forward packets to/from other instances in the region.
There are two things we need to configure here:
- Packet forwarding
- NAT-ing packets – this is critical since the network can’t route packets that originate from outside of the region back to the Gateway, so the GW must masquerade all packets as if they were generated by it.
Configuring packet forwarding
This is very easy (thanks to Marius Ducea @mariusducea), just type…
sysctl -w net.ipv4.ip_forward=1
And you are all set (you can read more about IP forwarding here).
Masquerading will be done by IPTables (Information on IPtables is widely available, I personally like this one). Here is the basic config:
iptables -F iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT iptables -t nat -A POSTROUTING -j MASQUERADE
Testing and Securing your other Rackspace servers
Now you are all set. Just configure your VPN client to use IPSec/L2TP (most operating systems have a native client already installed) and note the following:
1) Gateway address should be the Public IP address that was assigned to the Gateway
2) The shared secret to use is the one that was configured in ipsec.secret file
3) Username and password to use were configured in chap-passwords file
4) You may wish to avoid working in split tunnel mode, so that all traffic will go through the VPN Gateway. Otherwise, you might hit a conflict with your local private IP address subnets.
Once the VPN connection is established try to SSH your other Rackspace Gateways – it should work for you.
Now that now that we have everything working, we can significantly improve our Rackspace server security by:
- Allowing developers/tester/devops to access your virtual servers in the Rackspace cloud only via the VPN Gateway, which means NO MORE opening of ports to the public Internet for access. To do so, just add the relevant IPTables rule, to each one of your Rackspace servers, allowing traffic from the Gateway and remove all rules that allow access from the public Internet.
- Control access at user level (denying/allowing access now only requires removal/addition of a user from/to the list of users)
- Authenticate and encrypt all admin traffic over the public Internet (i.e. use the VPN) regardless of the protocol being used or location the traffic is coming from.
- Note that the VPN gateway can be used to better leverage the Rackspace SDN feature (which is currently lacking a proper GW offering).
That’s all folks!
We would love to hear your feedback on this post.
If you need further assistance, we’re here to help!