Sure Backup - Ping Virtual Appliance Gateway

[lightsout]

All,

I did try to search for this, but without luck.... too many other ping issues with virtual labs/sure backup. I have an issue with a Windows 2012 R2 DC thinking it is on a public network, and then, nothing can authenticate to it as the Windows firewall blocks it. This issue seems to describe it:

http://serverfault.com/questions/362374 ... ic-network

The Sure Backup/Virtual Lab works fine overall:

1. Machines in the virtual lab can ping each other.
2. The Veeam server can ping down to most servers, apart from the DC, as the local Windows FW blocks it.

If I logon to the DC, then it cannot ping its gateway, which is the Veeam virtual appliance. It can ping the other machines as described above.

So, if there anyway to get the virtual lab gateway to respond to a ping?

[foggy]

I remember similar cases being reported here previously, when Windows Firewall recognized virtual lab network as a new one and applied "public" profile to it. QC is currently looking whether this could be caused by some issue in the proxy appliance. You can disable firewall or configure it appropriately as a workaround.

[lightsout]

In this scenario, I don't control the server I'm backing up so I can't change its firewall so easily.

It would strike me, for testing purposes, being able to ping the appliance would be a good thing regardless?

[haslund]

It seems to me the Proxy Appliance does not reply to ICMP/ping from the isolated network(s).
Is there any way to enable that?

I have a customer who has Windows Firewall enabled on all VM's including domain controllers.
The issue is since their default GW does not respond to ping, Windows Firewall changes profile from Domain to Public = blocks basically all traffic = SureBackup validation fails

Thanks!

[foggy]

Another workaround is to set unidentified networks to get the Private Profile by default via GPO.

[alanbolte]

In my experience Network Location Awareness only changes the profile to Public if the VM cannot connect to a domain controller. Is there a domain controller in your Application Group?

http://blogs.technet.com/b/networking/a ... files.aspx
This article seems to support that while the gateway matters for determination of private networks, only the domain matters to determining if you're on a domain network.

If the VM in question is a domain controller, setting the NLA service to delayed start usually resolves the issue.

[haslund]

How do we enable ICMP responses from the Proxy Appliance from the isolated network?
Corporate policy does not allow GPO changes to set unidentified networks to get Private Profile.
Disabling firewall would also violate corporate policy.

In this instance the tested VM _IS_ the Domain Controller.

[lightsout]

So we've got the same issue, which is good.

I turned the ping check off, which is bad, but is still stops the VMs from authenticating if the FW profile goes to public. The DCs are tightly controlled, and I can't change them at all. Having the gateway ping seems like a good idea as I already mentioned, if nothing else, to help TS issues. I am guessing the appliance's firewall is blocking ICMP on the isolated networks, so if this was allowed, I suspect it'd fix both of our problems.

[mplep]

I am experiencing the same issue where the DC see's a Public Network and I cannot ping the Proxy Appliance. My research led me here but we don't seem to have an answer on allowing ICMP response from the Appliance? I do not wish to make GPO changes either.

Any help appreciated.

[lightsout]

Given we've got a lot of people with the same issue, rather than us all changing our environments, is there any reason not to get the virtual lab appliance just to respond to ICMP and fix it for all of us?

[nefes]

As Alexander already said, we are now reproducing that behavior in our environment.
If the bug is confirmed, it will be fixed in one of upcoming patches.
For now we are trying to propose you temporary solution, not avoid fixing at all.

[foggy]

Indeed, ICMP is not currently allowed on the appliance for some reason. The good thing is that it is already allowed there in the next update, so we expect this issue to not show up anymore, once the update is released.

[adrien.herve]

Hi guys,

I have the same issue in my lab. I can't ping the gateway in my isolated network from my restored VM in the vLab, can you please tell me if it's a proper behavior?

Thanks,

[foggy]

Adrien, this is expected with the current version, however will be addressed in the next update, as it was mentioned above.

[lightsout]

So I've updated to Update 2, I edited the virtual lab so Veeam pushed the new appliance image and then started my virtual lab.

I still can't ping the gateway. Can anyone else test it?

[foggy]

Please contact technical support to verify your guest OS and virtual lab network configuration. I've just checked with QC and according to them this should work after upgrading to Update 2.

