4.4 vSphere Networking

Outside of the virtualized platform, there’s a complete range of additional resources that a service provider has to setup in order to guarantee Veeam Cloud Connect operates properly.

In particular, the network design is of extreme importance for Cloud Connect Replication.

NOTE: VLANs and NEA appliances are used in vSphere environments, while on Cloud Director environments Cloud Connect takes care of replication and registration of VMs while relying on VMware network technology for the networking part, being it regular networking or NAS. For this reason, there is no networking design related to Cloud Director in this book.

VLANs

Veeam Cloud Connect Replication on vSphere guarantees multi-tenancy at the network level using VLANs.

Each port group created for any service provider is tagged with a unique VLAN ID so communications between port groups, VLANs and networks are only possible by traversing a network extension appliance and thus are regulated. Veeam Backup & Replication, upon creating a new network for a tenant, automatically creates a new port group on the selected virtual switch and sets a VLAN tag. The available VLAN IDs need to be configured in advance both in Veeam Cloud Connect and the networking equipment:

4.11: Configure VLAN pool settings

In the example, the service provider has a vSphere cluster named SP-Cluster. There is a distributed virtual switch named DV-switch, and VLANs 1000 to 2999 have been already configured in the hardware switches on the uplinks registered in the distributed switch. No routing has been configured between the VLANs so this property will be exclusively managed by Veeam network extension appliances.

Two settings control the way NAT (Network Address Translation) is applied to VMs belonging to a given VLAN:

• “No Internet”/”With Internet” setting toggles Source NAT. VMs belonging to a VLAN “With Internet” can reach internet.
• “Public IP” setting enables Destination NAT. Both VMs belonging to “No Internet” and “With Internet” VLANs can be reached from internet if a Public IP publishing rule is created.

This two settings are independent from each other, so that service providers can satisfy different customers needs.

Public IPs

During a full failover, replicated VMs are powered on and they need to be reached from the outside so that a tenant can consume their services. All communications happening in a failover are managed by Veeam network extension appliances; in order to be reached from internet and to allow failed over VMs to reach the internet, an NEA acts like a firewall or gateway. To do so it needs to have a public IP loaded on its external interface. Just like VLAN pools, public IPs are not manually assigned to each tenant; instead, whenever an additional public IP is needed, Veeam Cloud Connect uses one of the available IPs that have been pre-loaded into the configuration:

4.12: Public IP pre-loaded in Veeam Cloud Connect

Service providers can consume public IPs coming from different pools, as long as the external interface of an NEA is connected to the right VLAN where this public IP can be used.

A NOTE ON IPv6: starting from v12, Veeam Backup and Replication and Cloud Connect supports IPv6 connectivity. Its usage is still very limited, so there will be no example on how to use it in this book. However, if you need to configure IPv6 on your Veeam Cloud Connect environment, there are some useful resource in the related section of the User Guide. Some points of attention:

• you need first to enable IPv6 Communication;
• in a Cloud Connect system that was updated to v12 from a previous version, if the existing Cloud Gateways are directy connected to the Internet IPv6 cannot be enabled. A clear error will pop up:

4.13: Cannot enable IPv6

IPv6 can only be used with Cloud Gateways configured in NAT-mode, that is “Located behind NAT” in the Networking options of its configuration.

*4.14: Cloud Gateways Networking options

Public IP’s or NAT-ed IP’s

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 IPs directly in their network interfaces or using NAT (network address translation) technologies, 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, but in order to correctly publish replica resources it is highly recommended to load public IPs on both cloud gateways and NEAs.

There are two main reasons to do so:

• Cloud gateways and NEAs need to be able to communicate during a partial failover. If one of the two is behind a NAT system, the NAT device itself hides the real IP of the device. However, because DNS resolution is also in place, a service provider needs to build a complicated solution to hack DNS in order to correctly resolve Veeam Cloud Connect resources via their NAT-ed IPs, instead of the real ones. Simply using public IPs with no NAT makes this configuration much easier.
• Tenants can execute a full failover by themselves by accessing the Veeam Cloud Connect Portal. When at least one public IP address mapping rule is created, a service running in a VM is published on the outside using one of the public IPs assigned on the external interface of the NEA, like in this example:

4.15: A public IP address mapping rule using a public IP address

The public IP address 203.0.113.151 is directly reachable from the Internet. But what happens if we use a Private/Non Routable address, like 192.168.0.3? 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 by using an additional IP that is publicly routable, like the 203.0.113.151 in the above example.

The problem is that the customer can be confused because the Failover Plan (executed from the Veeam Backup Console or from the Veeam Service Provider Console) invites the user to reach his virtual machine over the IP address loaded in the NEA.

This IP address 192.168.0.3 loaded in the NEA is not a public IP, and so the customer cannot reach it; the only solution is for the service provider to advise the tenant to use the public IP that is used to NAT the NEA behind it.

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 or 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 or use the firewall to also be the router of the NEA’s public IP.