Veeam PN is a very cool product that has been GA for about four months now. Initially we combined the free product together with Veeam Direct Restore to Microsoft Azure to create Veeam Recovery to Microsoft Azure. Of late there has been a push to get Veeam PN out in the community as a standalone product that’s capable of simplifying the orchestration of site-to-site and point-to-site VPNs.

I’ve written a few posts on some of the use cases of Veeam PN as a standalone product. This post will focus on getting Veeam PN installed into an AWS VPC to be used as the VPN gateway. Given that AWS has VPN solutions built in, why would you look to use Veeam PN? The answer to that is one of the core reasons why I believe Veeam PN is a solid networking tool…The simplicity of the setup and ease of use for those looking to connect or extend on-premises or cloud networks quickly and efficiently.

Overview of Use Case and Solution:

My main user case for my wanting to extend the AWS VPC network into an existing Veeam PN Hub connected to my my Homelab and Veeam Product Strategy Lab was to test out using an EC2 instance as a remote Veeam Linux Repository. Having a look at the diagram below you can see the basics of the design with the blue dotted line representing the traffic flow.

 

The traffic flows between the Linux Repository EC2 instance and the Veeam Backup & Replication server in my Homelab through the Veeam PN EC2 instance. That is via the Veeam PN Hub that lives in Azure and the Veeam PN Site Gateway in the Homelab.

The configuration for this includes the following:

  • A virtual private cloud with a public subnet with a size /24 IPv4 CIDR (10.0.100.0/24). The public subnet is associated with the main route table that routes to the Internet gateway.
  • An Internet gateway that connects the VPC to the Internet and to other AWS products.
  • The VPN connection between the VPC network and the Homelab network. The VPN connection consists of a Veeam PN Site Gateway located in the AWS VPC and a the Veeam PN HUB and Site Gateway located at the Homelab side of the VPN connection.
  • Instances in the External subnet with Elastic IP addresses that enable them to be reached from the Internet for management.
  • The main route table associated with the public subnet. The route table contains an entry that enables instances in the subnet to communicate with other instances in the VPC, and two entries that enables instances in the subnet to communicate with the remote subnets (172.17.0.0/24 and 10.0.30.0/24).

AWS has a lot of knobs that need adjusting even for what would normally be assumed functionality. With that I had to work out which knobs to turn to make things work as expected and get the traffic flowing between sites.

Veeam PN Site Gateway Configuration:

To get a Veeam PN instance working within AWS you need to deploy an Ubuntu 16.04 LTS form the Instance Wizard or Marketplace into the VPC (see below for specific configuration items). In this scenario a t2.small instance works well with a 16GB SSD hard drive as provided by the instance wizard. To install the Veeam PN services onto the EC2 instance, follow my previous blog post on Installing Veeam Powered Network Direct from a Linux Repo.

Once deployed along with the EC2 instance that I am using as a Veeam Linux Repository I have two EC2 instances in the AWS Console that are part of the VPC.

From here you can configure the Veeam PN instance as a Site Gateway. This can be done via the exposed HTTP/S Web Console of the deployed VM. First you need to create a new Entire Site Client from the HUB Veeam PN Web Console with the network address of the VPC as shown below.

Once the configuration file is imported into the AWS Veeam PN instance it should connect up automatically.

Jumping on the Veeam PN instance to view the routing table, you can see what networks the Veeam HUB has connected to.

The last two entries there are referenced in the design diagram and are the subnets that have the static routes configured in the VPC. You can see the path the traffic takes, which is reflected in the diagram as well.

Looking at the same info from the Linux Repository instance you can see standard routing for a locally connected server without any specific routes to the 172.17.0.0/24 or 10.0.30.0/24 subnets.

Notice though with the traffic path to get to the 172.17.0.0/24 subnet it’s now going through an extra hop which is the Veeam PN instance.

Amazon VPC Configuration:

For the most part this was a straightforward VPC creation with a IPv4 CIDR block of 10.0.100.0/24 configured. However, to make the routing work and the traffic flowing as desired you need to tweak some settings. After initial deployment of the Veeam PN EC2 instance I had some issues resolving both forward and reverse DNS entries which meant I couldn’t update the servers or install anything off the Veeam Linux software repositories.

By default there are a couple of VPC options that is turned off for some reason which makes all that work.Enable both DNS Resolution and DNS Hostnames via the menu options highlighted above.

For the Network ACLs the default Allows ALL/ALL for inbound and outbound can be left as is. In terms of Security Groups, I created a new one and added both the Veeam PN and Linux Repository instances into the group. Inbound we are catering for SSH access to connect to and configure the instances externally and as shown below there are also rules in there to allow HTTP and HTTPS traffic to access the Veeam PN Web Console.

These, along with the Network ACLs are pretty open rules so feel free to get more granular if you like.

From the Route Table menu, I added the static routes for the remote subnets so that anything on the 10.0.100.0/24 network trying to get to 172.17.0.0/24 or 10.0.30.0/24 will use the Veeam PN EC2 instance as it’s next hop target.

EC2 Configuration Gotchya:

A big shout out to James Kilby who helped me diagnose an initial static routing issue by discovering that you need to adjust the Source/Destination Check attribute which controls whether source/destination checking is enabled on the instance. This can be done either against the EC2 instance right click menu, or on the Network Interfaces menu as shown below.

Disabling this attribute enables an instance to handle network traffic that isn’t specifically destined for the instance. For example, instances running services such as network address translation, routing, or a firewall should set this value to disabled. The default value is enabled.

Conclusion:

The end result of all that was the ability to configure my Veeam Backup & Replication server in my Homeland to add the EC2 Veeam Linux instance as a repository which allowed me to backup to AWS from home through the Veeam PN network site-to-site connectivity.

Bear in mind this is a POC, however the ability to consider Veeam PN as another options for extending AWS VPCs to other networks in a quick and easy fashion should make you think of the possabilities. Once the VPC/EC2 knobs where turned and the correct settings put in place, the end to end deployment, setup and connecting into the extended Veeam PN HUB network took no more than 10 minutes.

That is the true power of the Veeam Powered Network!

References:

https://docs.aws.amazon.com/glue/latest/dg/set-up-vpc-dns.html

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html#change_source_dest_check