2.9 Network Extension Appliances

To enable communication between production VMs on the tenant’s side and VM replicas at the service provider, Veeam Backup & Replication uses network extension appliances. A network extension appliance (NEA) is a tiny, hardened, Linux-based VM (1 VCPU, 512 MB RAM, 44 MB ISO file + virtual floppy disk for configuration) deployed automatically by Veeam Backup & Replication server on the virtualization hosts on which tenant VMs and their replicas reside. NEA is a mandatory component for vSphere and Hyper-V replication, while vCloud Director replication can choose to still use NEA, or leverage native VMware NSX capabilities.

NEA have two main purposes:

• During full failover, it provides both access to internet for replica VMs and access to replica VMs from the internet
• During partial failover, it extends customer network to the service provider environment, using L2 (Layer 2) over L3 (Layer 3) technologies, so that production VMs can communicate with replica VMs.

For every tenant who plans to replicate VMs to the service provider and use the built-in networking and failover capabilities described above, at least two NEAs should be deployed: one on the service provider’s side and the other on the tenant’s side.

2.29: General overview of network extension appliances

The network extension appliance on the service provider side is deployed on the virtualization platform that acts as a replication target. The NEA has at least two network interfaces:

• The external interface is connected to the service provider external network, in a network that can be reached also by the cloud gateways with proper routing, and without NAT. This network uses public IPs assigned to each NEA so that the appliance itself can act as a firewall or gateway for every replica VM
• One or more internal interfaces are created once a hardware plan is assigned to a new tenant. In vSphere environments, Veeam Cloud Connect uses VLANs as a way to isolate network resources assigned to every tenant. Each network of each tenant is created automatically by Cloud Connect in the virtualized platform as a new port group, tagged with a unique VLAN ID (taken from a VLAN pool preloaded during the Veeam Cloud Connect initial configuration). VLANs are not routed between each other at the physical switching layer. The only way a VLAN segment can communicate with another one is by the NEA, which guarantees the complete isolation of tenants.

2.30: VLANs are used to create network isolation and multi-tenancy

Full failover

During a full failover, the internal interfaces of a network extension appliance are configured with the same IP addresses that the original gateways use for their virtual machines at the tenant site, one per network / port group. This way, no change to replicated VM IP configuration is needed during the failover and the NEA can act as the new default gateway.

The tenant allows access to replica VMs during the configuration of a cloud failover plan:

2.31: Setting public IP destination rules in a cloud failover plan

Each rule created in the public IP step of the wizard becomes a new ingress rule on the NEA, from the public IP address to the private IP of the selected VM. Chapter 5 will provide additional information about this topic.

Partial Failover

During partial failover, only individual replica VMs are selected by a tenant to be powered on at the service provider, and those VMs will be able to connect to their original network at the tenant side, thanks to the network extension appliance.

In this scenario, there are two appliances involved in the process:

• The network appliance deployed at the tenant has one network interface, connected to the same port group as the virtual machines (multiple appliances are deployed when the end user has multiple port groups with VMs). This appliance starts the OpenVPN client and connects to the cloud gateway, and from here to the network appliance deployed at the service provider side
• The network appliance at the service provider side receives the connections from the OpenVPN client thanks to an OpenVPN server running inside it. The result is the creation of a L2 tunnel between the two sites, encapsulated in the Layer 3 tunnel created by the cloud gateways.

On top of the L2 tunnel, a Proxy ARP solution running inside both network appliances forwards L2 datagrams from one side to the other, and vice versa. The result is that VMs can use the same subnet or broadcast domain, regardless of the site where they are powered on.

Firewall

Because of the different networking configurations that a network extension appliance can have, a general firewall configuration for the appliance itself is not possible. There is one TCP port that is always open on the external interface:

Service	Port
SSHD	22

In addition, every rule created by a tenant in a cloud failover plan becomes a new firewall port open in the network appliance.

The only difference is that while SSHD needs to be reached only from Veeam Backup & Replication server in order to control and reconfigure the network appliance, every other rule is meant to have no defined source IP address, as end user may need to connect from different locations to their replica VMs.

NOTE: Because the network extension appliance is already a firewall and opens only the minimum amount of ports required by an end user, there is little sense in putting an additional firewall in front of it. Service providers can filter and monitor incoming connections, if needed, using firewalls operating at L2 (or in transparent mode) or by configuring their firewall as the gateways of the public IPs used by the network appliances. This allows to use the real public IP of an appliance instead of complicated multiple NAT levels.

Monitoring

There is no need to monitor a network extension appliance because it is powered on on-demand by the Veeam Backup & Replication server at the service provider when needed in reaction to end user activities like the start of a partial or a full failover.

Protection

From a protection standpoint, a network extension appliance does not need to be saved because there is no permanent data on it. A significant part of configuration (the content of the floppy image) is created during appliance deployment; the managing VBR server passes additional configuration upon boot. In both cases, data is stored in the Veeam Backup & Replication server and reconfigured upon a redeployment of the NEA.