Using VPN as a Service (VPNaaS) | User Guide

documentation.suse.com › Documentation › User Guide › Project User Guide › Using VPN as a Service (VPNaaS)

ContentsContents

User Guide

Navigation←→

Applies to HPE Helion OpenStack 8

15 Using VPN as a Service (VPNaaS)

15.1 Prerequisites
15.2 Considerations
15.3 Configuration
15.4 More Information

HPE Helion OpenStack 8 VPNaaS Configuration

This document describes the configuration process and requirements for the HPE Helion OpenStack 8 Virtual Private Network (VPN) as a Service module.

15.1 Prerequisites #

HPE Helion OpenStack must be installed.
Before setting up VPNaaS, you will need to have created an external network and a subnet with access to the internet. Information on how to create the external network and subnet can be found in Section 15.4, “More Information”.
You should assume 172.16.0.0/16 as the ext-net CIDR in this document.

15.2 Considerations #

Using the Neutron plugin-based VPNaaS causes additional processes to be run on the Network Service Nodes. One of these processes, the ipsec charon process from StrongSwan, runs as root and listens on an external network. A vulnerability in that process can lead to remote root compromise of the Network Service Nodes. If this is a concern customers should consider using a VPN solution other than the Neutron plugin-based VPNaaS and/or deploying additional protection mechanisms.

15.3 Configuration #

