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.
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:
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.
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 (18.104.22.168) Login credentials are:
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 22.214.171.124 and 126.96.36.199
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:
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:
|Interface||Which interface would be used to communicate with the other end of the tunnel|
|Remote Gateway||Enter the elastic IP of the other end of the tunnel (188.8.131.52)|
|My identifier||This is being used by the IPsec protocol to identify one of the ends of the tunnel|
|Peer identifier||The identifier of the other end of the tunnel|
|Pre-shared key||The password which needs to match on both ends of the tunnel|
|Security algorithm||This is used to determine how to encrypt and hash the data being sent. It’s important to ensure that these settings are mirrored on the other end of the tunnel.|
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:
|Local Network||Specifies which local network should be routed through the tunnel.|
|Remote Network||Specifies which is the remote network that the tunnel connects to (for outbound traffic)|
|Key Exchange Algorithm||This is used to determine how to encrypt and hash the data being sent. It’s important to ensure that these settings are mirrored on the other end of the tunnel.|
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.
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:
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:
Server host or addressto the hostname of the VPN server.
Server portto 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:
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.
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”).
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:
So all in all, your network configuration should look something like this:
This requires additional networking configuration and should be avoided for now, when using with VPN IPSec tunnel.
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.
Click the “e” icon to edit
Enter a new password twice (one for confirmation) and click “Save”
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:
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.
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.