Nutanix customers can set up a secure Virtual Private Network (VPN) connection from their on-premises datacenter to the Nutanix DRaaS service to replicate their workloads and setup communication between the two. A VPN solution also enables secure communication between your on-premises Prism® Central instance and the production Virtual Private Cloud (VPC) in the Nutanix DRaaS service.
This blog will cover the following:
How to enable workload communication between on-premises and your Nutanix DRaaS in the following scenarios:
- Nutanix managed VPN appliance on-premises to Nutanix VPN appliance on your Nutanix DRaaS.
- Third party VPN on-premises to Nutanix VPN appliance on your Nutanix DRaaS.
Nutanix VPN Appliance On-premises to Nutanix VPN Appliance on Nutanix DRaaS
When using the Nutanix managed VPN appliance on both sides of the connection, the deployment process automatically creates an ipsec tunnel with EBGP as the routing protocol running on top of it. These routes between both sides are advertised using EBGP.
By default, the Nutanix DRaaS advertises a load balancer subnet to the on-premises VPN. This is a /29 subnet which is a dedicated subnet for the Nutanix DRaaS target. To do this, login to the DRaaS Prism Central (PC) instance and go to “VPN” under Network & Security and click on “VPN Connection” to view the load balancer subnet information under the sent route section on the VPN connection page.
From on-premises to the Nutanix DRaaS Services network, we only redistribute the connected on-premises subnet. For example, if we deploy the VPN appliance in the same subnet as the Prism Central and Prism Element cluster, this subnet would be redistributed via EBGP from on-premises to the Nutanix DRaaS instance. Nutanix deploys Nutanix the VPN appliance in the same subnet as Prism Central and Prism Element clusters which should be segmented from other on-premises infrastructure. The communication between Prism Central and Prism Element clusters to the Xi load balancer subnet in the DRaaS is required for replicating the workload.
When running live workloads on Xi or failing over the VMs to the DRaaS (planned failover), communication between the on-prem and DRaaS infrastructure is also required between the workload subnets for your applications to work. For instance, if we run the live workloads or do a full subnet failover to Xi and the VMs on DRaaS are running on subnet 10.10.200.0/24 and our on-prem has VMs running on subnet 10.10.101.0/24, then the ideal traffic flow should follow the path as shown below.
- Traffic from the on-prem VM (10.10.101.10/24) should first go to its gateway which is either on the core switch or the firewall on the on-prem side.
- Add a static route on the router to redirect traffic to the on-prem VPN appliance. for destination subnet 10.10.200.0/24 with a next-hop of 10.10.100.10, the IP of on-prem VPN appliance. Note - In this case, if the same device hosts the gateway of both 10.10.101.0/24 and 10.10.100.0/24 subnet then it shouldn’t be a problem because 10.10.101.0/24 subnet would know how to route the traffic to the next hop 10.10.100.10. If the gateway of both the on-prem subnets are hosted on different devices then we would need to make sure to route the traffic to the on-prem VPN appliance by specifying the appropriate next hop in each router.
- Once the traffic reaches the on-prem VPN appliance, it will send the traffic to the Virtual Tunnel Interface (VTI) of the Xi side VPN.
- Xi side VPN will send the traffic to the upstream virtual router which hosts the gateway for the Xi side subnet 10.10.200.0/24.
- Traffic will now be sent to the VM on the Xi side, for example 10.10.200.10/24.
- For the reverse path, add a static route on the Xi side. This route is needed for Xi to route the traffic destined to on-prem subnets to the VPN connection. Add a static route on Xi. For destination subnet 10.10.101.0/24 with a next hop of the Xi side VPN connection (Refer to the next section on how to configure this static route).
- The Xi side VM will send the traffic to the virtual router which will then send it to the VPN appliance on the Xi side per the previously configured route.
- Xi side VPN will send the traffic to the VTI interface of the on-prem VPN appliance which has a default route to send all the traffic to its gateway 10.10.100.1/24
- Now the traffic will be routed to the 10.10.101.0/24 subnet’s gateway and from there to the on-prem VM.
Adding a static route from the Xi side
- Login to Xi PC and go to “Virtual Private Clouds” under Network & Security
- Click on Production
- Now, click on Routes as shown below
- Click on Create Static Routes
- Enter the on-premises workload subnet information.
- Select the VPN connection “vpn-connection” as the Next Hop Link.
- Click Save
Deploying Third-Party Firewalls n-prem to the Nutanix VPN Appliance on DRaaS Services
When using a tunnel between a third-party firewall on-prem and a Nutanix VPN appliance on DRaaS Services, the deployment creates an IPSec tunnel with either EBGP or static routing.
By default, DRaaS Services advertise a Xi load balancer subnet to the on-prem site which is a dedicated subnet in Xi DC used as a target network for workload replication. From on-prem, initially we only redistribute the subnet of Prism Element and Prism Central back to the Xi DC and open ports between the two sides to have end-to-end communication.
When running live workloads on Xi or failing over VMs to the DRaaS (planned failover), communication between the on-prem and DRaaS infrastructure is also required between the workload subnets for your applications to work. For instance, if we run the live workloads or do a full subnet failover to Xi and the VMs on DRaaS are running on subnet 10.10.200.0/24 and our on-prem has VMs running on subnet 10.10.101.0/24, then the ideal traffic flow should follow the path as shown below:
- Traffic from the on-prem VM (10.10.101.10/32) should first go to its gateway which is either on the physical network equipment on the onprem side.
- When running BGP over IPSec we can add our networks in the redistribution profile of the physical network equipment and advertise the on-prem network to Xi. You would also need to open the firewall rules to allow the communication between the on-prem and the Xi side subnets through IP policies or Zones, depending on how the firewall is configured. When using static routing over IPSec you would need to add a static route to the physical network equipment. For example, to reach the Xi side Destination subnet 10.10.200.0/24 the next hop is the 3rd party firewall VPN tunnel. In addition, you need to open the firewall rules between the two sides using IP policies or Zones. Note - In case of redistribution, make sure that your firewall has the information about your on-prem subnet and redistribute the routes appropriately i.e. static, ospf, connected etc depending on on-premises network configuration.
- Next the firewall/VPN will send the traffic to the VTI interface of the Xi side VPN
- Once received, the Xi side VPN will send the traffic to the upstream virtual router which hosts the gateway for the Xi side subnet 10.10.200.0/24
- Traffic will now be sent to the VM on the Xi side,10.10.200.10/32
- If we are using static routing over IPSec, then for the reverse path you need to add a static route on the Xi side. This route is needed for Xi to route the traffic destined to the on-prem subnet to theVPN connection. Add a static route on Xi which will be destination subnet 10.10.101.0/24 with a next hop of the VPN connection (Refer to the previous section on how to configure this static route in Xi). If instead we use EBGP over IPSec, then Xi will receive the subnet information via EBGP and in this case we would not need to add the static route from the Xi side.
- In the reverse direction, the Xi side VM will send the traffic to the virtual router which will then send it to the VPN appliance on the Xi side.
- The Xi side VPN will send the traffic to the VTI interface of the on-prem third-party firewalls.
- Now the traffic will be sent to the other subnet’s gateway and from there to the on-premises VM.
2021 Nutanix, Inc. All rights reserved. Nutanix, the Nutanix logo and all Nutanix product, feature and service names mentioned herein are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. Other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s). This post may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such a site. Certain information contained in this post may relate to or be based on studies, publications, surveys and other data obtained from third-party sources and our own internal estimates and research. While we believe these third-party studies, publications, surveys and other data are reliable as of the date of this post, they have not independently verified, and we make no representation as to the adequacy, fairness, accuracy, or completeness of any information obtained from third-party sources.
This post may contain express and implied forward-looking statements, which are not historical facts and are instead based on our current expectations, estimates and beliefs. The accuracy of such statements involves risks and uncertainties and depends upon future events, including those that may be beyond our control, and actual results may differ materially and adversely from those anticipated or implied by such statements. Any forward-looking statements included herein speak only as of the date hereof and, except as required by law, we assume no obligation to update or otherwise revise any of such forward-looking statements to reflect subsequent events or circumstances.