Setup Networks You can setup VPN as a Service (VPNaaS) by first creating networks, subnets and routers using the neutron command line. The VPNaaS module enables the ability to extend access between private networks across two different HPE Helion OpenStack clouds or between a HPE Helion OpenStack cloud and a non-cloud network. VPNaaS is based on the open source software application called StrongSwan. StrongSwan (more information available at http://www.strongswan.org/) is an IPsec implementation and provides basic VPN gateway functionality.

Note

You can execute the included commands from any shell with access to the service APIs. In the included examples, the commands are executed from the lifecycle manager, however you could execute the commands from the controller node or any other shell with aforementioned service API access.

Note

The use of floating IP's is not possible with the current version of VPNaaS when DVR is enabled. Ensure that no floating IP is associated to instances that will be using VPNaaS when using a DVR router. Floating IP associated to instances are ok when using CVR router.

From the Cloud Lifecycle Manager, create first private network, subnet and router assuming that ext-net is created by admin.

neutron net-create privateA
neutron subnet-create --name subA privateA 10.1.0.0/24 --gateway 10.1.0.1
neutron router-create router1
neutron router-interface-add router1 subA
neutron router-gateway-set router1 ext-net

Create second private network, subnet and router.

neutron net-create privateB
neutron subnet-create --name subB privateB 10.2.0.0/24 --gateway 10.2.0.1
neutron router-create router2
neutron router-interface-add router2 subB
neutron router-gateway-set router2 ext-net

Procedure 15.1: Starting Virtual Machines #

From the Cloud Lifecycle Manager run the following to start the virtual machines. Begin with adding secgroup rules for SSH and ICMP.

neutron security-group-rule-create default --protocol icmp
neutron security-group-rule-create default --protocol tcp --port-range-min 22 --port-range-max 22

Start the virtual machine in the privateA subnet. Using nova images-list, use the image id to boot image instead of the image name. After executing this step, it is recommended that you wait approximately 10 seconds to allow the virtual machine to become active.
```
NETA=$(neutron net-list | awk '/privateA/ {print $2}')
nova boot --flavor 1 --image <id> --nic net-id=$NETA vm1
```

Start the virtual machine in the privateB subnet.

NETB=$(neutron net-list | awk '/privateB/ {print $2}')
nova boot --flavor 1 --image <id> --nic net-id=$NETB vm2

Verify private IP's are allocated to the respective vms. Take note of IP's for later use.
```
nova show vm1
nova show vm2
```

Procedure 15.2: Create VPN #

You can set up the VPN by executing the below commands from the lifecycle manager or any shell with access to the service APIs. Begin with creating the policies with vpn-ikepolicy-create and vpn-ipsecpolicy-create .
```
neutron vpn-ikepolicy-create ikepolicy
neutron vpn-ipsecpolicy-create ipsecpolicy
```

Create the VPN service at router1.

neutron vpn-service-create --name myvpnA --description "My vpn service" router1 subA

Wait at least 5 seconds and then run ipsec-site-connection-create to create a ipsec-site connection. Note that --peer-address is the assign ext-net IP from router2 and --peer-cidr is subB cidr.

neutron ipsec-site-connection-create --name vpnconnection1 --vpnservice-id myvpnA \
--ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.16.0.3 \
--peer-id 172.16.0.3 --peer-cidr 10.2.0.0/24 --psk secret

Create the VPN service at router2.

neutron vpn-service-create --name myvpnB --description "My vpn serviceB" router2 subB

Wait at least 5 seconds and then run ipsec-site-connection-create to create a ipsec-site connection. Note that --peer-address is the assigned ext-net IP from router1 and --peer-cidr is subA cidr.

neutron ipsec-site-connection-create --name vpnconnection2 --vpnservice-id myvpnB \
--ikepolicy-id ikepolicy --ipsecpolicy-id ipsecpolicy --peer-address 172.16.0.2 \
--peer-id 172.16.0.2 --peer-cidr 10.1.0.0/24 --psk secret

On the Cloud Lifecycle Manager, run the ipsec-site-connection-list command to see the active connections. Be sure to check that the vpn_services are ACTIVE. You can check this by running vpn-service-list and then checking ipsec-site-connections status. You should expect that the time for both vpn-services and ipsec-site-connections to become ACTIVE could take as long as 1 to 3 minutes.

neutron ipsec-site-connection-list
+--------------------------------------+----------------+--------------+---------------+------------+-----------+--------+
| id                                   | name           | peer_address | peer_cidrs    | route_mode | auth_mode | status |
+--------------------------------------+----------------+--------------+---------------+------------+-----------+--------+
| 1e8763e3-fc6a-444c-a00e-426a4e5b737c | vpnconnection2 | 172.16.0.2   | "10.1.0.0/24" | static     | psk       | ACTIVE |
| 4a97118e-6d1d-4d8c-b449-b63b41e1eb23 | vpnconnection1 | 172.16.0.3   | "10.2.0.0/24" | static     | psk       | ACTIVE |
+--------------------------------------+----------------+--------------+---------------+------------+-----------+--------+

Verify VPN In the case of non-admin users, you can verify the VPN connection by pinging the virtual machines.

Check the VPN connections.
Note
vm1-ip and vm2-ip denotes private IP's for vm1 and vm2 respectively. The private IPs are obtained, as described in of Step 4. If you are unable to SSH to the private network due to a lack of direct access, the VM console can be accessed through Horizon.
```
ssh cirros@vm1-ip
password: <password>

# ping the private IP address of vm2
ping ###.###.###.###
```

In another terminal.

ssh cirros@vm2-ip
password: <password>

# ping the private IP address of vm1
ping ###.###.###.###

You should see ping responses from both virtual machines.

As the admin user, you should check to make sure that a route exists between the router gateways. Once the gateways have been checked, packet encryption can be verified by using traffic analyzer (tcpdump) by tapping on the respective namespace (qrouter-* in case of non-DVR and snat-* in case of DVR) and tapping the right interface (qg-***).

Note

When using DVR namespaces, all the occurrences of qrouter-xxxxxx in the following commands should be replaced with respective snat-xxxxxx.

Check the if the route exists between two router gateways. You can get the right qrouter namespace id by executing sudo ip netns. Once you have the qrouter namespace id, you can get the interface by executing sudo ip netns qrouter-xxxxxxxx ip addr and from the result the interface can be found.
```
sudo ip netns
sudo ip netns exec qrouter-<router1 UUID> ping <router2 gateway>
sudo ip netns exec qrouter-<router2 UUID> ping <router1 gateway>
```

Initiate a tcpdump on the interface.

sudo ip netns exec qrouter-xxxxxxxx tcpdump -i qg-xxxxxx

Check the VPN connection.

ssh cirros@vm1-ip
password: <password>

# ping the private IP address of vm2
ping ###.###.###.###

Repeat for other namespace and right tap interface.

sudo ip netns exec qrouter-xxxxxxxx tcpdump -i qg-xxxxxx

In another terminal.

ssh cirros@vm2-ip
password: <password>

# ping the private IP address of vm1
ping ###.###.###.###

You will find encrypted packets containing ‘ESP’ in the tcpdump trace.

15.4 More Information #

VPNaaS currently only supports Pre-shared Keys (PSK) security between VPN gateways. A different VPN gateway solution should be considered if stronger, certificate-based security is required.

For more information on the neutron command-line interface (CLI) and VPN as a Service (VPNaaS), see the OpenStack networking command-line client reference: http://docs.openstack.org/cli-reference/content/neutronclient_commands.html

For information on how to create an external network and subnet, see the OpenStack manual: http://docs.openstack.org/user-guide/dashboard_create_networks.html

Print this page