Problems with SureBackup Ping Tests Across VPN

[JoePrecious]

We're trying to run SureBackup verification on our replicated VPNs which are offsite over a VPN. We have Cisco ASA firewalls at both sites.

The ping tests are failing and I think it is something to do with NAT of the firewalls - so not really a Veeam issue but hoping someone has a similar setup and has managed to resolve the issue.

I can ping the Virtual_Lab appliance when it is running over the VPN fine, and if I use static mappings in the Virtual Lab I can ping the VMs on those addresses as well. However, I can't ping using the masquerade network so all of the ping tests (and other tests apart from the heartbeat) fail.

I've added the masquerade network to the cryptomaps on the VPN and also added NAT exemption rules. I've also added a route on the default gateway of the network with Veeam installed to route all traffic destined for the masquerade network to the IP address of the Virtual_Lab appliance.

However, on the remote firewall I get the following errors:-

Asymmetric NAT rules matched for forward and reverse flows; Connection for icmp src outside:192.168.1.15 dst outside:192.168.251.15 (type 8, code 0) denied due to NAT reverse path failure

I've raised this withe Cisco as well, but hoping someone here may be able to advise.

Thanks!

[Naim]

can you perhaps do a quick diagram (even with paint is fine) and explain the issue with that? thanks

[JoePrecious]

Does the following help:



I think the routing on the 192.168.1.1 firewall is working as the error in the logs is on the remote end of the VPN so packets are getting sent down the VPN, just not getting back.

Thanks

[nefes]

May I offer you slightly different setup?
You could have VBR server on the right side (Orange one), and perform replicas and surebackup from it.
Thus you are achieving two goals: first, your replicas can perform failover even if the whole "Blue" site is totally down. Second, your surebackup job will work locally in "Orange" site and you will not need to build complex routing rules to make it work.

[JoePrecious]

That's an interested suggestion, but may not work. We also to local backups to a local SMB share of the servers in the live blue site - could these be managed from a B&R server in the replication site? If not, does the license allow us to install two instances of B&R - one for backup and one for replication?

If we did move the B&R server to the replication site, presumably we could set up the jobs to make use of the replicas already there, and wouldn't have to start replication from scratch?

[nefes]

You could have 2 VBR servers - one on live site, handling backups and granular restores from it, another on replication site, handling replicas, failovers and surebackups.
VBR is licensed per source hosts, and you can use as much VBR servers, as you want, as far as your total number of hosts, that contains protected VMs, does not exceed your licensed number.

As for moving VBR and re-using existing replicas, there is functionality for it, called replica mapping. Just don't remember to disable old jobs before starting new ones.

[alanbolte]

Although you certainly could have two VBR servers, I don't see a need for it in the current version (compared to just having it in the DR site). There were reasons to do that in older versions, but a number of minor features and improvements have greatly improved our ability to run offsite jobs. On the other hand, if you're also running Surebackup in the blue site for the local backups, then having separate VBR servers would be needed to work around your current firewall problem.

The component you're looking for to manage backups to SMB share in the blue site (from a VBR server in the orange site) is called a Gateway server, and it's specified in the repository settings.

As to the firewall, I don't know your hardware, but from the text of the error message I'd assume there's something you need to explicitly allow for one of those addresses.

[unsichtbarre]

I say this only because I have made the mistake many times myself: Is ICMP allowed both directions? ICMP is completely different from TCP/UDP. Most things will work if TCP/UDP is allowed, but ping will not.