- Veeam Support Knowledge Base
- SureBackup Ping Test Timed Out
SureBackup Ping Test Timed Out
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Oops! Something went wrong.
Please, try again later.
Challenge
Solution
Below is a list of the most commonly observed causes of Ping Test failures and solutions for each.
- A router exists between the Veeam Server and Virtual Lab.
- The vNIC for the Isolated Network is misconfigured.
- The firewall of the VM being tested is blocking inbound ICMP traffic.
- The VirtualLab Appliance has been moved to a different host.
- The Static Route for the Masquerade network was not created.
- VMXNET3 vNIC with Windows 7, Windows 2008 R2, or Windows 2012.
A Router exists between the Veeam Server and Virtual Lab
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.
vNIC for the Isolated Network is Misconfigured
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 expected 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.
The Firewall of the VM being tested is blocking inbound ICMP traffic
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:
- Open Windows Defender Firewall with Advanced Security ( wf.msc )
- Switch to the Inbound Rules section
- Enable the rule named File and Printer Sharing (Echo Request - ICMPv4-In)
Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled TrueThe VirtualLab Appliance has been moved to a different host
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 on a different host than shown, migrate it to the host indicated in the Veeam settings.
Example of matching locations:
Static Route for Masquerade network not created
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 demonstrates a route created by the SureBackup job to route traffic for the 11.0.0.0 masquerade network to the VirtualLab appliance IP of 10.75.1.105.
route.exe add <masquerade subnet> mask <mask> <appliance_production_IP>VMXNET3 vNIC with Windows 7, Windows 2008 R2, or Windows 2012
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.
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
Spelling error in text
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please, try again later.
You have selected too large block!
Please try select less.
KB Feedback/Suggestion
This form is only for KB Feedback/Suggestions, if you need help with the software open a support case
Thank you!
Your feedback has been received and will be reviewed.
Oops! Something went wrong.
Please, try again later.