SureBackup Isolated network isn't isolated

[bhagen]

I've created a virtual lab, an application group, and a surebackup job. Thankfully I decided to target a test VM, because when I run the surebackup job, the production vm gets run over by the vm in the "isolated" network.

???

The production vm is in our production site; I run a continuous ping to it, and see a latency of <1ms.

I start the surebackup job, and as soon as it spins up the vm (it's actually a replica, in our DR site), my ping latency jumps to 26ms...which is the latency to our DR site.

So...my "isolated" network isn't isolated at all; the vm that I spin up in that "isolated" network is completely accessible to our production network.

Why would this be? How do I fix this?

[PetrM]

Hello!

I think it makes sense to consider one of these 2 methods to isolate port groups from the production environment as long as you use advanced multi-host virtual lab configuration.

Thanks!

[skrause]

Make sure you use different VLAN IDs for your isolated networks compared to their corresponding production networks.

I accidentally caused all kinds of problems by starting up a virtual lab that had the same VLAN IDs as it created some weird network loops when I was initially testing Sure Backup a couple years ago.

[bhagen]

One goal of spinning up these VM replicas is to do Windows Updates on them and evaluate any issues. If I change the vlan of the isolated network, that certainly keeps it off the production network; but it also prevents me from doing windows updates (or accessing the VM from anywhere but a vmware remote console), unless I change the IP of the VM to that vlan. But even doing that won't allow access to windows updates, since the vlan of the iso network isn't a vlan on our production network.

Kind of a bad circular logic.

For grins, I just tried changing the vlan of the distributed port group on the dvswitch to a non-existent vlan and ran the job. As I suspected, the job failed the ping test, and stopped the job.

The promise of virtual labs is that I can spin up my DC, file server, SQL server, etc (everything that is necessary to duplicate my production environment) and test updates, do a quick SQL dev session, or whatever, with access to the internet, without disturbing our production environment.

Has anybody here actually done this? If so, can you walk me thru it?

[PetrM]

Hello!

As far as I understand you use vlan id tagging method to isolate port groups, right?
Anyway, please double check that you specified correctly network mapping at this step of Virtual Lab configuration wizard.

Probably the options below could be helpful in your particular scenario:
1) You can make proxy appliance act as internet proxy for machines which are running in a virtual lab.
2) Static IP mapping is another option which might be useful to make VMs in the virtual lab accessible from production network avoiding IP conflicts.

Thanks!

[ChrisGundry]

The documentation is very poor for vLabs and doesn't explain it very well at all. The support team also do not understand it very well, we have had very frustrating experiences with them related to vLabs.

What I can say is that it does work and works very well, once it is setup. Which version of ESXi are you running? We are currently troubleshooting an issue where it was working great in 6.7 U2 and now in U3 it is no longer working.

I can say this though:
Isolated VLAN doesn't need to exist on the production network. But you do need to have a masquerade network configured in the proxy appliance.

Say your production network is 192.168.100.x/24 and VLAN1 and the GW address is 192.168.100.250
Your network within your lab the proxy IP on the isolated network should be 192.168.100.250 and the masquerade network range on that page should be listed as whatever IP/range you want to use to connect to your isolated VMs, lets say that is 10.100.100.x/24.
On the screen where VLANs are mentioned you need to specify a VLAN ID for the isolated network, otherwise it will conflict with your production network, which seems to be the issue you are having.

When Veeam runs the SureBackup job it enters a static route on your B&R server to point the 10.100.100.0/24 range to the proxy IP on 192.168.100.x. If you have complex routing between your B&R server/site and where the lab is running then you will probably need to add some more routing somewhere to ensure the 10.100.100.0/24 traffic gets to the proxy appliance on 192.168.100.x.

We do patch testing any all sorts of other things using vLabs and it can work very well for what you want to do.

Feel free to message me if you want.

[bhagen]

Nice! Thanks for this. I have questions, but am heading into a meeting; will parse thru this later today!