Challenge
When executing a SureBackup job with the ping test enabled the test fails.Cause
This KB contains multiple causes with their appropriate troubleshooting steps listed below in the Solution section.Solution
PRODUCTION NETWORK CONNECTION UNDER PROXY IS MISCONFIGURED
Virtual Lab is on a different subnet than the Veeam server. To test use the command line tool ‘tracert’ with the Virtual Lab IP while the Virtual Lab appliance is powered on. The result should be 1 hop, as shown in Fig 1.1. If it is more than 1 hop, correct the settings on the Proxy tab of the Virtual Appliance configuration. You may need to change the “Production network” or manually specify IP address for the proxy in the configuration (Fig 1.2).
Fig 1.1
Fig 1.2
NOTE: If the virtual lab is being configured on another site from the Veeam server, traffic will have to cross routers in between. In this situation the number of hops will be more than 1. The routers between the sites must be configured to have routing for the masquerade address to the virtual lab appliances production side adapter.
VNIC FOR ISOLATED NETWORK MISCONFIGURED
The isolated NIC within the Virtual Lab configuration is not configured to have the IP of the Gateway which the VMs within the isolated environment are set to contact. Check the settings for the Virtual NIC settings on the Network Settings tab. If this tab does not appear in the Virtual Lab settings, change the radio option on the Networking tab to “Advanced single-host”.
FIREWALL WITHIN GUEST OS OF VM IN ISOLATED NETWORK IS BLOCKING ICMP
This can either happen because the VM blocks ICMP normally or because it’s within the isolated environment and the firewall has changed to the Public profile due to it not being able to communicate with a Domain Controller in the isolated network.
You can test this by performing the following:
- Run the following command from the Veeam server. * masquerade address
ping <masquerade address> -t
- Connect via the console to the VM in the lab and run:
netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol=icmpv4:8,any dir=in action=allow
If the ping starts to work, run the same command on the production server. On the next backup of the Production VM, the change will be in that restore point.
NOTE: Even if firewall rule is set to disabled, Public profile mode in 'Network and Sharing Center' will block the ping.
THE VIRTUAL LAB IS NOT ON THE HOST THAT IT WAS ORIGINALLY CONFIGURED TO BE ON
Check the under the Backup Infrastructure>Virtual Labs section to see what 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 settings.
VMXNET3 WITH WINDOWS 7 OR WINDOWS 2008R2
The Virtual Machine being brought up within the Virtual Lab environment defaults to DHCP and is not contacting the gateway as configured within the Virtual Lab setting. This occurs due to a known issue with VMware VMXNET3 Network Adapaters and Windows 7/Windows 2008 R2 operating system. The hotfix documented in the following VMware KB must be applied to the Production server. This server must then be rebooted and backed up again.
http://kb.vmware.com/kb/1020078
STATIC ROUTE NOT BEING CREATED
The static route is not being added when the SureBackup job starts. After the Surebackup Job has been started, run the command 'route print' and look for the IPv4 route for the masquerade subnet to the Virtual Lab appliance. If it's not present, try manually running the route with the following command:
route.exe add <masquerade subnet> mask <mask> <appliance_address_externaly>
A reboot of the Veeam server may be necessary if the static route will not stay.