This page documents the general process and things that are important to keep in mind when you want to create a VPN tunnel to a network that is located inside of OpenStack, it is not at all an impossible task, but it does require you to plan the network topology and have a good understanding of networking in OpenStack, routing, the neutron command client and last but not least, the VPN product/Protocol that you intend to use.
With that in mind we can start looking at the simple scenario that is shown in the diagram below.
The goal here is the have connectivity between the server on the left-most side and the instance on the right-most side, and this connection will be made through the site-to-site tunnel. This document will focus on the components found on the right side which exist in OpenStack, namely the VPN server instance, the OpenStack-network and a ordinary instance connected to the network. There is one important detail on the left side and the subnet-id of the "Other end network", we use an example of 172.24.0.0/24.
The topology below shows the three OpenStack components and how they would be setup inside of OpenStack.
In our scenario this is the network that we want to access through the VPN tunnel.
Default gateway: 192.168.10.1
DHCP-range: 192.168.10.10, 192.168.10.2
Static route: 172.24.0.0/ 192.168.10.2
DNS name servers: 188.8.131.52, 184.108.40.206
A static route makes sure that traffic destined for the "Other end network" is sent to the VPN server at 192.168.10.2, all other traffic is sent to the default gateway.
The VPN server on the OpenStack side. This is just an ordinary instance running the image of your choice, it could be a Linux or Window server running your desired VPN server/Tunneling protocol. We also have a PfSense image available in the portal which comes with number of tunneling protocols pre-installed. Before you try and configure any kind of VPN please read the sections below A word on security groups and Allowed address pairs.
Local IP: 192.168.10.2
Floating IP: 220.127.116.11
A word on security groups
To make it easier when first setting up your tunnel make the instance a member of the security group called all, this will allow all traffic to flow to and from the instance making it easier to rule out connectivity problems during the initial setup. Once traffic is going through the tunnel you can start filtering traffic with different security groups if you want to.
Allowed address pairs
Before any types of traffic can go back forth through the tunnel you will need to change what mac_address/ip_address(cidr) pairs that are allowed to pass through the VPN servers port, this can be achieved with the neutron port-update command.
$ neutron port-update <port-uuid> --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr>
Now we can update the port to allow connections from other source addresses, note that we leave out the mac_address= Option to allow connections from any MAC-address. We specify ip_address= 172.24.0.0/24 which is the subnet on the other end of the VPN tunnel.
$ neutron port-update 31ded746-60a7-4ac2-9e11-18950980f21c --allowed-address-pairs type=dict list=true ip_address=172.24.0.0/24
Note! Ip_address CIDR
If you specify a CIDR for ip_address= try to keep them as restrictive as possible and only allow what you need. An allowed address pair can take precedence over security groups leaving you instance exposed if you are not careful. Stick to single IP addresses with a subnet mask of /32 or the private address spaces 10.0.0.0/8, 172.16.0.0/16. Avoid IP addresses/adress spaces that are route-able on the public Internet as this might leave your instance exposed on it's floating IP.
Instances can be launched on the OpenStack-network as usual and get their IP-addresses assigned with DHCP, it can access the Internet through the default gateway at 192.168.10.1 and the VPN thanks to the static route to 192.168.10.2. So if the OpenStack-network is correctly configured, both the VPN server in OpenStack and the "other end VPN server" are setup accordingly, then you should be able to ping the "other end server".
If you are having problems getting ping through, add only the security group called all to this instance to tule out the firewall filtering your traffic.