Feature Request: Virtual Lab HTTP Proxy

[segfault]

The SureBackup virtual lab proxy appliance has a built in HTTP proxy to permit VM's inside the isolated lab to get out to the internet, what I'd love to see is the reverse: The ability to run an http proxy on the appliance that allows external users to reach into the virtual lab.

This way I can instruct the app testing folks to configure their local copy of Chrome/Firefox/Whatever to use the virtual lab proxy appliance as an HTTP proxy so that they can test the web based apps that are running in the virtual lab.

Right now I need to include a windows 10 box in the app group and then they can use the VMWare console to login and test the various applications. Alternatively, I'm contemplating the setup a VM on the side with a similar network setup as the Veeam lab proxy except that it also includes a copy of ATS/NGINX/Squid/Etc for the testers to use as an HTTP proxy.

Thanks,

--john

[Rick.Vanover]

Hi John - interesting idea. You may want to consider Veeam Availability Orchestrator. There are upcoming capabilities (next release) with new roles and console provisioning inside the Data Lab.

[segfault]

I looked at VAO, but the cost of $102/vm/year was quite exorbitant and quickly put an end to any possibility of using it.

I can understand the value proposition for folks with a handful of high value VM's that need to be protected, but when it is all said and done I'll have over 300 or so production VM's being replicated up to our DR site. I would be paying more every year for just the VAO license than I did for a perpetual license to backup and replicate my entire infrastructure, and we have the full enterprise plus availability suite license for 30 sockets.

--john

[Rick.Vanover]

Cheers, John. I could see some hackery and scripting easily made that would put this together pretty easily if not baked in. It's a decent request "DataLab Gateway" as it were.

[PTide]

Hi,

If I understood your request right, static IP mapping should let you reach the isolated VMs from production network.
Alternatively, you can login into the appliance and configure a proxy manually.

Thanks!

[segfault]

Thanks for the additional ideas on how to accomplish the testing.

Static IP mapping would work if I setup a custom host file for the tester that references the masqueraded IP's and have the network team update the routing table between the tester and the appliance in the remote datacenter. The other downside is that this setup has the side effect of potentially leaking requests to systems not in the lab if the hosts file is not setup exactly right.

I didn't think about abusing the fact that under the hood the appliance is just a linux box. In theory I could load my own copy of ATS/Squid/Apache/Nginx/whatever on the system. I'm hesitant to do this since odds are it would be unsupported and potentially wiped out at the next Veeam maintenance patch.

For now I'll just spin up a small linux host to operate in parallel with the lab proxy appliance. Once Veeam officially supports the functionality I can remove it. This makes testing of web based apps relatively easy. Thick client apps will continue to require a client OS loaded into the lab to run the client app on, but it seems that we have fewer and fewer of those each year.

--john

[PTide]

Static IP mapping would work if I setup a custom host file for the tester that references the masqueraded IP's and have the network team update the routing table between the tester and the appliance in the remote datacenter.

If you have a spare IP in your production network, and the network is already accessible from the tester's machine, then you won't need to update routing tables. The static IP will be assigned to the proxy's network adapter connected to the production network. IP traffic directed to the specified static IP address will be routed by the proxy to the VM in the isolated network.

Thanks!

[segfault]

The static IP will be assigned to the proxy's network adapter connected to the production network. IP traffic directed to the specified static IP address will be routed by the proxy to the VM in the isolated network.

I could combine the static IP with a local host file entry that keeps the name the same. The only problem is that host file modification requires local administrator rights to the box which is a show stopper in our environment. An httpd proxy can be swapped out in chrome without elevated permissions and quickly via a chrome plugin, so the test users and admin staff like that. Hence why I was starting to explore the option.

If I try and use a different dns entry for the static lab IP (e.g. sharepoint-lab.example.com) to avoid the need to modify the local host file then I'll run into certificate errors and constant redirection back to production for apps like sharepoint and wordpress.

For basic HTTPS access, a proxy on the appliance (the feature request) or a small http proxy box that sits on the same networks as the appliance is a bit simpler for the test crew and avoids the need to spin up an RDP server inside the lab for end user testing purposes (the current method).

--john