Objective
This guide provides an outline of how to configure a virtual private network between an on-premises Zerto platform and an OVHcloud Hosted Private Cloud. We will use the OPNsense open-source VPN Solution as an example, and explain the simplest way to set up a VPN tunnel to the Zerto network.
Find out how to get started with a VPN for OVHcloud Zerto DRP.
Requirements
- one public IP, available on the target Hosted Private Cloud for the VPN endpoint
- a Zerto platform installed on the on-premises platform
- To get the installation package for the On-Prem ZVM, please click here. Password for the file is OVHcloudShare
- Note: You must be logged into your OVHcloudShare Account to be able to download the file.
- To get the installation package for the On-Prem ZVM, please click here. Password for the file is OVHcloudShare
- VRAs (Virtual Replication Appliances) on both sides that are able to connect to the counterpart on TCP ports 4007 and 4008
- Zerto administration consoles or ZVMs (Zerto Virtual Managers) that are able to connect to the counterpart on TCP port 9081
Solution overview
Listed parameters:
On-premises side:
- VPN endpoint public IP address (1)
- VPN endpoint internal IP address (2)
- ZVM internal IP address (3)
- ZVM internal network (4)
OVHcloud side:
- VPN endpoint public IP address (5)
- ZVM internal network (6)
- ZVM internal IP address (7)
Instructions
You need to decide which network to deploy the OVHcloud ZVM in. This avoids any overlap with local networks, which would prevent routing.
You can either accept the suggested network or provide your own, as long as it is within a valid /23 range.
Step 1: Activate Zerto features.
It is easy to activate Zerto features from the OVHcloud Control Panel. You just need to select the datacenter linked to the Hosted Private Cloud solution that you want to use, from the Disaster Recovery Plan tab.
First select Between your infrastructure and an OVHcloud Private Cloud, then click Enable Zerto DRP. Next, select a free public IP from the drop down menu and enter the desired network range for the ZVM deployment. Confirm the VRA Network range and then click Install.
Proceed through the following menu, selecting you IP address pool, VRA datacenter network, and your on premises network.
Step 2: Activate IPSec service.
From the OPNsense interface, go to the VPN menu on the left, IPSec section and select Tunnel Setting. Click Enable IPsec and click save.
Step 3: Set up IPSec tunnel.
You can configure the IPSec tunnel by defining two sets of parameters: Phase 1 and Phase 2.
3.1 Set up Phase 1.
In the VPN menu, go to Tunnel settings, and click on the + to add a new Phase 1:
3.1.1 Phase 1: General information.
If the default values are correct:
- Connection Method: Default
- Key Exchange version: V2
- Internet Protocol: IPV4
- Interface: WAN
The only required parameter is the OVHcloud IPSec endpoint IP address.
3.1.2 Phase 1: Authentication.
Once the default values are valid, you only need to provide the shared secret for authentication.
3.1.3 Phase 1: Encryption algorithms.
Supported values for each parameters:
- Encryption algorithms: AES 256 bits
- Hash algorithms: SHA256
- Duffie-Hellman key group: 14 (2048 bits)
- Lifetime: 28,800 seconds
You can keep the default values for the other parameters. Click Save, then Apply changes.
The new Phase 1 is now present in the interface:
3.2 Set up Phase 2.
Click on +.
3.2.1 Phase 2: General information
Check that the mode is set to "Tunnel IPV4".
3.2.2 Phase 2: Local Network
The local network type must be set to "Lan subnet".
3.2.3 Phase 2: Remote Network
You need to give the OVHcloud side VRA IP Network.
On OVHcloud side, the VRA network is always a /23 network (512 IPs).
Warning: Make sure to double-check the parameters, otherwise the VPN tunnel won't come up.
3.2.4 Phase 2: Key exchange
Supported values are:
- Protocol: ESP
- Encryption algorithm: AES 256 bits
- Hash algorithms: SHA256
- PFS: Off
You can leave advanced parameters to their default value. Click Save, then Apply changes.
3.3. Check VPN status.
Click the orange triangle on the right to initialize the connection:
If all the parameters are correct, the tunnel will come up and two new icons will appear:
- tear down tunnel
- tunnel information
Click on the information icon.
The tunnel is now up. Make sure to add, if required, a route to the OVHcloud ZVM network on your local ZVM.
Troubleshooting
If the tunnel is not coming up, make sure that the parameters values are identical on both sides:
- Shared secret
- Remote endpoint IP address
- Remote network range
Make sure that a firewall is not interfering in the dialog between the local and remote endpoints.
You can check the IPSec log file in /var/log/ipsec.log on the OPNsense appliance to get more information.
Step 4: Set up firewall.
To allow pairings of on-premises and OVHcloud instances, traffic must be authorized on the following ports:
- TCP 9071 to 9081 between ZVMs
- TCP 4007/4008 between vRAs
4.1 ZVM opening
Go to the Firewallmenu, Rules section, IPSecinterface:
Click on Add to create a new rule.
Rule parameters are as follow:
- Action: "Pass" (authorize traffic)
- Interface: "IPsec" (incoming traffic coming from the VPN tunnel)
- Protocol: "TCP"
For "Source" and "Destination", select "Single host or Network" type. The source is the OVHcloud ZVM, and the destination is your on-premises ZVM.
Destination TCP port range is 9071 to 9081. Click Save and Apply Change.
4.2 VRAs opening.
VRAs opening is a bit more complex since there are multiple VRAs on each side that need to be able to exchange information on TCP ports 4007 and 4008. To simplify this setup, we are going to use the alias feature of OPNsense. An alias is a group of objects IPs, networks, URLs…) that can be used in firewall rules.
We will define three aliases:
- one for VRA IPs on the On-Prem side
- one for VRA IPs on the OVHCloud side
- one for the ports
You can get the OVHcloud VRAs IP from the destination Private Cloud vCenter interface.
Let's create the OVH_VRA alias for OVHcLoud VRAs:
Similarly, we can create an alias for the on-premises vRAs:
Finally, you need to create the ports alias:
We have now all the elements we need to implement the required firewall rules to authorize data coming from the OVHcloud platform. It is the same procedure as before, we just need to use the aliases instead of explicit IPs or ports:
At this point, we have a functional and secure link between our on-premises platform and cloud instance.
Now that all of the network flows and rules have been created, we need to pass them to the OVHcloud side VPN to activate the connection.
To do this, you go back to OVHcloud Manager. You will see that it is requesting you to input the information to complete the setup. The following information will be needed.
Step 5: ZVM Pairing
As of Zerto 7.5, the pairing method now requires a token. To get your pairing token, login to your OVHcloud ZVM. Go to the sites Menu, and click the Key Icon labeled Generate Pairing Token. This will provide you the token that is good for 48 hours or until Paired.
Log in in to your on-premises ZVM. The following screen is displayed:
Select Pair to a site with a licence, enter the OVHcloud ZVM IP and the token generated in your OVHcloud ZVM, then press Start.
In the dashboard, you can see the pairing is ongoing:
You will be notified when the pairing is successful:
You can check that your OVHcloud PCC is visible in the Sites tab.
At this point, your Zerto setup is functional and you can start to create your virtual protection groups (VPGs).
Troubleshooting
If the on-premises ZVM is not able to successfully contact the OVHcloud ZVM (due to an incorrect firewall setup, for example) you will get the following message:
You will then be brought back to the log-in screen, with the following error message:
The most probable cause is that the OVHcloud ZVM is not authorized to contact your on-premises ZVM on TCP 9081 (it needs to be able to initiate the connection).
Step 6: Installing VRAs on Hosts
Once the site's are paired you will get a popup once inside the UI informing you that you need to deploy VRAs to all hosts. Each host needs to have it's own VRA. The requirements for the VRAs and how to configure them can be found here and here respectively.