Skip to main content
  • EN

Hi all,

We have recently moved from VMWare to Hyper-V.

We use Veeam B&R V12 and have encrypted offsite backups going to a remote backups repository via a site-to-site VPN connection to a third party. 

On VMWare, we used VMs as backups proxies and included only those VM addresses in the site to site VPN.

When we moved to Hyper-V, because of the on-host backups proxy architecture, we needed to add the Hyper-V host IPs into the VPN profile.  On any given day, I’m happy that the remote team follow best practice in terms of security but I’m not willing to expect that to always be the case.  I’m really not comfortable having our host IPs being directly accessible from a third party location, when they have control over the remote IP scheme.

Is there any way to introduce a VM as a backups proxy as per the VMWare architecture to remove the Hyper-V host from the VPN?

If not, is there any reason why I can’t just block all inbound access from the third party IPs?  I would expect that all activity is initiated on my side, is that correct?

With thanks,

Simon

Hello, 


On Hyper-V, Veeam requires on-host proxies, so using a VM as proxy, like in VMware, isn’t supported. However, you can block inbound traffic from the third-party side, all backup activity is initiated outbound from your environment, so your Hyper-V hosts don’t need to accept incoming connections.

To be more specific, you can have “Off-Host” Hyper-V proxies, however it isn’t recommended to run these on virtual machines. You can set up a physical “Off-Host” proxy, which may address your concerns.

Thank you both.  ​@Tommy O'Shea thanks for that but I have ruled that out.  The documentation for system requirements for “Off-Host” Hyper-V proxies states that the physical machine must run the same version of Hyper-V as the host.  We have Datacenter licenses for our existing hosts but nothing in the budget for something like that.

I’ll go ahead with blocking inbound access to the hosts from the remote site.

Thanks again,

Simon

Just a final point on this.  I blocked inbound connectivity from the remote site as discussed above.  This broke file level restores from the remote repository.  It seems that the remote mount server must initiate what looks like a new connection back to the B&R server as part of FLR, which the firewall drops because it’s not part of a current connection. 

I have two options - open the necessary ports on the firewall, which I believe from the error is just TCP 9401, or I can treat this like a cloud repository and have the mount server on the local site instead of the remote. 

I reconfigured the repository to use the Veeam B&R server as its mount server.  This affects performance in restores but it works, so I went with this.  I have the firewall rule to allow traffic in place but it is disabled, and I can enable it a situation where I need a more performant restore.

Thanks all,

Simon

Terms & ConditionsAccessibility statement