Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Applies to SUSE OpenStack Cloud 8

15 Using VPN as a Service (VPNaaS) Edit source

SUSE OpenStack Cloud 8 VPNaaS Configuration

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

15.1 Prerequisites Edit source

  1. SUSE OpenStack Cloud must be installed.

  2. 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”.

  3. You should assume 172.16.0.0/16 as the ext-net CIDR in this document.

15.2 Considerations Edit source

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 Edit source

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 SUSE OpenStack Cloud clouds or between a SUSE OpenStack Cloud 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
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
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.

  1. 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
  2. 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
  1. 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
  2. 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
  3. 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
  4. 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
  1. 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
  2. Create the VPN service at router1.

    neutron vpn-service-create --name myvpnA --description "My vpn service" router1 subA
  3. 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
  4. Create the VPN service at router2.

    neutron vpn-service-create --name myvpnB --description "My vpn serviceB" router2 subB
  5. 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
  6. 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.

  1. Check the VPN connections.

    Note
    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 ###.###.###.###
  2. In another terminal.

    ssh cirros@vm2-ip
    password: <password>
    
    # ping the private IP address of vm1
    ping ###.###.###.###
  3. 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
Note

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

  1. 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>
  2. Initiate a tcpdump on the interface.

    sudo ip netns exec qrouter-xxxxxxxx tcpdump -i qg-xxxxxx
  3. Check the VPN connection.

    ssh cirros@vm1-ip
    password: <password>
    
    # ping the private IP address of vm2
    ping ###.###.###.###
  4. Repeat for other namespace and right tap interface.

    sudo ip netns exec qrouter-xxxxxxxx tcpdump -i qg-xxxxxx
  5. In another terminal.

    ssh cirros@vm2-ip
    password: <password>
    
    # ping the private IP address of vm1
    ping ###.###.###.###
  6. You will find encrypted packets containing ‘ESP’ in the tcpdump trace.

15.4 More Information Edit source

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