SureBackup Static Mapping does not work

[skoch]

CASE ID 00200347 - Attempting to use SureBackup with Static Mapping to allow clients/systems on other VLANs access to the lab does not work and is a known bug in 6.5.

I can't find this bug documented anywhere so hopefully this saves someone else some time. I'm told the issue is because the proxy appliance does not respond to ARP requests for the mapped static IP. This can be resolved by adding static entries to your router's ARP table or moving the system to the VLAN the other clients/systems are running from. The bug is scheduled to be fixed in v7 sometime in Q3 of 2013.

Unfortunately for us we're unable to add static ARP entries or move our system into dozens of VLANs simultaneously so we are stuck building an entirely separate development system to do a couple of hours of testing. Awesome.

[tsightler]

Interesting, I'm not aware of this issue and I've configured static mapping in a number of complex networks without this issue cropping up. I even have multiple networks in my home lab and experience no problems accessing the static mappings from any subnet. I don't see how this could possibly work in any environment if the proxy wasn't responding to ARP requests at all. I'm going to query our support team about this.

[skoch]

That would be great if you could check it out. The proxy appears to respond to ARP requests, but just not those of the static IP mapping.

[twashburn]

I'm experiencing this same problem with the 7.0.0.839.
I guess I gotta open a ticket.
Unless there's a KB article now.

[twashburn]

Ok, found this.
Guess I'll see if I can get our Network admin to do this.

Q: What if i want all computers on the network to be able to access those temporary VMs running in the virtual lab?
A: You should assign the proxy appliance static IP address in the virtual lab settings, and update your production router settings to forward all request destined into masquerade network (as configured in virtual lab settings) to the proxy appliance IP address. Alternatively, if you only need to access select VMs in the isolated network, you can use virtual lab's Static Address Mapping feature and point specific IP addresses in the production network to selected IP addresses in the isolated network. Proxy appliance will grab specified production IP addresses for its production network interface, and will take care of routing automatically.

[skrbnik]

Hi there. I am also experiencing the same problem. If the restored VM is in the same VLAN as the Veeam server and the Vlab proxy I can access remotely to the restored VM. If the restored VM is in a different VLAN as the Veeam server and the Vlab proxy I can not access nor ping the restored VM...

Do you have any suggestion or comments about it? Thanks

[twashburn]

I ran across this article and sat down with our network admin and went over it.

http://blog.dewin.me/2013/04/surebackup ... pdive.html.

So we had to put a route in the physical network switch that pointed at the virtual lab's external IP.
The veeam backup server doesn't need to as it does this automatically to it's own network interface.

[electricd7]

I have this EXACT issue. Surely this can be fixed somehow? I need machines outside the subnet of Veeam/VirtualLab to be able to access isoloated machines via the static IP i have assigned.

[skrbnik]

Thanks for the reply. As you did I sat down with my network guy and solved the problem as suggested.

[electricd7]

Hello,

We have been fighting the SureBackup appliance for the past couple of weeks because we want to spin up an Oracle server inside the sandbox and then allow static-mapping through to the isolated VM. This works great as long as the client you are using to connect to the isolated VM resides on the same subnet as the Veeam Server and the Proxy Appliance, but falls on its face if you are trying to access it via a machine that is on a different subnet. This is a very common network I would think for most enterprises where servers reside on one vlan and PCs reside on a different. We have 30+ VLANs in this particular network.

The Veeam Appliance should act as an "arp proxy" whereby it responds with its own MAC address for any arp requests it observes on the outside Ethernet interface for IP addresses that it is destination (global) NAT'ing.

This limitation is currently overcome by adding an ARP entry into the core router for the MAC of the outside interface of the Proxy appliance, but this should not have to happen as it could be easily cared for by the appliance itself with a little tweaking.

Chad