As I’m completing the new Veeam Cloud Connect Replication Reference Architecture, this question has come out multiple times from service providers and architects. So, I decided to publish in advance this small chapter from the upcoming book, to try and answer once and for all with my opinion on this topic.
When Veeam Cloud Connect v8 was first released, only Backup services were available. For this solution to work, Cloud Gateways could have been published either loading public IP’s directly in their network interfaces, or using NAT (Network Address Translation) technologies, where Cloud Gateways were using non public IP addresses, and an external component like a firewall would have published the TCP ports needed to expose Cloud Gateways to the public Internet.
This is still the case for Backup services in Veeam Cloud Connect v9, but in order to correctly publish Replica resources, we highly recommend to load on both Cloud Gateways and Network Extension Appliances public IP’s.
There are two main reasons to do so:
- Cloud Gateways and Network Extension Appliances need to be able to communicate during a partial failover. If one of the two is behind a NAT system, the real IP of the device is hidden by the NAT device itself; however, since DNS resolution is also in place, a service provider needs to build a complicated solution to “hack” DNS in order to correctly resolve Cloud Connect resources via their NAT-ed IP’s, instead of the real ones. Simply using public IP’s with no NAT makes this configuration much easier;
- Tenants can execute by themselves a full failover by accessing the Cloud Connect Portal. When at least one Public IP Address Mapping Rule is created, a service running in a virtual machine is published on the outside using one of the “public” IP’s assigned on the external interface of the NEA. Actually, any IP would be usable in this situation, like in this example:
The Public IP address 198.51.100.3 in reality is a special subnet dedicated to create documentation and examples, but it can be compared with an internal IP used in a DMZ network, like 192.168.0.3. None of these IP’s are reachable over internet. If a tenant attempts a failover using this configuration at the service provider, the service provider itself will need an additional NAT rule to publish the internal IP used in the NEA using a “real” public IP, like 185.62.37.102.
The problem is that the customer can be confused because the Cloud Connect Portal suggests the user to reach his virtual machine over the IP address loaded in the NEA:
This IP address (192.168.100.51) loaded in the NEA is not a public IP, and so the customer in reality cannot reach his virtual machine, unless the service provider advises the tenant to use the public IP that for example a firewall is using to publish the NEA on the internet.
This scenario is a major complication in both the network design and the level of automation that can be possibly reached. The NEA is a hardened Linux system, exposing to the outside just the ports that the customer/tenant has configured in his failover plan. No additional protection or routing is needed on the external interface of the NEA. If a service provider desires to have additional control, he can deploy an external firewall working at L2 (Layer2) and thus be totally transparent to the network configuration of a NEA.