How to setup VPN for environment running in Ravello from a vanilla pfSense image

Ravello’s nested virtualization and overlay networking technology allows for fast application development and testing by encapsulating entire application environments in cloud agnostic capsules. This capability makes it easy to quickly spin hundreds of versions of the capsules in the cloud, which is typical of a continuous integration setup. There is often times a need to connect the Ravello environment to another public cloud, or an on-premise private cloud servers, databases, repositories, etc. For example, in a continuous integration setup where the code repository is on premise, there needs to be a connection to the Ravello environment in the cloud via a secure tunnel.

The goal of this article is to showcase how to setup a secure VPN between two Ravello environments, one in AWS EC2 and one in Google Cloud. This setup mocks a scenario where, while one environment is running Ravello in either Google or AWS, the other could be an on-premise data center or customer’s VPC in AWS or some third party data center.

IPSEC or OpenVPN?

The two options we will describe here are ISPEC and OpenVPN.

Each has its known advantages and disadvantages as described here.

In addition to those known advantages and disadvantages, there are also Ravello’s specific advantages and disadvantages. Here is a list:

• In order for IPSEC to work properly, you need a static public IP. In Ravello you therefore need to use “elastic IP”. Currently, when using elastic IP, you must use Ravello’s proxy/router which has some performance bursts (this is scheduled to be fixed in the next few months). So please be aware that using IPSEC in Ravello might have some performance bottlenecks every once in a while.
• OpenVPN is using a client-server topology in which only the client needs access the server. This is great for an on-premise OpenVPN client as you do not need to open any firewall in your on-premise site.
• OpenVPN is works better in Ravello with port forwarding (rather than “elastic IP”. However, when working with port forwarding in Ravello, the destination port might change in some cases (for example adding/removing some additional supplied services). Such a port change will force a matching configuration change in the VPN Client.

IPSEC

The following settings will need to be adapted to your environment, in order to route the traffic through the pfSense gateway, which will be one of the endpoints of the VPN tunnel.

Ravello GUI

1. WAN Static IP: 10.10.10.1 (the other node will use 10.10.10.2)
2. WAN Elastic IP: 85.190.178.133
   
    
3. LAN: 192.168.1.1 (the other node will use 192.168.2.1)
   
4. Supplied services (on WAN interface)-

    

   1. UDP ports needed are 500(phase 1 IPSEC), 4500 (Phase 2 IPSEC) and 88 (Kerberos).
   2. TCP ports needed are 80 and 443 (for web interface).

   

pfSense GUI

The VPN IPsec tunnel setting will be created through the web interface of the pfSense virtual appliance.

Copy and paste the Elastic IP of your pfSense appliance into your browser (use https:// prefix) to access the Web UI admin page (85.190.182.122) Login credentials are:
username: admin
password: pfsense (unless you have changed it yourself earlier)

The setup of the tunnel is comprised of two phases:

Phase 1 specifies how the tunnel connects to its remote peer (the other end of the tunnel).

Phase 2 specifies which local network traffic/subnets should be sent through the tunnel. This division makes it possible for the tunnel to handle requests from multiple local subnets. In this example, there will only be one local subnet: 192.168.2.0/24 connecting to 192.168.1.0/24 through the tunnel that has the to endpoints 85.190.182.122 and 85.190.178.133

Before configuring the IPSEC, It is crucial not to forget to add firewall rules in the WAN interface to allow incoming connections (3 rules for UDP ports 88,500,4500):

Also, do not forget of course to enable IPSEC:

Phase 1 configuration

Navigate to VPN > IPsec from the top navigation. Double click the first row in the table. The main components of the Phase 1 configuration are:

Phase 2 configuration

Click Save to navigate back to the main VPN IPsec configuration page. Click the + sign under the first row in the table to see the Phase 2 summary. Double click the row to make changes.
The main components of the Phase 2 configuration are:

The 2nd IPSEC peer

If you are using another pfSense machine in another application, you will need to perform the previous steps in a similar way (just change the source and destination addresses - you will also need to change the address in LAN interface itself).
If connecting your Ravello environment to a private data center, you will need to configure the VPN IPsec settings in your specific router. The steps and terminology involved are similar, but the navigation/UI differs from vendor to vendor.

Establish the VPN IPsec tunnel

In order to establish the VPN IPsec tunnel, navigate to Status > IPsec and click the “Connect” button on the right of the row.

A successful tunnel will display similarly to the screenshot below:

Using OpenVPN instead of IPSec

As written above, For improved performance in Ravello, OpenVPN peer to peer should be used instead of IPSEC. This is because with OpenVPN you can control the port of the remote VPN endpoint and by that you can use port forwarding instead of elastic IP. Elastic IPs along with VPN can result in performance overhead due to external Internet routing infrastructure used.

To configure pfSense as OpenVPN Peer to Peer with a shared key read this.

It is crucial not to forget to add a firewall rule in the OpenVPN server to allow incoming connections:

So after setting OpenVPN client and server, set the OpenVPN server WAN interface to use port forwarding and add a supplied service to UDP port 1194.

Then, in the OpenVPN client, you will need to set:

1. Server host or address to the hostname of the VPN server.
2. Server port to the port used for OpenVPN port (UDP 1194) forwarding in the OpenVPN server (usually 10002 - note that this port number might change after OpenVPN VM restart).

So all in all, the server configuration should look something like this:

and the client should look something like this:

LAN testing

Allowing traffic in OpenVPN/IPSEC interface

In order to allow traffic between 2 sides, you need to add a rule in the firewall. In my example, I allowed all OpenVPN traffic for any protocol on both sides (this includes ping/ICMP packets). A similar thing should be done when using IPSEC instead of OpenVPN.

Testing traffic through the tunnel

Finally, in order to ensure that the local traffic is routed through the tunnel, navigate to Diagnostics > Ping and ping a local IP address from the other end of the tunnel (note - make sure “Source Address” is set to “LAN”).

Networking configuration of other machines/Vms in the environment configured with VPN

If no inbound internet access is required to the Vms in the Ravello application environment

This is the recommended settings for your VMs. You probably just need to be able to access the internet from those VMs and to be able to access those VMs from other VMs in your application or in the remote site of the VPN. If you for some reason do need inbound access from the internet to VM, please go to this section.

So, in order to configure your machines to properly use the VPN, You need to:

1. Give those machines a static IP address (In this example I will give 192.168.2.2).
2. In case you are using the 192.168.1.x or 192.168.2.x networks (this is how we recommend in this blog), you need to set the Netmask to 255.255.255.0. In case you are using a different network, you will need to assign the matching netmask.
3. Set the Gateway to the VPN’s machine address (In this example I will give 192.168.2.1 as this is the VPN’s address).
4. No need for DNS.

So all in all, your network configuration should look something like this:

If the Vms in the Ravello application environment are configured with DHCP address

This requires additional networking configuration and should be avoided for now, when using with VPN IPSec tunnel.

If inbound internet access is required to the Vms in the Ravello application environment

In case you need inbound traffic from the internet to the VM, it is recommended that you will add another network interface in the VM for that using a new network in your application (10.20.0.x in my example here). You need to configure the routing table in your VM in such a way that the connections to the remote application through the VPN will be routed via the VPN as the gateway and other traffic will be routed using a new gateway defined in Ravello.

Hardening

1. Make sure using only the following Published Services:
   1. TCP ports needed are 80 and 443 (for web interface).
   2. VPN ports:
      1. For IPSEC - UDP ports needed are 500(phase 1 IPSEC), 4500 (Phase 2 IPSEC) and 88 (Kerberos).
      2. For OpenVPN, UDP 1194 is needed.
2. Change the “admin” password:
   In the web interface, Click “System”->”User Manager”

    

   

   Click the “e” icon to edit

   

   Enter a new password twice (one for confirmation) and click “Save”

3. If for some reason you use HTTP and not HTTPS, use HTTPS web access
   Click “System” -> “Advanced”

    

   

   Change “HTTP” to “HTTPS” and click “Save” (at the bottom of the page). Please note that depends on your certificate, you might get a warning message such as this the next times you enter the web interface:

   

Important Notes

IP fragmentation/Jumbo packets/MTU

When a packet is nearly the size of the maximum transmission unit (MTU) of the physical port, and it is encapsulated with IPsec headers, it probably will exceed the MTU of the interface. This situation causes the packet to be fragmented after encryption (post-fragmentation), which requires the IPsec peer to perform reassembly before decryption. In addition, sometimes fragmented IP packets might cause other problems and even get lost in the way.

Moreover, in Ravello, IPSEC VPN needs Elastic IP (see here) which is causing another encapsulation and therefore increases the size of the packet.
This scenario is even more common with jumbo packets which are split to several maximum-MTU packets.
It is therefore highly recommended to reduce the MTU size of the VMs running in Ravello to something much smaller than 1500 (1300 to be 100% safe). If you will not reduce the MTU size of your VMs, packets might get lost.

Reverse DNS resolving

Ravello’s DNS sometimes uses the cloud provider’s DNS for resolving host names into IPs and for reverse resolving IPs to host names. When connecting two applications in Ravello using DNS, you might have a routable IP address on remote application with an internal IP - like for an example 192.168.1.2. If you try to nslookup this IP, you might get an internal cloud provider machine. Just be aware of this situation when using DNS.