On surebackup jobs from B&R outside production subnet

[selva]

I run Surebackup jobs from a B&R server connected by routed VPN to the production subnet. This requires setting up some routes on the B&R server and VPN gateway, and works fine. But its a manual process and I run into an issue trying to automate it. Here is the problem:

Production subnet: 192.168.1.0/24
Virtual Lab masqueraded subnet: 192.168.255.0/24
Virtual Lab proxy machine IP: 192.168.1.96

Automatic route added by B&R when the surebackup job runs: route to 192.168.255.0/24 via 192.168.1.96.

This is a useless route but it doesn't hurt. I override it with a route via the VPN gateway:

route to 192.168.255.0/24 via VPN_gateway_IP

To avoid this manual intervention I want to setup this route in advance, but that causes the surebackup job to abort with

"Found existing route from 192.168.255.0 to gateway a.b.c.d".

Is there a way to tell B&R to skip this check or, even better, skip the step where it adds a route to the Virtual Lab?

And a feature request: Make B&R a bit smarter here -- check the gateway through which VirtualLab proxy IP (192.168.1.96 above) is reachable, and add the route via that interface.

[Andreas Neufert]

Not sure if it would work this way.

For the B&R Server, you need to make sure that the Virtual Lab Proxy IP address can be reached. I think this is done by your VPN. And by that the automatic route would work in this direction.

I guess your issue is more with the route backwards. The Virtual Lab Proxy IP has likely your Router as a Gateway. This router needs to find back to your sender (B&R server IP address). So you need to add a static route to this device, so that you can ping your B&R Server from the Virtual Lab Proxy IP.

[selva]

As I wrote, my manually added routes are all fine and the backup does work. Return route is not an issue as its all properly setup. The route I manually add on B&R is required. The issue is Veeam errors out on seeing there already exists a route to the virtual lab, requiring me to add that route manually at the "right moment". It wants to add a route to the virtual lab via the default gateway which is fine[*], but if I can make it not error out because of the existing route, I can avoid manual intervention (or dirty hacks).

Anyway, from your reply, it seems what I'm asking for is not possible. I understand this may be a rare use case, may not be worth supporting.

[*] The automatic route added via a gateway outside the subnet is meaningless, but its also harmless. That's fine, but B&R should not consider the existing route as an error. A warning would be more appropriate.

[PetrM]

Hello,

We cannot skip the check of the existing route, otherwise we cannot be sure that workloads are being tested in the environment which is entirely isolated from the production one.

Why Veeam B&R cannot access 192.168.1.96 (Virtual Lab) if the production network 192.168.1.0/24 is already reachable over VPN? One more point to consider is why do not add a route to 192.268.1.96 via VPN_gateway_IP instead of the route to the masquerade network 192.168.255.0/24 via VPN gateway? As Andreas said, Veeam B&R must be able to see Virtual Lab.

Thanks!

[Andreas Neufert]

As I shared, you do NOT have to edit or change the dynamically created route.
If the dynamically set route is not accessible by the B&R Server by the normal routings, you need to add additional routes, but not for the dynamic added subnets.
The dynamic route will point as GW address to the virtual lab applaince IP. If you can not ping this IP address from the B&R Server when you start the lab, you need to guide the Backup Server to that other subnets. Like telling B&R that the subnet of were the Virtual Lab appliance is located will be reachable through the router within your production network and not by the default gateway of your standard connection.

This said, you need to make sure as well that the way back is working correctly. That the Virtual Lab appliance can find the B&R Subnet through the default Gateway defined in the Virtual Lab wizard. (Do not set any route for the Masquerade Subnets).

I suggest to do the following simple test. Start the lab and log in the Virtual Lab Appliance console. Try to ping the B&R Server. If this is not working you need to set routes on the Router that is used within the Gateway definition in the virtual lab wizard and potentially as well on the B&R Server. When this PING is working correctly in both direction, then the automatically created dynamically entries for the Masquerade Subnets would work without issues.

[Andreas Neufert]

The password for the Virtual Lab Applaince can be set in the credential manager in the top left menue of the console.