Mirantis OpenStack Express VPN-as-a-Service (VPNaaS) - Step by Step

Hybrid Essentials: Linking Tenants on Separate OpenStack Clouds

In this video, we’ll show how quickly and easily Mirantis OpenStack Express VPNaaS lets you link tenants in separate OpenStack clouds -- for example, premise and hosted clouds in a hybrid application.

Step by Step

To demo this capability, I’ve set up two, completely-separate OpenStack environments in MOX -- one representing the premise datacenter, the other a hosted cloud. In a future demo, I’ll show how it’s now also possible to link an actual on-premise OpenStack cloud to a Mirantis OpenStack Express cloud, though this currently requires use of neutron command-line or REST functions, and is ideally done with the help of scripts to simplify the process.

Mirantis OpenStack Express, meanwhile, has made it simple. Within each environment, I’ve set up a Project -- also called a Tenant. That’s an OpenStack construct for isolating tenant resources and activities inside a cluster. You can use a Project to give your users access to designated resources, to give them roles that define their powers and to prevent them from seeing parts of the Project and cloud they’re not permissioned for. Under most OpenStack networking regimes (other than the simplified, “flat” model -- these environments use Neutron VLAN-based networking), a project can have its own private networks, subnets, and router gateways.

That’s what I’ve built here, in each cluster. First, I created a Project -- we have DemoProject 1 on Environment 1, and DemoProject 2 on Environment 2. Then I made the Admin user of each environment a member of the respective Project and gave each of them the admin role within that Project. This is important for setting up VPNaaS, since router gateway IP addresses and other info you’ll need to set up your VPN connection are visible only to the admin user.

To demo VPNaaS, I created two OpenStack clouds on Mirantis OpenStack Express, and in each of them, created a Project, and added the admin user to the Project in the Admin role. This insures that, when I'm inside the project as the Admin, I'm permissioned to see everything I need to see, to set up the VPN connection (e.g., router external gateway IP addresses and other details). This is Cloud A/DemoProject1's User table.

This is Cloud B/DemoProject2's user table. Note the admin user.

Then, switching to each project as the admin user, I built a simple local network for it. You can see these networks from each project’s Network Topology view. Each project’s network has a defined subnet, letting it serve a range of local IP addresses. And each network has a router connecting it to the cloud’s public external network.

This is a plain-vanilla network setup that lets machines talk to each other and the internet. And what VPNaaS will do is make an encrypted connection between the public IP addresses of each tenant’s gateway router, so that machines in DemoProject 1 can see machines in DemoProject 2, and vice-versa, while securing the traffic between the two projects from prying eyes.

Within each Project, I've set up a basic local network, bridged to the cloud-wide public network (and the Internet) with a router. OpenStack Express Horizon (and Neutron networking) makes this very easy. Here's DemoProject1's network, on Cloud A.

And here is DemoProject2's network, on Cloud B. Note the IP address range given to the local subnet: it does not overlap with the IP address range on DemoProject1's local subnet (see above). This is a requirement for VPNaaS to work.

For VPNaaS to work in connecting these subnets, the subnets need to have non-overlapping IP address ranges. As you can see here, I’ve given each subnet an arbitrary CIDR range assignment that doesn’t overlap with that of the tenant in the other cloud. Each range contains 256 IPv4 addresses.

Once your VPN is connected, you’ll probably want to use a range of apps and methods to communicate across it. So you need to be aware that when you first set up a Project in Mirantis OpenStack Express, it gets assigned the default security group for the cluster in its default form, which is usually restrictive. So you’ll probably need to create a few additional rules in each Project’s default security group: like a general ICMP rule, enabling pings, and a port 22 TCP rule, enabling SSH.

I also added some Ingress rules to each Projects' default Security Group, to allow pings (ICMP) and SSH traffic (TCP, port 22) to go back and forth. Doing this first saves head-scratching later, when the VPN goes Active, but you can't communicate.

Set up VPNaaS on Cloud A

Now let’s start building our VPN hookup by clicking on VPN under Compute->Network. We get four tabs that let us set up the four elements of a VPN link: an Internet Key Exchange (IKE) policy, an IPSec policy, a VPN Service, and an IPSec Site Connection. We need to fill out these tabs under each Project to make the VPN work. Protocol and policy details need to match -- the defaults offered are mostly optimal. And to fill out the IPSec Site Connection tab, we’ll need to provide each side of the VPN with info on the other side’s public gateway IP address, and its subnet IP address range.

We’ll do all of this first for DemoProject 1 on Cluster A:

Create the Internet Key Exchange Policy: The only thing recommended to change, here, is the Encryption algorithm, which should be set to aes-256.

Setting up the Internet Key Exchange (IKE) policy for DemoProject1/Cloud A's side of the VPN connection. The only change from the defaults is to select the recommended 256-bit AES encryption. Names assigned to policies are arbitrary and need only be locally unique, so I've used the same names for components on both clouds.

Create the IPSec Policy: Same thing. The defaults are fine, though it’s recommended to use aes-256 encryption.

Setting up DemoProject1/Cloud A's IPSec policy. Again, we're going to use the recommended AES-256 encryption.

Create the VPN Service: Here’s where we select a router that will work as our VPN gateway -- that’s the local router; and picking a subnet to make visible at the other end: that’s our local subnet. As noted, the main thing to remember is that VPN will not work if the subnets at both ends overlap.

Adding the VPN Service definition for DemoProject1/Cloud A — selecting DemoProject1's local router and subnet range from the popdowns. We'll do the analogous thing on the other cloud.

Create IPSec Site Connection: This is the only mildly-tricky thing about setting up a VPN using VPNaaS. We start by identifying our VPN Service, our IKE Policy and our IPSec Policy, defined just a moment before -- that’s easy. To finish, however, we’ll need to get some information about the network in DemoProject 2. So let’s flip to DemoProject 2’s Horizon, making sure we’re logged in as the admin, so we can see the info we need to know.

