Veeam PN was launched as part of Veeam Recovery to Microsoft Azure, but Veeam PN has some great standalone use cases. In this blog post, I’ll be covering a very real-world solution with Veeam PN where it will be used to easily connect geographically disparate cloud hosting zones, enabling you to achieve High Availability for applications and provide cross cloud application and services access.
Taking this use case one step further, how can cloud-to-cloud Availability be achieved in the most cost effective and operationally efficient way? There are obviously a few ways to connect clouds, and many other solutions out there, whether that be via some sort of MPLS, IPSec, L2VPN or stretched network solution. What Veeam PN achieves is simplicity — it’s very easy to configure, and it’s also very cost effective (remember it’s FREE). This makes it one of the best ways to connect one to one or one to many cloud zones with little to no overhead.
Cloud-to-cloud-to-cloud Veeam PN appliance deployment model
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/399972/4F0D2125-0F83-4619-A885-97375F8112AA_xm9vgf.png)
In this scenario, I want each vCloud Director zone to have access to the other zones and be always connected. I also want to be able to connect in via the OpenVPN endpoint client and have access to all zones remotely. All zones will be routed through the Veeam PN Hub Server deployed into Azure via the Azure Marketplace.
Components
- Veeam PN Hub Appliance x 1 (Azure)
- Veeam PN Site Gateway x 3 (One Per Zettagrid vCD Zone)
- OpenVPN Client (For remote connectivity)
Networking overview and requirements
- Veeam PN Hub Appliance – Incoming Ports TCP/UDP 1194, 6179 and TCP 443
- Azure VNET 10.0.0.0/16
- Azure Veeam PN Endpoint IP and DNS Record
- Veeam PN Site Gateways – Outgoing access to at least TCP/UDP 1194
- Perth vCD Zone 192.168.60.0/24
- Sydney vCD Zone 192.168.70.0/24
- Melbourne vCD Zone 192.168.80.0/24
- OpenVPN Client – Outgoing access to at least TCP/UDP 6179
In my setup, the Veeam PN Hub Appliance has been deployed into Microsoft Azure mainly because that’s where I was able to test out Veeam PN initially, but also because in theory it provides a centralized, highly available location for all the site-to-site connections to terminate into. This central hub can be deployed anywhere, and as long as it’s got HTTPS connectivity configured correctly to access the web interface, you can start to configure your site and standalone clients.
Configuring site clients for cloud zones (site-to-site)
In order to configure the Veeam PN Site Gateway you’ll need to register the sites from the Veeam PN Hub Appliance. When you register a client, Veeam PN generates a configuration file that contains VPN connection settings for the client. You must use the configuration file (downloadable as an XML) to set up the Site Gateways. Referencing the diagram at the beginning of the post, I needed to register three separate client configurations as shown below.
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/399972/C9ABFBD3-DB01-4101-85B3-75ED7727E6A0_sjfzwy.png)
Once this has been completed, you need to deploy a Veeam PN Site Gateway in each vCloud Hosting Zone, and because we are dealing with an OVA, the OVFTool will need to be used to upload the Veeam PN Site Gateway appliances. I’ve previously created and blogged about an OVFTool upload script using PowerShell. Each Site Gateway needs to be deployed and attached to the vCloud vORG Network that you want to extend, in my case it’s the 192.168.60.0, 192.168.70.0 and 192.168.80.0 vORG Networks.
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/399972/89D40638-47BE-4A0B-9531-22C123B66150_yohwk7.png)
Once each vCloud zone has the Site Gateway deployed and the corresponding XML configuration file added, you should see all sites connected in the Veeam PN Dashboard.
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/399972/74897640-936E-4FB6-98FB-0C920D12E761_wjmeyw.png)
At this stage, we have connected each vCloud Zone to the central Hub Appliance which is configured now to route to each subnet. If I was to connect an OpenVPN Client to the Hub Appliance, I could access all subnets and be able to connect to systems or services in each location. Shown below is the Tunnelblick OpenVPN Client connected to the Hub Appliance showing the injected routes into the network settings.
![broken image](http://custom-images.strikinglycdn.com/res/hrscywv4p/image/upload/c_limit,fl_lossy,h_9000,w_1200,f_auto,q_auto/399972/750A8663-C8A6-46E9-A849-C416CC27E0D2_zs4jmh.png)
You can see above that the 192.168.60.0, 192.168.70.0 and 192.168.80.0 static routes have been added and set to use the tunnel interfaces default gateway which is on the central Hub Appliance.
Adding static routes to cloud zones (cloud to cloud to cloud)
To complete the setup and have each vCloud zone talking to each other, we need to configure static routes on each zone network gateway/router so that traffic destined for the other subnets knows to be routed through to the Site Gateway IP, through to the central Hub Appliance onto the destination and then back. To achieve this, you just need to add static routes to the router. In my example, I have added the static route to the vCloud Edge Gateway through the vCD Portal as shown below in the Melbourne Zone.
Conclusion
To summarize, below are the 5 steps that were taken to setup and configure the configuration of a cloud-to-cloud-to-cloud network using Veeam PN and its site-to-site connectivity feature. By doing so, allowing cross-site connectivity while enabling access to systems and services via the point-to-site VPN:
- Deploy and configure Veeam PN Hub Appliance
- Register cloud sites
- Register endpoints
- Deploy and configure Veeam PN Site Gateway in each vCloud zone
- Configure static routes in each vCloud zone
These five steps took me less than 30 minutes, which also took into consideration the OVA deployments as well. At the end of the day, I’ve connected three disparate cloud zones which all access each other through a Veeam PN Hub Appliance deployed in Microsoft Azure. From here, there is nothing stopping me from adding more cloud zones that could be situated in any public cloud, whether AWS, IBM or Google. I could even connect my home office or a remote site to the central Hub to give full coverage.
The key here is that Veeam Powered Network offers a very simple solution to what is traditionally a complex and costly one. Again, this will not suit all use cases, but at its most basic functional level, it’s a great solution for customers who have a need for cross-cloud connectivity.
Go give it a try! Get started with Veeam PN.
I work for Veeam as Systems Engineer, this blog article credit goes to Veeam. If you have any questions, feel to reach out or check us out at Veeam