0 Flares Twitter 0 Facebook 0 LinkedIn 0 Email -- 0 Flares ×

Last week, during the VeeamON 2017 conference, one of the announcements has been a completely new product, called VeeamPN (Veeam Powered Network), a solution to easily create virtual private networks between multiple public clouds, remote locations and roaming users. Even if the main use case of the solution is to ease the access to Azure virtual machines, I’ve found another interesting use case that I’m sure the service providers running Veeam Cloud Connect will like.

Some basics

My colleague Anthony Spiteri has blogged about this new announcement on his blog, and you can read here the article, where many information and details are shared. The architecture uses one central appliance, called the Hub Server, to receive and manage all the connections from the other remote locations:

The site Gateways (or the individual remote clients) are installed in the remote locations, and they all connect over public internet to the Hub Server. Upon connection, a private network is created between the two locations, so that each machine can talk to each other like it would be in the same network.

The Cloud Connect scenario

In Veeam Cloud Connect, tenants can publish their servers through the “Public IP addressing rules” of a Failover Plan. When the failover plan is triggered, either by the service provider or by the tenant via the Cloud Connect Portal, the rules previously created by the tenant are applied in real time to the NEA (Network Extension Appliance), that acts like a router/firewall for all the virtual machines.

This scenario is perfect for customers willing to reach their services over public internet, like a web server or a mail servers, but there are cases where the customers doesn’t want to expose a server to internet, and so different solutions are needed. So far, technologies like Remote Desktop servers or similar have been suggested, but this solution has not been accepted by everyone. Now, with VeeamPN, there’s a different way to offer remote access to Cloud Connect users.

First, let’s describe the scenario. Out customer has three different servers that wants to replicate towards VCC-R:

Once all the virtual machines have at least one restore point correctly stored into VCC-R, the customer creates a failover plan with all the three VMs. When it comes to the Public IP addressing rules, the customer only wants to publish over internet these ports:

tcp/80 from the LAMP machine

tcp/3389 from test-2012 machine

while everything else should not be reachable via internet. Without VeeamPN, the customer would have had to use for example the RDP connection towards test-2012 has a “jump host” to then reach the SQL machine. With VeeamPN instead, there’s no need to publish services over public internet, if this is not what the customer wants.

Deploy VeeamPN inside a VCC-R Hardware Plan

There are two different use cases here:

– tenant deploys VeeamPN: the tenant deploys VeeamPN inside his network, and then replicates it together with the other virtual machines. During a failover, also the appliance is powered on and can then be accessed. The advantages here is that the tenant is totally independent in doing this operations, and can configure in advance the appliance. The disadvantage is that an additional VCC license is consumed to replicate this machine.

– provider deploys VeeamPN: provider deploys and configures the appliance in advance, sends the configuration parameters to the tenants, and asks to the tenant to create the needed firewall rules in the failover plan. The advantage is that the appliances doesn’t consume a VCC license since it’s not replicated. The disadvantages are that the appliance is always powered on, so it consumes resources and hypervisors licenses in the service provider, and the provider has to do a series of operations to setup the appliance for the customer.

In my demo, I’m going to describe the first scenario, since I prefer to keep as much as possible the idea of self-service that Cloud Connect has. Just remember that both scenarios are possible.

First thing first, we need to install and configure VeeamPN at the customer site. Veeam just published a new KB2271 with detailed instructions for deploying VeeamPN on premises. Once we have retrieved the OVA, we start the installation on the customer network. If the network has no DHCP available, you can login into the VM console and change the IP address like in any Ubuntu Linux: use vi /etc/network/interfaces and add these lines, adapting the values to the customer’s own network:

iface ens160 inet static

address 10.2.50.105

netmask 255.255.255.0

gateway 10.2.50.254

dns-nameservers 8.8.8.8

Once you log into the web portal, follow the wizard and complete the configuration of the hub. After retrieving the Public IP assigned to the tenant from the information available in the Veeam Cloud Connect failover plan, we configure in advance the Hub to accept both site-to-site and point-to-site VPNs. I choose TCP, even if slower, because the NEA available in VCC-R allows for now only TCP rules:

Now, we also prepare in advance the connection for our computer. Into the Client section, we hit the Add button and we select standalone computer. VeeamPN is based over OpenVPN, and as such we can use the OpenVPN client for the operating system we have, plus the configuration file created by VeeamPN.

Finally, you need to create a new Client, this time using type “entire site”. Again, go into the Client section, hit Add and select this time Entire Site. Give it a name, and most of all enter here the subnet that’s used in the VCC-R tenant. In my case it will be 10.2.50.0/24.

This allows VeeamPN to push a dedicated entry in our computer’s routing table, so that upon connecting to the OpenVPN server, the client will have the entries to reach the failed over machines.

We can now replicate the VeeamPN appliance towards our tenant in VCC-R, so that we have this situation at the end:

Good, the appliance is replicated in our Hardware Plan. Time to add it to the failover process.

Enable VeeamPN during a failover

Once the appliance is replicated, we move into the cloud failover plan. First, we add the machine to the list of VMs that need to be powered on during the failover:

There’s no need to have the VeeamPN appliance to be started before every other VMs, unless we really want to access all the failed over resources as soon as they are up and running at the DR site. The most important part of the configuration is however the “Public IP Addresses” step of the wizard. Here we configure the publishing rules like this:

In the new rules, I’ve added the two needed ports to publish VeeamPN over ports 1194 (site-to-site) and 6179 (point-to-site), plus the web interface, in case I need to edit some configurations on the fly once the failover is started. Note that there is no rule to publish over internet the SQL Server; this is done on purpose, as customers may not want to expose some sensitive applications, like a database or a file share. This is the perfect use case for VeeamPN!

Now, it’s time to start the failover. From the Cloud Connect Failover Portal I start the failover plan, and I wait for all the virtual machines to be correctly started and published. I can immediately check that, for example, the VeeamPN web interface is correctly exposed:

Then, I test obviously the most important part, the access to the VPN itself. I installed the OpenVPN client in my computer, and added the configuration file that I previously created:

After a few seconds, the connection is completed successfully:

I see in the OpenVPN client that a new route has been added:

Wed May 24 00:18:17 2017 us=880028 C:\WINDOWS\system32\route.exe ADD 10.2.50.0 MASK 255.255.255.0 10.9.0.1 Wed May 24 00:18:17 2017 us=885042 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=35 and dwForwardType=4 Wed May 24 00:18:17 2017 us=885042 Route addition via IPAPI succeeded [adaptive] 1 2 3 Wed May 24 00 : 18 : 17 2017 us = 880028 C : \ WINDOWS \ system32 \ route . exe ADD 10 . 2 . 50 . 0 MASK 255 . 255 . 255 . 0 10 . 9 . 0 . 1 Wed May 24 00 : 18 : 17 2017 us = 885042 ROUTE : CreateIpForwardEntry succeeded with dwForwardMetric1 = 35 and dwForwardType = 4 Wed May 24 00 : 18 : 17 2017 us = 885042 Route addition via IPAPI succeeded [ adaptive ]

Now, I can ping successfully the SQL Server (remember, it’s not reachable from internet):

and open its shares:

With this solution, both end users and service providers can easily offer connection services to their infrastructures, like remote access to Veeam Cloud Connect Replication.