|Product:||Veeam Backup & Replication|
When setting up the Proxy Appliance, you should assign it to a Production network directly accessible by the Veeam server and ensure that the appliance has an IP address in the same network as the Veeam server. When SureBackup testing is performed, VMs are accessible by the Veeam server using IP Masquerading. If there is a router between the Veeam server and the Virtual Lab appliance, packets sent to the masquerade IPs will be dropped by the intermediate router, causing the ping test and other tests to fail.
To test this, manually power on the Virtual Lab appliance and use 'tracert' on the Veeam server to determine how many hops are between the Veeam Server and VirtualLab appliance.
For example, if the Virtual Lab was assigned the production IP of 10.75.1.105, the results below demonstrate that it is only 1 hop away.
The IP address assigned to the isolated vNIC must match the gateway IP that the VMs being powered on in the isolated network will be expecteding to contact.
In the example below, the default gateway of a VM to be tested is 10.0.8.1, the vNIC IP address for the Isolated network must match.
When a VM that is part of a domain is tested using SureBackup without an Application Group containing a Domain Controller, its firewall will switch to the Public profile. The default Public firewall Profile setting is to block ICMP inbound traffic.
To resolve this, configure an Application Group containing a Domain Controller with the "Domain Controller (Authoritative Restore)" role assigned. Then configure the SureBackup job to use that Application Group.
Alternatively, if the machine being tested was not part of a domain or a Domain Controller cannot be added to an Application Group for the SureBackup job to use, the Windows Defender Firewall will need to be altered on the machine to allow inbound Echo Requests. After the firewall rule is enabled, the VM must be backed up again and then tested with SureBackup.
Enable "File and Printer Sharing (Echo Request - ICMPv4-In)" rule:
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True
In very rare situations the VirtualLab appliance may have moved to a different host than it was initially configured to be on. Check the under the Backup Infrastructure>Virtual Labs to see which host the Virtual Lab is configured to be on. If the Virtual Lab VM is found to be on a different host than shown, migrate it to the host shown in the Veeam settings.
Example of matching locations:
VMs being tested with SureBackup having the above Windows OSs may have their network adapters duplicated due to a known issue with VMXNET3. These duplicated network adapters have default settings and often appear as having an APIPA Address.
At the start of a SureBackup job, a static route is added to the Veeam server so that network traffic can reach the isolated VMs being tested. Under some rare circumstances, this route fails to be created, often due to security software on the Veeam server. To determine if the route is being created, start a SureBackup job. After the job completes the "Starting virtual lab routing engine" step, run the 'route print' command in an Administrative Command Prompt. Review the output to determine whether a static route has been created to route traffic sent to the Masquerade network to VirtualAppliance IP.
The example below demonstrate a route that was created by the SureBackup job to route traffic for the 220.127.116.11 masquerade network, to the VirtualLab appliance IP of 10.75.1.105.
route.exe add <masquerade subnet> mask <mask> <appliance_production_IP>