Surebackup Ping Test Fails

[davidstepup]

I'm setting up a SureBackup job for my primary domain controller. I'm having an issue where the ping test fails for the job, but I can ping the masquerade IP address of both the gateway for the virtual lab and the masquerade IP address of the virtual machine while it's in the process of booting. After a period of time the pings to the virtual machine stop responding, but the gateway still responds.

I have the networking for the virtual lab configured as "advanced single-host" and my vNIC has DHCP enabled.

When I manually test the Surebackup job's VM, I can get it to respond to pings after I use the vSphere console to get into the VM and login to it. I've extended the timeout for the Surebackup job but this hasn't produced any successful results.

I have followed this KB and verified everything is as it should be: https://www.veeam.com/kb1067

Anyone run into a similar issue and have some path forward?

[Andreas Neufert]

Likely you have the Firewall on and allow communication only from known network. The Virtual Lab network is not known and so external communication will be blocked on the VM but when you ping from the VM it works?

[davidstepup]

When I login to the tested VM in the virtual lab I can get replies for ping requests to the VMs masqueraded IP.

[davidstepup]

UPDATE: So pings don't reply even when I first login to the tested VM via the vSphere console. I have to manually click on the network icon in the system tray first for it to respond to ping.

[Andreas Neufert]

Try this, create an Windows Firewall rule on the production VM to allow ICMP (PING) as well on undetected networks. backup and try SureBackup again.

[Andreas Neufert]

In the end SureBackup does exactly the job it was built for. It shows you that when you restore in a disaster in a new environment, that you will run into (same) issues there.

[vmtech123]

Try this, create an Windows Firewall rule on the production VM to allow ICMP (PING) as well on undetected networks. backup and try SureBackup again.

Id go this route.. I had the same issue. It has to do with the nic in windows.

if you turn off ping test etc, and log in via console in VMware you can see the firewall is coming up and blocking it as it's on a new subnet.

Unfortunately for myself, I'm not going to be changing the DC Firewalls to allow ICMP on undetected neworks.

I've just disabled the checks for labs, logged in with the console and accepted and was able to preform what I had to do. the VM's managed to talk to eachother within the lab

[PetrM]

Hello,

I would recommend to let our support team to investigate the issue because our possibility to troubleshoot technical issues effectively over the forum posts is very limited. You may share a support case ID with us so that we can keep an eye on it.

Thanks!

[soncscy]

> Unfortunately for myself, I'm not going to be changing the DC Firewalls to allow ICMP on undetected neworks.

Just as a thought, what about a pre/post thaw script during the backup that allows ICMP through then blocks it again after the snapshot? That way the testing works in an automated way, and the change is extremely temporary. Granted, it means on a full DC restore you have to consider this for the restoration, but should be easy enough to add to your restore procedure or just have it as a policy that'd be pushed out after restored.

[Andreas Neufert]

This would work. Other option, you could create a firewall rule that allows PING for the IP address of the Veeam Server and the Virtual Lab appliance only for undetected networks.
This way you can likely implement in production?