In this article by Omar Khedher, author of the book Mastering OpenStack, we will create a VPN setup between two sites using the Neutron VPN driver plugin in Neutron. The VPN as a Service is a new network functionality that is provided by Neutron, which is the network service that introduces the VPN feature set. It was completely integrated in OpenStack since the Havana release. We will set up two private networks in two different OpenStack sites and create some IPSec site-to-site connections. The instances that are located in each OpenStack private network should be able to connect to each other across the VPN tunnel. The article assumes that you have two OpenStack environments in different networks.
The following figure illustrates the VPN topology between two OpenStack sites to provide a secure connection between a database instance that runs in a data center in Amsterdam along with a web server that runs in a data center in Tunis. Each site has a private and a public network as well as subnets that are managed by a neutron router.
The VPN driver plugin must be configured in /etc/neutron/neutron.conf. To enable it, add the following driver:
# nano /etc/neutron/neutron.conf
service_plugins = neutron.services.vpn.plugin.VPNDriverPlugin
Next, we'll add the VPNaaS module interface in /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py, as follows:
'enable_VPNaaS': True,
Finally, restart the neutron-server and server web using the following commands:
# service httpd restart
# /etc/init.d/neutron-server restart
Let's assume that each OpenStack site has at least a router attached within an external gateway and can provide access to the private network attached to an instance, such as a database or a web server virtual machine. A simple network topology of a private OpenStack environment running in the Amsterdam site will look like this:
The private OpenStack environment running in the Tunis site will look like the following image:
Neutron offers several commands that can be used to create and manage the VPN connections in OpenStack. The essential commands that are associated with router management include the following:
In the first VPN phase, we can create an IKE policy in Horizon. The following figure shows a simple IKE setup of the OpenStack environment that is located in the Amsterdam site:
The same settings can be applied via the Neutron CLI using the vpn-ikepolicy-create command, as follows:
Syntax: neutron vpn-ikepolicy-create --description <description> --auth-algorithm <auth-algorithm>
--encryption-algorithm <encryption-algorithm> --ike-version <ike-version> --lifetime <units=UNITS,
value=VALUE> --pfs <pfs> --phase1-negotiation-mode <phase1-negotiation-mode> --name <NAME>
An IPSec policy in an OpenStack environment that is located in the Amsterdam site can be created in Horizon in the following way:
The same settings can be applied via the Neutron CLI using the vpn-ipsecpolicy-create command, as follows:
Syntax: neutron vpn-ipsecpolicy-create --description <description> --auth-algorithm
<auth-algorithm> --encapsulation-mode <encapsulation-mode> --encryption-algorithm <encryption-algorithm>
--lifetime <units=UNITS,value=VALUE> --pfs <pfs> --transform-protocol <transform-algorithm> --name <NAME>
To create a VPN service, you will need to specify the router facing the external and attach the web server instance to the private network in the Amsterdam site. The router will act as a VPN gateway. We can add a new VPN service from Horizon in the following way:
The same settings can be applied via the Neutron CLI using the vpn-service-create command, as follows:
Syntax: neutron vpn-service-create --tenant-id <tenant-id> --description <description> ROUTER SUBNET --name <name>
The following step requires an identification of the peer gateway of the remote site that is located in Tunis. We will need to collect the IPv4 address of the external gateway interface of the remote site as well as the remote private subnet. In addition to this, a pre-shared key (PSK) has to be defined and exchanged between both the sites in order to bring the tunnel up after establishing a successful PSK negotiation during the second phase of the VPN setup. You can collect the router information either from Horizon or from the command line. To get subnet-related information on the OpenStack Cloud that is located in the Tunis site, you can run the following command in the network node:
# neutron router-list
The preceding command yields the following result:
We can then list the ports of Router-TN and check the attached subnets of each port using the following command line:
# neutron router-port-list Router-TN
The preceding command gives the following result:
Now, we can add a new IPSec site connection from the Amsterdam OpenStack Cloud in the following way:
Similarly, we can perform the same configuration to create the VPN service using the neutron ipsec-site-connection-create command line, as follows:
Syntax: neutron ipsec-site-connection-create --name <NAME>
--description <description> ---vpnservice-id <VPNSERVICE>
--ikepolicy-id <IKEPOLICY> --ipsecpolicy-id <IPSECPOLICY>
--peer-address <PEER-ADDRESS> --peer-id <PEER-ID>
--psk <PRESHAREDKEY>
A complete VPN setup requires you to perform the same steps in the OpenStack Cloud that is located in the Tunis site. For a successful VPN phase 1 configuration, you must set the same IKE and IPSec policy attributes and change only the naming convention for each IKE and IPSec setup. Creating a VPN service on the second OpenStack Cloud will look like this:
The last tricky part involves gathering the same router information in the Amsterdam site. Using the command line in the network node in the Amsterdam Cloud side, we can perform the following Neutron command:
# neutron router-list
The preceding command yields the following result:
To get a list of networks that are attached to Router-AMS, we can execute the following command line:
# neutron router-port-list Router-AMS
The preceding command gives the following result:
The external and private subnets that are associated with Router-AMS can be checked from Horizon as well. Now that we have the peer router gateway and remote private subnet, we will need to fill the same PSK that was configured previously. The next figure illustrates the new IPSec site connection on the OpenStack Cloud that is located in the Tunis site:
At the Amsterdam site, we can check the creation of the new IPSec site connection by means of the neutron CLI, as follows:
# neutron ipsec-site-connection-list
The preceding command will give the following result:
The same will be done at the Tunis site, as follows:
# neutron ipsec-site-connection-list
The preceding command gives the following result:
For VPNaaS to work when connecting the Amsterdam and Tunis subnets, you will need to create a few additional rules in each project's default security group to enable not only the pings by adding a general ICMP rule, but also SSH on port 22. Additionally, we can create a new security group called Application_PP to restrict traffic on port 53 (DNS), 80 (HTTP), and 443 (HTTPS), as follows:
# neutron security-group-create Application_PP --description "allow web traffic from the Internet"
# neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 80
--port_range_max 80 Application_PP --remote-ip-prefix 0.0.0.0/0
# neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 53
--port_range_max 53 Application_PP --remote-ip-prefix 0.0.0.0/0
# neutron security-group-rule-create --direction ingress --protocol tcp --port_range_min 443
--port_range_max 443 Application_PP --remote-ip-prefix 0.0.0.0/0
From Horizon, we will see the following security group rules added:
In this article, we created a VPN setup between two sites using the Neutron VPN driver plugin in Neutron. This process included enabling the VPNaas, configuring the site, and creating an IKE policy, an IPSec policy, a VPN service, and an IPSec connection.
To continue Mastering OpenStack, take a look to see what else you will learn in the book here.