[lightsout]

Case 00900789 submitted!

[lightsout]

Support have confirmed the issue - they can't ping the gateway either.

[Vitaliy S.]

Thanks for the update, we will forward this details to our QC team.

[foggy]

Yep, QC guys were also able to reproduce this, we will investigate this further, thanks for the heads up.

[lightsout]

Thanks. Support couldn't help me any further as this is essentially a feature request at this point. Given the interest in this thread, I think that is sufficient justification to do it?

[foggy]

Yes, definitely.

[foggy]

Here's a simple workaround that seems to help (at least in our tests) to address the issue while we're working on a fix. Ping starts to work if the Allow proxy appliance to act as internet proxy for virtual machines in this lab check box is selected.

[lightsout]

Nice one foggy, that works. I just enabled the proxy with the defaults settings, so it won't actually route traffic, and now it pings.

[cojaxx8]

Hello,

I'm just in the process of setting up SureBackup to test some VM's and they keep failing. The issue is that when the VM's boot the OS assigns the Public Firewall profile.

My VM can successfully ping the gateway and in this instance the VM I am testing is also a domain controller. My Virtual Lab network is set to replicate the production network (meaning the Virtual Lab IP has the same default GW as what the production servers have).

There is a section in this KB article (https://www.veeam.com/kb1067) that references "STATIC ROUTE NOT BEING CREATED", but I can't do that can I? Because since my Virtual Lab network is on the same subnet as my production network, wouldn't that break routing for my Veeam Backup Server?

I have also setup a proxy as per this (https://helpcenter.veeam.com/backup/80/ ... xy_vm.html). The port got changed to 80, but then it asks to change the proxy settings on each of the servers. I'm assuming this means the production servers, if that is the case, this is once again going to break internet access on my production servers, because I don't use a proxy in production.

I must be missing something.

PS. The VM I am testing this on is a Windows 2008 R2 DC, and have installed the following patch so that it keeps the same static IP (http://kb.vmware.com/kb/1020078). Veeam 9.5 is being used on Windows Server 2016.

Regards,
Peter

[foggy]

Hi Peter, please refer to workarounds mentioned above.

[final]

I'm playing a bit with SureBackup (not in production yet, but as we have it in our Veeam license, why not give it a shot). Things are going quite well, but I seem to have a little problem with my DC:

I've set up an application group with a DC and a file server. Simple enough. The DC (I tried two DCs, Server2012R2 and Server2016) boots up fine, reboots out of safe mode automatically, then replies to ping and all the test scripts run ok. It also keeps its network configuration on the single NIC it has. The two server are able to talk to each other, so I guess my virtual lab network config is ok (well, it's simple, has both servers have one nic and are in the same subnet)

The issue is that the DC himself thinks that he is not on the "Domain Network", but on a "public network". Hence, it turns on the firewall. Because of that, my second server cannot authenticate against the DC - the DC's firewall is blocking the reqeusts. Also, the because of that, the second server is also on a public network - it cannot find a DC.

I feel that this is less of a SureBackup question than a "how to configure your DC properly" question, but it's beyond me why the DC himself thinks he's not on the domain network. My DC is a GC and hosts DNS services. It's also the DHCP server - because of that, I've disabled the DHCP services on the virtual lab appliance. The DC's DNS-Client has 127.0.0.1 entered as the secondary DNS-Server, according to some "best practices" blog post of Ned Pyle back in 2010. DNS resolution on the DC works fine, and so does AD authentication. Restarting Network Awareness Location service doesn't help either - the DC re-discovers its network location and still thinks it's on a public network.

I've found some posts across the internet, but nothing seems to help me.

[PTide]

Hi,

Might be a long shot, but does Network Location Awareness service start before the domain is available?

Thanks

[foggy]

This is somewhat expected. When VM is loaded in the virtual lab, it considers the network as the "new" one, so firewall switches to public network profile. Please see above for some thoughts.

[kayvonp@re-wa.org]

Does anyone know of a way to ensure that a Windows Server VM booted during a Surebackup job gets assigned to the correct firewall profile? We have the public and private ones locked pretty tight so the tests fail unless they are assigned to the domain profile. I tested with a domain controller and the tests failed and I think it's because the NIC got assigned to the public firewall.