What can stop SureBackup masurade working?

[pkelly_sts]

I've finally had some time to get into SureBackup properly and have a test working with two VMs (one a SQL vm the other a web server) and it successfully completes all SureBackup tests.
However I can't seem to be able to access the masqueraded IP's from the B&R server and further testing shows that the two VMs can access each other, but neither can access the isolated IP of the proxy (which has been configured with the same IP as the hosts' normal Default Gateway, nor can the proxy vm ping the test VMs.

I can ping the production side IP of the proxy on the production network from the VBR server. Static routes on the VBR server appear to be correct, sending masquerade traffic to that IP.

They're on a /28 network & are very close in IPs (DG is x.x.x.13, VMs are .4 & .5) so can't see it being a subnet mask issue.

Also the Netmap rules o the proxy /appear/ to be correct to my eyes (having gone through http://blog.dewin.me/2013/04/surebackup ... pdive.html to check my setup).

I've tried them with a random/unused VLAN (which shouldn't make any difference anyway as there are no uplinks) as well as a VLAN of 0 just to rule it out.

Can anyone suggest anything else I should be looking at?

Paul

[tdewin]

Pinging from the router directly could not be the best test because your request will probably not be "mangled" or "natting" won't be applied correctly as you are not coming in via eth0 but are rather already on the server itself.

You should be able to ping the default gateway address from the vm's in the isolated environment, that is the real ip (x.x.x.13) and not the production side of the proxy nor any masqueraded version. With ifconfig eth1 in the appliance you can check that it is really set to the ip address you expect (x.x.x.13). Then check in VMware that the isolated VM's are properly mapped in the same portgroup as Network adapter 2 of proxy/nat appliance (eth1=network adapter 2).


If your test are running fine (and not giving errors) it means the backup server was able to reach the machine because it will do a network validation test at one point. I suggest you take a look at the "log" part of a certain VM to double check your are trying to connect to the correct IP address. Just open the statistics window of the surebackup job. Then click the VM you want to test and search for the line something like this (notice my mask is 10.20.1.0)

• 14-5-2014 15:10:50 Results: IP address '10.20.1.31', network '10.20.1.0', mask '255.255.255.0', gateway '172.20.1.80'

Then try to ping/rdp/ssh whatever is open on that VM to contact it on the "resulting ip address". Remember this can only be done from the backup server, or if you manually would push the routes on a pc that is in the same subnet as the production interface of the proxy/nat appliance


If you are looking at static mapping:
For the Isolated IP: use the real IP of the server, not the masqueraded address
For access IP: use an IP that is free in your production environment on the same network as the production address of the proxy/nat appliance

Finally you can also open a support ticket. They can do a remote sessions to take a closer look at your setup.

[pkelly_sts]

Many thanks for your detailed reply, most useful!

I was struggling to understand some of the issues I was having previously and had typed up a longish reply here but, as is often the case, the act of putting my issues in writing actually helped explain the issues to me, most of which it turns out revolves around me having provided a totally incorrect subnet mask for the proxy appliance IP (255.255.240.0 when it should have been 255.255.255.240 - big difference!).

The only oddity I have now is that the VMs in the lab can't seem to ping the isolated IP of the vlab (same IP as default gateway in the production network) but then it's working now anyway so do I need to worry?

Paul.

[tdewin]

Paul,

Like stated above, for me I'm able to ping it so it must be something specific in your scenario. Maybe a not so "default" subnet like a class c 255.255.255.0. I would also expect that a "bigger subnet" mask on the isolated subnet doesn't make a lot of difference unless you have multiple networks (which I understand you don't have). Maybe it could be a test to use just 255.255.255.0 for your isolated adapter (however I calculated your subnet briefly and 13, 4, 5 should be in the same network so it should be correct).