Home
This repository contains a sample HEAT template and instructions for deploying a VM into your OpenStack project to function as a VPN end-point, allowing secure connections to be made to other projects, vCloud Director VDCs, or back to your own infrastructure in-house.
These instructions make use of a pfSense Firewall Appliance to provide the IPSEC VPN endpoint. UKCloud provide an image for the pfSense Appliance in the public catalog, however you are welcome to upload your own image if you prefer. These are the steps we used to prepare the public pfSense Appliance image on our Cloud Native Infrastructure.
This example configuration assumes that you have already deployed certain resources in your project:
- A router connected to the 'internet' external network.
- A network / subnet with an interface added to the router.
- At least one linux VM running OpenSSH deployed on the subnet, having a floating IP address associated with it.
- An ssh client on your local desktop that is capable of connecting to the linux VM in your project, and can setup an SSH tunnel over the connection.
If you have not already deployed any resources in your project, have a look here for an example on how to get started.
The pfSense appliance assumes that it will have at least 2 NICs attached to it, one attached to the WAN and one or more attached to internal networks. To fit this into an existing infrastructure deployed in your project, and to avoid any nasty routing loops, the HEAT template will create a new WAN network along with an interface on your existing router. This will provide the WAN interface for pfSense and will have a floating IP address associated with it for the internet-facing end-point of the VPN tunnel.
The LAN interface of the pfSense appliance will attach to your existing internal network. Both WAN and LAN interfaces in the pfSense appliance image in the public catalog are configured for DHCP. This will allow the instance to seamlessly configure against your existing infrastructure.
Clone or take a copy of this repository. You will need to update the properties.yaml file to suit your deployed infrastructure. If you used the infrastructure.yaml HEAT template in this repository to build your core infrastructure, the properties will look similar to below:
parameters:
key_name: jumpbox_key
pfsense_flavor: t1.tiny
router: InternetGW
internal_network: Internal
internal_address: 192.168.1.254
internal_net_cidr: 192.168.1.0/24
remote_net_cidr: 10.1.1.0/24
where InternetGW is the name of your router, Internal is the name of your existing network, and internal_address is the address on your existing network that will be assigned to the LAN interface on the appliance.
Note that this HEAT template assumes that your VPN tunnel is only connecting to a single remote network. If you need to route to multiple remote networks, after completing the deployment you will need to follow a few more configuration steps.
Using the OpenStack CLI tools, the stack can be launched by running:
openstack stack create --enable-rollback -t pfsense.yaml -e properties.yaml --wait VPNStack
The stack can also be launch through the Horizon Web UI by selecting the pfsense.yaml and properties.yaml files appropriately when prompted.
Once the HEAT template has finished deploying your vpn stack, you will need to connect to the pfSense appliance in order to configure the IPSEC Tunnel. While some configuration can be performed through the OpenStack console, or an SSH connection to the appliance, most configuration is via it's web UI. The pfSense UI only listens on it's LAN interface, so it cannot be used directly via the internet-facing floating IP address on it's WAN interface.
Connecting to the pfSense UI requires using SSH port forwarding to tunnel a connection through the jumpbox server connected to the internal network, onto the LAN interface of the pfSense appliance. With a command line ssh client, you would typically run:
ssh -i ~/.ssh/jumpbox.pem -l jumpboxuser -L 80:192.168.1.254:80 <jumpbox floating IP address>
where 192.168.1.254 is the address allocated to the LAN interface of the appliance. If you are using a windows desktop, you may want to try using PuTTY for the SSH port forwarding.
All being well, you should now be able to browse to http://localhost/ and get the pfSense Login Screen.
Login with username admin and if you are using the image provided by UKCloud, the password is set to Password123#
Once logged in, the first thing you will want to do is update the LAN interface configuration. While in the image, the interface is configured to use DHCP to bring the instance up for initial configuration, once you start adding static routes to the internal subnet in your project, you do not want the LAN interface to receive those routes via the DHCP configuration otherwise it will result in a routing loop and traffic will not be passed across the VPN to the remote network. Click on the Interfaces > LAN menu and update the following settings:
- IPv4 Configuration Type: Static IPv4
- IPv4 Address: 192.168.1.254 /24
- IPv4 Upstream gateway: None
Save the Settings to continue.
For the purpose of this example, we are assuming the following tunnel configuration. You will need to substitute your own values accordingly:
OpenStack Network pfSense VPN Endpoint Remote Network
----------------- ------- ------------ --------------
LAN: 192.168.1.254 LAN: 10.1.1.1
192.168.1.0/24 <-----> WAN: 172.16.1.XXX <-------------> WAN: YYY.YYY.YYY.YYY <-----> 10.1.1.0/24
Floating IP: XXX.XXX.XXX.XXX
Pre-shared Key: D3v0psD3m0D3v0psD3m0D3v0psD3m0D3v0psD3m0
Click on the VPN > IPsec menu to take you to the IPsec Tunnels page, then click on the Add P1 button to start configuring this endpoint of the tunnel.
In the Edit Phase 1 page you will need to set the following values:
- Remote Gateway: YYY.YYY.YYY.YYY
- Description: My VPN Connection
-
My identifier:
IP AddressXXX.XXX.XXX.XXX -
Peer identifier:
IP AddressYYY.YYY.YYY.YYY - Pre-Shared Key: D3v0psD3m0D3v0psD3m0D3v0psD3m0D3v0psD3m0
Save the settings. Now click the Add P2 button to complete the rest of the tunnel configuration.
In the Edit Phase 2 page you will need to set the following values:
- Local Network: LAN subnet
- NAT/BINAT translation: None
-
Remote Network:
Network10.1.1.0 / 24 - Description: My remote network
Save the settings. You should now have a IPsec Tunnels page looking like this.
The default firewall rules allow outbound traffic from the LAN network. This is sufficient to allow the IPSEC tunnel to be established and to also allow traffic from our internal network to be routed across the tunnel, however you need to add a new firewall rule to allow returning traffic from the remote network to be routed back to the LAN network.
Click on the Firewall > Rules menu and select the IPsec tab. For this example, since we are trusting all traffic from the LAN network to the remote network, we will just add a single rule to accept all traffic from the remote network back into the LAN network. In your environment, you will probably want to be more specific with your rule definitions.
To add a new rule on the IPsec tab, click one of the Add buttons and set the following values:
- Action: Pass
- Interface: IPsec
- Protocol: any
-
Source:
Network10.1.1.0 / 24 -
Destination:
LAN net - Description: Allow all remote traffic
Save the rule and you should have a screen showing the firewall rules like below:
At this point you now want to ensure that the other end of the VPN tunnel is also configured. If you are connecting two OpenStack projects, you could repeat these instructions to deploy another pfSense appliance into the remote project.
Connecting an IPsec tunnel to a vShield Edge on a VDC in our Enterprise Compute environment can be problematic, since the Web UI does not set the local identifier correctly. You have to make use of a REST Client against the vCloud Director API to manually correct the tunnel configuration. The process is documented in a Knowledge Centre article available through the UKCloud Portal.
There is an automated way however to setup the vShield Edge IPsec tunnel without using the Web UI. We have provided a script written in ruby that automates the interaction with the vCloud Director API to correctly setup the VPN endpoint from scratch. Have a look at the ukcloud-vpn documentation for more details.
By now, if the configuration of both endpoints match, the IPsec tunnel should already have completed both Phase 1 & 2 negotiations and have established a tunnel. You can check from the Status > IPsec menu.
