Target WAN Accel tries to directly access NAS in source Site

[stevenrodenburg1]

Hello,

I want to set up the following v9 environment (100% virtualized):
Source Site A
- Veeam Backup master Server VM
- Backup proxies VM's
- Source WAN Accelerator VM
- All these VM's have two NIC's. One in the main/normal LAN (192.168.10.0), the second in the VLAN where the NAS is (192.168.60)
- The 192.168.60.0 network is hard set as the preferred network for backup & replication traffic
- Synology NAS (physical) exists only in 192.168.60.0 network but all above hosts access it through their second NIC and this has worked fine for years.

Target Site B (other GEO area, 40 Mbit effective bandwidth)
- Target WAN Accelerator + Target Repository on same, large VM with IP in Site B's network, 172.16.1.0

Both sites are connected through a Site2site VPN. 192.168.10.0 and 172.16.1.0 networks can reach each other.

I started the very first copy-job I just created: Repo = Target Repo in Site B with Job-params: "Source WAN Accel = WAN Accel in Site A" and "Target WAN Accel = WAN Accel in Site B".

I was assuming that ALL communications to Site B are ONLY done by the two WAN Accelerators. The job however fails with the message "06.05.2016 21:47:11 :: Error: Failed to connect to the port [syno01-vlan60.domain.tld:2500]" (anonymized the domain name)

So i start to ask " **Who** cannot talk to the NAS on port 2500" ??
All hosts in Site A, incl. the WAN Accell. there, have that second NIC to access the .60 ip-storage network where the NAS lives.

I then looked in the firewall / VPN logs on both sides and I see that the remote host with the target Repo and WAN Accel on it, is the one that tries to connect with the NAS in Site A (which ofcourse it well never be able to).

Why does the target host in Site B try to connect directly with the NAS in Site A? Why does the traffic not go completely via the two WAN Accelerators?

The design in had in my head only envisioned the WAN Accelerators talking to each other. Ever.

Code: Select all

Site A                                          Site B
192.168.60.x     192.168.10.x                   172.16.1.x
NAS ------------ Source WAN Accell  <---------> Target WAN Accell --- Target Repository (together in same VM)

But what happens, what it tries to do, according to the firewall-logs, is this:

Code: Select all

Site A                                          Site B
192.168.60.x     192.168.10.x                   172.16.1.x
NAS ------------ Source WAN Accell              Target WAN Accell --- Target Repository (together in same VM)
 ^                                                /
  \----------<------------<-----------<----------/

Have i configured something wrong ?
I cannot change the Site A design and move the NAS into the 192.168.10.0 Network (I will be shot).

[stevenrodenburg1]

I've been going over the manual again. The way it is written was a bit vague to me at first, but now that I see this behaviour in our environment, it appears that it works like that by design.

Which is a problem.

Is it not possible to let the source wan-accell. collect the data from the source repo. and send it to the other side?
It would result in "only the two accellerators ever talking to each other", allowing it to work in environments where the storage is in an isolated network (like we have and which is a security best-practice as well).

Any comments? Can Veeam be reconfigured like this?
I read that with CIFS shares, it works like that but that Linux (Syno) and Windows repo's, they connect directly (which, again, is bad for us).

[foggy]

Steven, how is the target repo added to Veeam B&R, CIFS share? Do you have a gateway server that is located in the target site specified in the repository settings?

[stevenrodenburg1]

Hi Alexander,

Source Repo type = Linux Server
Target Repo type = Windows Server (vPower NFS not installed)

I do not understand your second question "Do you have a gateway server that is located in the target site specified in the repository settings?"
What is a "gateway" in this context ? I cannot find such an option in the GUI when i edit the target repo object.

I created a Windows server object and used it for the target repo role, as well as the target WAN accell. role.

Traffic goes trough a VPN tunnel which is an open tunnel between the 192.168.10.0/24 (Source site A) and 172.16.1.0/24 (target site B) networks.

[foggy]

Scratch that, I misread the setup. In case the target repo is a Windows server, it shouldn't connect to the source NAS at all, so I'd contact support for a closer look at your setup.

[stevenrodenburg1]

"In case the target repo is a Windows server, it shouldn't connect to the source NAS at all"

Are you sure?. The v9 documentation says this:

Chapter:
"User Guide for VMware vSphere > Overview > Backup Copy > Backup Copying Process > Data Transport Path"

"Through built-in WAN accelerators:
Veeam Backup & Replication transports data through a pair of WAN accelerators: one deployed on the source side and the other one deployed on the target side. WAN accelerators remove redundant blocks before transferring VM data and thus significantly reduce the amount of traffic going over the network. This type of data transport is recommended for copying backups offsite over slow connections or WAN.
When Veeam Backup & Replication transports VM data via WAN accelerators, it uses Veeam Data Mover Services on the following backup infrastructure components:

In case of Microsoft Windows and Linux repositories: Veeam Backup & Replication uses the source Veeam Data Mover Service on the source backup repository and target Veeam Data Mover Service on the target backup repository."

which is what i referred to when i wrote "I've been going over the manual again. The way it is written was a bit vague to me at first, but now that I see this behaviour in our environment, it appears that it works like that by design."

[foggy]

Not sure how the quoted conflicts with my post. In case of WAN accelerated backup copy, the data flow is exactly as you've assumed in your initial post: source repo (source data mover) - source WAN - target WAN - target repo (target data mover).

[stevenrodenburg1]

"the data flow is exactly as you've assumed in your initial post"

Except that it doesn't. It works exactly like is described in the manual: The IP address of the target Windows VM (with both roles installed) talks directly to the IP of the NAS.

But I need it to work like you just described

Using Netstat on the Target WanAccell VM: I see that:

Process "VeeamTransportSvc.exe" (on target wan.acc) has connections open to the Veeam Master server in Site A
Process "VeeamAgent.exe" (on target wan.acc) has connections open to the Veeam Master server in Site A
Process "VeeamWanSvc.exe" (on target wan.acc) has connections open to the source wan.acc VM in Site A
Process "VeeamAgent.exe" (on target wan.acc) has connections open to the NAS in Site A

VeeamAgent.exe is the Datamover right?

[foggy]

Yes, it is the actual data processor, VeeamTransportSvc is the management service. I'd said the observed behavior is not expected, so setup verification by our engineers is required.

[stevenrodenburg1]

Ok.

In the meanwhile, I tricked the target wan.acc. by nat'ting the NAS management interface (which is in a routable subnet). I gave it a natted IP in the 192.168.10.0 network so that the target can talk to it. On the target I used a hosts file entry to overrule and thus fake the actual hostname to the natted IP.
Data is flowing as i type this

Sometimes i'm so clever, i scare myself