SureBackup - Masquerading?

[ksl28]

Hi,

We just started looking into SureBackup, and was really impressed by the first impression - but are now struggling to understand some of the network features.
https://helpcenter.veeam.com/docs/backu ... ml?ver=110
Our VBR Setup (VBR, Repo, etc) are completely seperated from the production environment - so the SureBackup production IP, is in our production network. This is so that clients can connect to the SureBackup environment, using static mappings.
This also means that for the VBR server to reach the SureBackup proxy, it has to go through the normal network routing.

This is causing us some issues, since the masqueraded subnet(s) are only known to the VBR server - once it sends that out its default gateway, the normal network routes takeover, and the package is routed somewhere else.

But why is it even necessary to use masqueraded subnets?
Veeam already knows the production IP of the SureBackup proxy, and it should be basically just send an request to the SB Proxy, asking it to perform an ping test of the guest VM.
Instead the VBR server sends an ping package, to an masqueraded IP, that the proxy then forwards to the guest VM. The orchestration should be inside the VBR, but the worker should be inside the SB Proxy.

According to Veeam the masqueraded subnet, must be equal or greater than the production network, that you want to "emulate".
In one of our VLABs we currently have these servers:
Server: VBRSrv1
Production IP: 10.100.10.10/29
Server: SureBackupProxy1
Production IP: 10.200.10.10/25
Server: WebSrv1
Production IP: 172.16.10.10/25
Server: WebSrv2
Production IP: 172.16.10.20/25
Server: WebSrv3
Production IP: 172.16.10.30/25
Server: DC01
Production IP: 172.20.0.10/29
Server: DC02
Production IP: 172.21.0.10/29
Server: AppSrv1
Production IP: 10.10.10.10/25
Server: AppSrv2
Production IP: 10.10.10.20/25
Server: SQLSrv1
Production IP: 10.20.10.10/24

Since we need to route our masqueraded subnets, we then need to reserve 2x/25 subnets, 2x/29 subnets and 1x/24 subnet.
These subnets needs to be routable, and is an huge waste of IP addresses.


Have i misunderstood the masqueraded concept completely, or is it really as complicated as the above?

PS: We are not talking about Static Mapping here. Its similar to NAT in an router, and works perfectly

[HannesK]

Hello,

But why is it even necessary to use masqueraded subnets?

because that design is flexible and easy to implement Agree, there are other ways to solve that.

Your understanding in general is correct. You can avoid wasting IP addresses by putting the SureBackupProxy1 in the same subnet as the VBR server. Then you don't need to set static routes on your production network. Of course, this only works if your clients from other subnets don't need to access the lab.

Best regards,
Hannes

[micoolpaul]

Hi,

You’re correct in what you’re saying.

The point of the masquerading is that the Veeam SureBackup Virtual Lab is routing traffic and performing NAT services, but it’s not performing any “logic”, your scripts run from your VBR server. It’d arguably be more complex if the SureBackup Virtual Lab had to perform all of the actions to interact with your VMs and I’d argue it would slow down development of testing as it would require different ways of working.

[Andreas Neufert]

Yes, B&R could be teached to just reach to the vLAB production IP address, but then all kind of other functionality would not work. We have a lot of customers that run all kind of software on the B&R Server or on the Universal Restore Client to connect to the vLAB and production at same time to compare or transfer data (restore).

To implement it in the TCP/IP stack so that you can use it universally is the best way and therefore we went that way.

When you do not have the vLAB production IP in the same subnet as the B&R Server (or Universal Restore Client), then you need to set a route on your router (default gateway) so that the Masquerade Subnets are forwarded to the Default Gateway.

You need the same amount of IP Subnets for masquerading for any vlab that uses them. As most of the systems are not allowed to communicate directly with the internet (or at least do not have to communicate with most of the internet), you can use as well Public IP Subnets for the Masquerade Subnets.

For example you can use
11.10.10.10/25
as masquerade subnet for your
10.10.10.10/25 subnets

This means the backup server can not communicate with the 11.10.10.10/25 subnet in the internet anymore when a vlab is started, but why should it. The warning message about public IP usage can be just ignored.