In my previous post I explained step by step how a service provider can configure Veeam Cloud Connect Replication to allow for more than 9 internal networks. In this second part of the post, we’ll see how a tenant can replicate his virtual machines in this specific scenario, and how they can configure pfSense to allow the multiple communications between the replicated VMs and Internet.
Configure pfSense
The provider has configured the firewall for the tenant, and it has already connected it to the 12 different networks available into Veeam Cloud Connect. It’s now up to the tenant to create all the different rules that he needs to allow all the virtual machines to talk to each other and to the Internet. For this example we will create just a couple of rules, but remember that pfSense has a moltitude of options and features.
First, we configure the different OPT* networks with the proper static IPs, to be ready to act as gateway for the different VMs we are going to replicate. I’ve setup OPT1 with 10.2.113.254 and OPT2 with 10.2.114.254:
BE CAREFUL HERE: the configuration screen asks you for an IPv4 address and by default it suggests a /32 subnet, which is indeed what a single IP looks like. But since this IP needs to talk to its entire subnet, configure the subnet accordingly. It is /24 in my case.
Then, we create a rule to allow the two internal networks we want to use in this example to freely talk between each other and to the outside world:
Connect and consume Veeam Cloud Connect
In Veeam Backup and Replication, we register the new Cloud Connect provider, and we should be able to see the resources that are offered to us:
We can confirm that we have a grand total of 12 networks available, coming from two hardware plans, that are at the end combined together from a networking point of view thanks to the VLAN setup we did.
We then create a new Replication job, and in the first step we need to select network remapping:
We then select the two VMs we want to replicate:
and the most important part of the wizard, we properly configure the network mapping between source and destination:
Once the first replication job is completed, we can check immediately how the VMs have been stored in the provider’s vSphere environment. We can totally confirm that each VM is now connected to the correct VLAN, here’s VM-113 for example, linked to vlan-113 as planned:
Failover time!
Ok, now that everythins is (hopefully) configured properly, it’s time to test it! We first create a new Cloud Failover Plan in the tenant’s VBR console:
In the remaining part of the wizard, we can see that default gateways and public ip addresses are still available as options, but this doesn’t really matter as we are using the pfSense appliance and not the integrated Veeam Network Extention Appliance. But it’s still good to verify that we have connected the VMs to the correct network:
Let’s start the failover plan:
We connect to vm-113 and we test its connectivity:
As you can see, we can ping the VLAN gateway of the same subnet where vm-113 is connected, which in reality is not connected to the same port group, but it’s the virtual interface of pfSense that is configured to reply to VLANid 113. Also, we can reach the other virtual machine vm-114. The pfSense machine is working as a router between the different VLANs of the trunk.