Problem with Virtual Labs connectivity

[Titanmike]

First let me explain the setup itself.

Each vSphere host and the Veeam server have multiple VLANs configured and virtual machines might be part of multiple VLANs, but at least two at a time.

In this example I created a Virtual Lab with the following settings:

1. Choose Host - done

2. Choose Datastore - done

3. Proxy
Under production network I assign an IP address which is not yet assigned on the network.

4. Advanced Configuration
I add the second VLAN in question (virtual machine has VLAN22 and 999)
Production network was set to VLAN22, so I add 999 to the network mapping as well

5. Network settings
I change the default VLAN22 vNic to reflect the actual network range without DHCP enabled
I added a second VLAN (999) which also reflect the actual network range without DHCP enabled

I choose not to route traffic between vNics

6. Static Mapping
None have been defined

The creation of the virtual lab finishes successfully.

Now the big bang.

I have created a verification SureBackup job and attached it to a backup task.

The first thing I noticed when running the job is that the Veeam server lost connectivity to the network. As a result it lost all its connectivity to the vSphere infrastructure, causing the job to fail at some point. But since it is then unable to receive any status updates from the proxy appliance it ends up being in an odd stage where the Veeam server fails to notice that the task failed. Basically I had to remove the lab manually etc.

I then checked why it failed all connectivity and I noticed that as soon as the verification task starts, it creates a static route on the veeam server, pointing all traffic to the proxy appliance.

Is this a behaviour caused by a certain settings or / and how can this be avoided ?!?

[Alexey D.]

Hello,

Please copy-paste here your virtual lab's settings so we can take a look and help you.
Settings can be taken from "Ready to Apply" step of the wizard from the box under "Virtual lab will be created with the following parameters".

[Titanmike]

Lab name: Veeam_Lab_VLAN999_and_VLAN22
ESX name: dev-vsphere-1.titaninternet.co.uk
Datastore: Dev-Storage-Vol-03

Appliance:
Name: Veeam_Lab_VLAN999_and_VLAN22
Pool name: Veeam_Lab_VLAN999_and_VLAN22
Folder name: Veeam_Lab_VLAN999_and_VLAN22

Production network name:VLAN22
IP: 192.168.40.135
Subnet mask: 255.255.240.0
Default gateway: ...

DNS:
Preferred: 192.168.40.11
Alternate: 192.168.40.10

Network configuration type: Advanced
Network options:
Isolated network: Veeam_Lab_VLAN999_and_VLAN22 VLAN22
Masquerade IP: 192.168.32.0
Appliance IP: 192.168.40.136
DHCP: disabled

Isolated network: Veeam_Lab_VLAN999_and_VLAN22 VLAN999
Masquerade IP: 85.232.60.0
Appliance IP: 85.232.60.184
DHCP: disabled


Network mapping:
VLAN22 --> Veeam_Lab_VLAN999_and_VLAN22 VLAN22
VLAN999 --> Veeam_Lab_VLAN999_and_VLAN22 VLAN999

[Alexey D.]

Ok, please also tell subnet masks for both of your isolated networks.

[Titanmike]

192.168.32.0 /20
85.232.60.0 /23

[Alexey D.]

Ok! Let me explain what happened. The general rule is that masquerade IP must not point to production network. It has to be an unused and unique IP.

For example, in your case, assuming that production network is 192.168.32.0/20, masquerade may be 192.168.48.0/20. Thus, let's say, if you have production VM with 192.168.32.99 IP, its corresponding masquerade would be 192.168.48.99. This proper masquerade address allows to go to VM running from backup in isolated virtual lab. From the other hand, production VM is also accessible by its "original" IP.

With your settings, you got the effect of "snake eating its tale". So please change masquerade IPs for both of your isolated networks, according to the situation I explained. Hope this helps!

[Titanmike]

Would I have to use static mapping as well ?

[Vitaliy S.]

Static Mapping is essential if you want other VMs to have an access to the VMs in a Virtual Lab. In other words, if you do not configure static mapping, the VM in the Virtual Lab will only be accessible from a backup console.