Due to security requirements we have a couple of DMZs in our environment, within which "secure servers" exist, one of which even does so behind a dedicated firewall (i.e. double-bastion).
We're looking at leveraging replication/vlabs for fresher dev & UAT environments which technically work great, but (specifically for UAT which would require some user access so masquerading etc. is perfect) however, because the mapped IP addresses effectively sit on the production network, that brings the environment outside of any fw rules and so causes our security people to get very twitchy
Is there a way of leveraging vlabs such that the "production" network that is forwarded/masqueraded into the isolated network can exist within a protected (fire-walled) subnet, even if we just spin up a new subnet with same FW rules in order to maintain vm->vm isolation, or is this one of those circumstances where the "production" network actually has to be the same subnet as the B&R server (which I know is the case for certain elements of B&R deployment but can't for now remember what those are).
OK, a supplemental question that might help. In terms of "Production" network when configuring a vLab, what rules are there as to which networks can be chosen for the proxy primary address? Anything such as "it must be on the same network as the backup server" or "can't be a routed network from the end-user's perspective" etc.?
If literally any configured network is acceptable, then I think i can simply spin up another Subnet/PortGroup/DMZ as a permanent addition, apply the same f/w rules to this subnet/dmz as to the original subnet/dmz, but replacing the IPs (in the f/w rule) with the masqueraded IPs, which hit the "production" interface on the proxy, then get passed back to the isolated network.
not sure if this is what you are looking for but don't see why you can create lab then move to vlan on protected network. The lab is what is doing the masquerade so point to it for the route. route masquerade IP > lab ip.
I have a few Labs appliances all talking together so I can load balance. I now have one lab per ESX host all talking. I could add a couple more labs for internet proxy and host mapping if needed for throughput. This allows a complete test and DR capacity verifying.
You can create a lab, take note of the interface names made on the labs Vswitch. Rename those interfaces in vcenter. Create interface on production vswitch with name from step 1. Connect to vlan for labs. Repeat for any number of Veeam labs. Now when you power on the labs the interfaces will be connected to a production vswitch. Only one lab can have the IP address of the default router. The IP address you assign to the lab can be a real address; I use my product IP addresses at my DR site, now everything uses their normal IP. The masquerade IP can be set in DNS to allow access from other sites to the VMs in the lab. You can also place physical PCs into the lab by place switch ports on the vlan created by the lab.
The lab appliance will take care of routing between the vlans for you if you put the rule in the lab config. The static mapping will also work from the lab.
option b
If you have a spare Nic in your ESX just attached to lab and skip all the interface renaming. Still can use the lab to route between all the lab subnets.