Starting to set up DemoProject1/Cloud A's IPSec Site Connection. We begin by selecting the VPN Service, IKE and IPSec policies we've just created.

The first thing we need is the Peer gateway public IPV4 address or fully-qualified domain name for DemoProject2’s router. This can be found by going to DemoProject2’s Network tab, clicking on router, the router name, and copying the IP address shown for the external gateway interface: it’s 198.11.214.23. This is the thing you won’t be able to see if you’re not in the admin role for this project.

To finish filling out DemoProject1/Cloud A's IPSec Site Connection, we need two pieces of information from DemoProject2/Cloud B. The first is the external IP address of DemoProject2's router. We can find this by going to DemoProject2/Cloud B's Horizon, clicking on Routers, clicking on the router name, and finding the IP address in the router's interface table.

This IP address goes into two slots in the IPSec Site Connection edit dialog for DemoProject1: the first marked “Peer gateway public IPv4/IPv6 Address or FQDN”, and the second marked “Peer router identity for authentication (Peer ID)”.

The router IP goes into two slots in DemoProject1/Cloud A's IPSec Site Connection dialog.

The second piece of info is the CIDR range for DemoProject2’s subnet. Again, go to DemoProject2’s Horizon, click the Network tab, click on network, and copy the subnet CIDR range, which is 192.168.111.0/24.

The second piece of info we need is the IPv4 subnet address range for DemoProject2/Cloud B's local network. We can find that in DemoProject2/Cloud B's Horizon, under Networks, next to the network name.

We’ll put that into the Remote Peer Subnet slot on DemoProject1’s IPSec Site Connection dialog. Then to finish setting up DemoProject1’s IPSec Site Connection, we’ll provide a pre-shared key password -- same on both sides -- for authentication. The rest of the parameters can be left as defaults -- if you change them, they should match on both sides of the connection.

We put DemoProject2/Cloud B's local subnet range into the Remote Peer Subnet slot in DemoProject1/Cloud A's IPSec Site Connection Dialog. We finish by entering a pre-shared-key password, which will be the same on both sides of the connection.

Set up VPNaaS on Cloud B

Now let’s quickly set up the other end of the VPNaaS connection, over on DemoProject 2. We’ll make sure protocol details and policies match.

On DemoProject2’s IPSec Site Connection tab, we’ll provide -- in two places -- the peer gateway public IP address for DemoProject 1’s router, and DemoProject 1’s subnet IP address range.

Now we set up the same components on DemoProject2/Cloud B. Setting up IKE Policy, IPSec Policy and VPN Service are simple. For the IPSec Site Connection, we'll need the same two pieces of info from DemoProject1/Cloud A that we needed for DemoProject2/Cloud B. Here, we're grabbing DemoProject1/Cloud A's external router IP address.

And here, we're grabbing DemoProject1/Cloud A's local network IP address range.

We drop the router IP into two slots of DemoProject 2/Cloud B's IPSec Site Connection dialog, and supply the shared password. Then we click Add, and the VPN sets itself up.

Once you click Add on the IPSec Site Connection tab, you’ll have to wait a little bit for your VPN to go to Active status. If that doesn’t happen within a few minutes, there’s probably something wrong with your settings.

If this happens, check to make sure that protocol details on both sides match, that correct router gateway and subnet address range info for each side has been provided in the other side’s IPSec Site Connection tab, that PSK passwords match, and that subnet IP address ranges don’t overlap.

We're connected! The IPSec Site Connection shows as Active at both ends.

Testing VPNaaS

Now, let’s test. I’ve created two VMs, one in each Project, and associated them with floating IPs so I can SSH into them from my desktop. Let’s look at the internal IP of the VM on DemoProject2 (Cloud B) ... And then let’s log into the VM on DemoProject1 (Cloud A) and ping our new VPN friend on that internal IP address. Remember, we set each Project’s security group rules to admit ICMP traffic.

I'd previously launched two minimal VMs, one on each cloud, and given them floating IP addresses for open net access. Here, I'm picking up the internal IP address from the VM running in DemoProject2/Cloud B's project.

To do that, we're going to log into TestVM1, on DemoProject1/Cloud A, via its floating IP address — that's what we're grabbing, here.

It works! We log into TestVM1 on Cloud A, and we can ping the internal (not public) IP of TestVM2 on Cloud B. That proves our VPN can carry ICMP traffic.

Success! Finally, lets log into our friend using SSH with user/pass authentication and pass some TCP traffic.

And it can carry TCP traffic too, as we prove by SSHing into TestVM2 on Cloud B, from TestVM1 on cloud A, using user/pass authentication.

Simple and quick. In upcoming videos, we’ll be exploring some more-interesting use-cases for Mirantis OpenStack Express VPNaaS. Thanks for watching!

Mirantis OpenStack Express Basic Ops Tutorials

Mirantis OpenStack Express 2.0 — Mirantis' "Private Cloud as a Service" — is the fastest way to get your hands on a fully-functional, optimally-configured, private OpenStack cloud, running on hosted bare metal and able to scale on demand. This series of short tutorials shows how to perform common cloud operations tasks in MOX 2.0, and offers links to documentation and learning resources. Pro tip: though aimed at Mirantis OpenStack Express, many of the techniques discussed here will also work on a private OpenStack cloud deployed using Mirantis OpenStack.

Tutorials:

• Adding New Custom Boot Images
• Launching a VM from a Boot Image
• Creating a Block Storage Volume
• Attaching and Using Volumes
• Creating new VM Flavors
• Setting Up a project
• Murano in a Minute