The VPNaaS Plugin for Fuel
Documentation
Release 1.2-1.2.0-1
Mirantis Inc.
1 Document purpose 1
1.1 Key terms, acronyms and abbreviations . . . 1
1.2 VPNaaS Plugin . . . 1
1.3 Requirements. . . 1
1.4 Limitations . . . 2
1.5 Known issues. . . 2
2 Installation Guide 3 2.1 Installing VPNaaS plugin . . . 3
2.2 Creating Environment with VPNaaS. . . 3
3 User Guide 5 3.1 Configuring VPNaaS service. . . 5
4 Appendix 20
5 Indices and tables 21
CHAPTER
ONE
DOCUMENT PURPOSE
This document provides instructions for installing, configuring and using Neutron Firewall-as-a-Service plugin for Fuel.
1.1 Key terms, acronyms and abbreviations
Term/abbreviationDefinition
VPNaaS VPN-as-a-Service. Neutron extension used to connect 2 private networks via Internet. IPSec Internet Protocol Security (IPsec) is a protocol suite for securing Internet Protocol (IP)
communications by authenticating and encrypting each IP packet of a communication session. OpenSwan An IPsec implementation for Linux. It has support for most of the extensions (RFC + IETF drafts)
related to IPsec, including IKEv2, X.509 Digital Certificates, NAT Traversal, and many others. IKE Internet Key Exchange is the protocol used to set up a security association (SA) in the IPsec
protocol suit.
VM Virtual Machine (Instance)
1.2 VPNaaS Plugin
VPNaaS (VPN-as-a-Service) Fuel plugin provides an opportunity to deploy and configure a VPNaaS Neutron exten-sion. VPNaaS Neutron extension introduces VPN feature set in Neutron which is based on Openswan (opensource IPSec implementation). The main goal is to provide VPN connection as a service between 2 private networks over the public network (in general via Internet).
That means, you can build a VPN connection between 2 private subnets, which can be placed in 2 different tenants and separate OpenStack clouds — for example, premise and hosted clouds in a hybrid application.
1.3 Requirements
Requirement Version/Comment
Fuel 7.0 release
OpenStack compatibility 2015.1 Kilo Operating systems Ubuntu 14.04 LTS
1.4 Limitations
VPNaaS plugin can be enabled only in environments with Neutron with ML2 plugin with OpenVSwitch Mechanism driver (default configuration) as the networking option and tested only with the OpenSwan driver.
1.5 Known issues
• [VPNaaS] Active VPN connection goes down after controller shutdown/start1
1https://bugs.launchpad.net/mos/+bug/1500876
CHAPTER
TWO
INSTALLATION GUIDE
2.1 Installing VPNaaS plugin
1. Download the plugin fromFuel Plugins Catalog1.
2. Copy the plugHin on already installed Fuel Master node:
[user@home ~]$ scp vpnaas-plugin-1.2-1.2.0-1.noarch.rpm root@:/ <the_Fuel_Master_node_IP>:~/
3. Log into the Fuel Master node. Install the plugin:
[root@fuel ~]# fuel plugins --install vpnaas-plugin-1.2-1.2.0-1.noarch.rpm
4. Verify that the plugin is installed correctly:
[root@fuel ~]# fuel plugins --list
id | name | version | package_version ---|---|---|---1 | vpnaas_plugin | 1.2.0 | 2.0.0
2.2 Creating Environment with VPNaaS
1. After plugin is installed, create a new OpenStack environment with Neutron. 2. Configure your environment2.
3. Open the Settings tab of the Fuel web UI and scroll down the page. Select VPNaaS plugin checkbox:
1https://software.mirantis.com/download-mirantis-openstack-fuel-plug-ins
4. Deploy your environment3.
2.2.1 References
3http://docs.mirantis.com/openstack/fuel/fuel-7.0/user-guide.html#deploy-changes
CHAPTER
THREE
USER GUIDE
3.1 Configuring VPNaaS service
Once OpenStack has been deployed, we can start configuring VPNaaS.
This section provides an example of configuration and step-by-step instructions for configuring the plugin.
Here is an example task. Let’s imagine that we have 2 Clouds, Public and Private (Cloud A and B). Each cloud has a Project with a private network which is connected to the Internet via router. In real life, Private networks are very often placed behind the NAT just like in our case.
Project:
In this network topology, we have a public Cloud A, directly connected to the real public network and private Cloud B, connected to the corporate private network and placed behind NAT (Bastion router).
Let’s get started.
Please, note the following when configuring VPNaaS plugin:
1. This is important for setting up VPNaaS, since router gateway IP addresses and other settings made to configure the VPN connection are only visible to the user who has an admin role.
2. 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 every Project in OpenStack is 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.
3.1.1 Configure VPNaaS on Cloud A
1. Let’s configure VPN. To do that, please selectNetworkoption in the left-hand menu and clickVPN.
2. CreateIKE Policy
(a) EnterKE Policiestab and clickAdd IKE Policybutton (see the screenshot above).
(b) We would recommend that you changed the Encryption algorithm, which should be set toaes-256and IKE version which should bev2.
3. CreateIPsec Policy
(a) EnterIPSec Policiestab and clickAdd IPSec Policybutton (see the screenshot in step 1 of this section).
(b) The defaults are fine, though it’s recommended to useaes-256encryption. Please pay attention that we should keep tunnelEncapsulation mode, because this mode allows to build tunnel between 2 private networks over public (transportis used only for the host-to-host VPN connection) andespTransform protocolwhich provides encryption for the payload data.
4. Create the VPN Service.
(a) EnterVPN Servicetab and clickAdd VPN Servicebutton (see the screenshot in step 1 of this section). (b) Here select a router that will work as our VPN gateway — that’s the local router; You should also pick up 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
5. CreateIPSec Site Connection.
(a) EnterIPSec Site Connectiontab and clickAdd IPSec Site Connectionbutton.
(b) This is the only mildly-tricky thing about setting up a VPN using VPNaaS. We start by identifying our
VPN Service, ourIKE Policyand ourIPSec Policy, defined just a moment before — that’s easy.
(c) To finish, however, we’ll need to get some information about the network architecturein Cloud_B. Cloud_B has theBastion, which is connected to the public network and also is used as NAT for the cor-porate network. For the building VPN connection through the NAT, IPSec has NAT-Traversal mechanism which is enabled by default.
(d) So let’s flip to Project_B’s Horizon, making sure we’re logged in as the admin, so we can see the info we need to know. Here we need to specifyBastion’s public IP addressinPeer gateway public IPv4/IPv6
Address or FQDNslot (see step 5):
(e) Further we specify Peer gateway public IPV4 address or fully-qualified domain name for Project_B’s router. This can be found by going to Project_B’sNetworktab, clicking on Router_B, the router name, and copying theIP address shown for the External gateway interface: in our case, it’s 172.24.4.45. This is the thing you won’t be able to see if you’re not in the admin role for this project.
(f) This IP address goes intoPeer router identity for authentication *(Peer ID)slots in theIPSec Site Connec-tionedit dialog for Project_A (see step 5):
(g) The second piece of info is the CIDR rangefor Project_B’s subnet. Again, go to Project_B’s Horizon, click theNetworktab, click on network, and copy the subnet CIDR range, which is 22.0.0.0/24.
(h) We’ll put that into theRemote Peer Subnetslot on Project_A’sIPSec Site Connectiondialog. Then to finish setting up Project_A’s IPSec Site Connection, we’ll provide apre-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 (see step 5):
3.1.2 Configure VPNaaS on Cloud B
Now let’s quickly set up the other end of the VPNaaS connection, over on Project_B. We’ll make sure protocol details and policies match.
1. On Project_B’sPSec Site Connectiontab, we’ll provide — in two places — the peergateway public IP address
for Project_A’s router andsubnet IP address range.
2. Now we set up the same components on Project_B. Setting upIKE Policy,IPSec PolicyandVPN Serviceare simple. For the IPSec Site Connection, we’ll need the same two pieces of info from Project_A that we needed for Project_B. Here, we’re grabbing Project_A’sexternal router IPaddress.
3. And here, we’re grabbing Project_A’slocal network IP address range.
4. CreateSec Site Connection
• Since Cloud_A is connected to the public network directly we just drop therouter IPinto two slots of Project_B’sIPSec Site Connectiondialog, and supply thePre-shared password.
• Then we click Add, and the VPN sets itself up.
5. Once you clickAddon theIPSec Site Connectiontab, you’ll have to wait a little bit for your VPN to go toActive
status (seeStatuscolumn in theIPSec Site Connectionstab). 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 asActiveat both ends.
3.1.3 Testing connectivity
Let’s open console of VM A on the Cloud_A,log into and try to ping VM B using their internal (not public) IP addresses.
Then do the same from console of VM B.
So it works!!! Now we have VPN connection between 2 private networks Net_70 (placed in Cloud_A/Project_A) and Net_22 (placed in Cloud_B/Project_B) and the virtual machines connected to these networks have secure direct connectivity.
FOUR
APPENDIX
# Title of resource Link on resource
1 Fuel Plugins CLI Link
2 Mirantis OpenStack Express VPN-as-a-Service (VPNaaS) Step-By-Step Link
CHAPTER