SureBackup - multiple production networks and VLANs

[CaliMSP]

Hi
Got a question about how to configure SureBackup to work with multiple networks and VLANs. I have not deployed SureBackup before. Some of our systems (including Veeam server) are multi-homed 192.168.x.x and 10.x.x.x (vlan) , others are within a single network. All of the guests are on two hosts that have access to both networks/vlans. I'm a bit confused about how to configure the virtual lab networking options in this case, especially since your docuymentation recommends "advanced single-host" (manual configuration) for this scenario.

1) in Isolated networks, do I need to map both production networks 192 and 10. to Virtual Lab VM network by adding the second entry?
2) One of our networks (10.x has a different mask and is on a VLAN). Your documentation says that both networks must have the same mask, plus setting VLAN ID affects both - so I can't set one network with vlan0 and one with vlan1.
3) in network settings - Masquerade IP is isolated subnet IP that will not have direct connectivity to production, right?
4) in network settings - it prepopulated Appliance IP with 192.168.x.1 (there is no veeam proxy or gateway/firewall at this IP). What is it looking for? The docs says it's looking for the "Gateway" IP of the production network, which in our case would be .254 (firewall)?
5) Do I need to create a second vNIC for the 10.x network as well?

[micoolpaul]

Morning, I believe I can help here:

1) Correct!
2) Check out the diagram on https://helpcenter.veeam.com/docs/backu ... ml?ver=110, it shows two VMs with different masks. It’s important to mirror their production network mask, but the individual networks can have different masks to each other, as long as it reflects their production mask. This is because IP masquerading is being used. If you used a 172.16.0.0/16 in production and then configured a 192.168.0.0/24, the moment you got to the 172.16.1.x section, Veeam is out of IP addresses to NAT. As for your comment about changing the VLAN, IMO it isn’t as clear but the second field on creating your network is free text, if you don’t amend it you’ll be placing your VMs into the same isolated network and that VM port group can only have a single VLAN. See here RE second field: https://helpcenter.veeam.com/docs/backu ... ml?ver=110
3) Correct, when your SureBackup virtual lab is running, your VBR will temporarily create a static route for that subnet. I.e. your production subnet is 10.0.0.0/16, your masquerade IP address subnet is 10.1.0.0/16. Your virtual lab needs 1x production network IP for itself to talk to VBR and act like a router, performing NAT. Say this is 10.0.0.200. Your static route will appear to 10.1.0.0/16 via 10.0.0.200. If your VBR and virtual lab live in different subnets, the ARP lookup of your virtual lab’s MAC address will fail and the packet will go to your default gateway, so your network would need to be aware of this subnet and pass traffic to the correct network to reach your virtual lab. I often see this with SureReplica across geo-locations.

4) For each network, your virtual lab needs to know the production network’s subnet and gateway. This is because a lot of tests require 2 way communication. As no RE-IP addressing will take place on your SureBackup/SureReplica jobs, we’re leveraging NAT here. So the virtual lab needs to know your existing default gateway to impersonate it for your VMs. Back to my prior example. If production is 10.0.0.0/16 with a default gateway of 10.0.0.1, and we’ve got a VM that is 10.0.0.2, when we perform IP masquerading with 10.1.0.0/16, consider what happens when we do a ping test to the VM. It’s masquerade IP is 10.1.0.2 so we can route the traffic to 10.0.0.200 (virtual lab from previous example), virtual lab will NAT this traffic to 10.0.0.2, but it still needs to have an origin that can have traffic returned to it, so by configuring the IP of your gateway, we can assume it’s IP address within our isolated environment. we can now change the source details to be our virtual lab (10.0.0.1/16), and deliver the ping, assuming no firewall rules on the VM drop/block the packet, it’s delivered successfully. But the thing is, VBR needs to know if the ping was successful, so how do we get the response back? The VM sees the ping originate from the gateway IP (our virtual lab), and forms a response packet. This gets delivered to our virtual lab, which will then NAT it back to its true source, our VBR server. Then VBR knows the ping test was successful. Any network level interactions for VM testing work this way, such as port checks for web server or DNS.
5) Yes you do.

Appreciate there’s a lot I’ve said above, SureBackup is one of the tools with the steepest learning curve as you have to look at what’s going on with the underlying networking to wrap your head around it. Hopefully this all helps and any further questions I’ll do my best to answer.

[joetheghost]

This is my exact situation, can you make a step by step visual guide because it isn't making sense to me.

Thank you.

[micoolpaul]

Hi,

I don’t work for Veeam but they’ve already got a lot of diagrams on their help centre. Happy to answer any questions with this though, maybe if you diagram or explain what you’ve got and how you want it to work?

[joetheghost]

Thank you for answering.

My issue is, I don't understand how to configure the lab part without a real world example. The only example I see is for a flat network not a multi vLan. I guess I need to call Veeam to help walk me through it. Like in the isolated network, I can only configure one VLAN ID: no mater what I've tried, why? If i had an example of how it should look then I can do it.

[micoolpaul]

So we can tailor this to what you need, are you Hyper-V or vSphere?

[joetheghost]

We are running vSphere.

[micoolpaul]

Okay, that should be fine then.

So here's what you need to know:

You'll create a virtual lab (https://helpcenter.veeam.com/docs/backu ... ml?ver=110), and you need to be aware of the following:

The way a virtual lab works, is similar to a firewall, it performs NAT. So you'll configure an IP address for the virtual lab, preferrably within the same L2 subnet as the VBR server (not necessary, but a lot easier when within the same L2).

Before I explain how the NAT process is performed, I'll explain why we need this. When you spin up your isolated copy of your VMs, we need the VBR server to communicate to the isolated VMs. Consider the following network: a subnet of 10.0.1.0/24, with a VBR server configured with 10.0.1.10, a virtual lab IP address of 10.0.1.11 and a domain controller of 10.0.1.20. If we don't manipulate the IP addresses, and we tell VBR to test the domain controller services such as DNS, it would create a packet to 10.0.1.20, which would hit the production domain controller, a massive no no for what we want!

To avoid this, we create isolated networks and specify network settings for these. These are to exist as subnet ranges in identical size to your production network, but in unused IP address ranges, in my example lets choose 10.1.1.0/24.

At this point you might be going, huh? How's it going to get there? And that is through the magic of adding a temporary static route to the VBR server itself (this is why I said it's handy if you use the same L2 as your VBR server, it's not necessary, but when it's not in the same subnet, VBR has to send the traffic to its gateway, so you need to add more routes into your upstream core switching and firewalls.

So VBR would add a route saying that it can reach 10.1.1.0/24 via 10.0.1.11 (the virtual lab from earlier in the example). This way, when it wants to talk to the domain controller, it will address the packet to 10.1.1.20, the route table says, send this onto the virtual lab, and then the virtual lab performs NAT to swap it back to the appropriate IP (10.0.1.20) once inside the virtual isolated copy), this is because if you're working with replicas, any re-IP rules aren't applied during backup/replica testing.

Hopefully this helps as a start, as to the comment of creating multiple VLANs, at step 6 of the deplyment, choose advanced single-host: https://helpcenter.veeam.com/docs/backu ... ml?ver=110

Then to create your multiple networks, at step 7, select add, choose your production network, and then ensure you give it a unique ISOLATED NETWORK name, and then VLAN, though if you're using single host, it's going to a vswitch with no uplinks, so VLANs don't really matter anyway... Then just be sure that each additional network just has a unique isolated network name & VLAN also.

Does this help to start? Please give some detail on any questions