Back up Over NAT with the new version

[efi@zebratech.co.il]

Did any one know if working beind NAT is solve in the new version ?

[wdbarker3]

I'm doing it, but I had to use iptables to hack the return path on the remote side. Details:
REF: 553077
Environment/Scenario:
==================
ESXi and Veeam Server (on real 2K8r2 server) are on the same subnet behind a firewall.
The backup target is a linux appliance out on the WAN.
The backup target is moved to the local network and initial backups are done using Reversed Incremental mode.

Then the appliance is moved offsite on the WAN for nightly backups.

Firewall Rules Needed:
==================
The Backup Target is behind a firewall and needs port 22 forwarded to it, as would be expected.

The local firewall must port forward the ports selected in the target’s Data Transfer Port Range (I chose 2500-2510. This was documented, but was not particularly obvious).

Since the Veeam v5 server publishes its private address instead of its public address,
-- or --
Since the Veeam v5 agent on the target uses the address published by the server instead of using the source IP of the commands,
the traffic from the target to the server is sent out to the wrong IP address.

I added the firewall rule on the target:
iptables –t nat –L OUTPUT –d <veeamserverPrivateIP> -j DNAT –to <veeamserverPublcIP>

However, this will interfere with traffic whenever the appliance is on site, like during a disaster or for the initial load. So, a simple script in rc.local deletes the rule if the appliance is booted on site. The DHCP assignment may not be available at rc.local time, thus the while loop.

#!/bin/bash

# First three octets of the local subnet
# If they match the DHCP supplied address, then the firewall rule is unnecessary
LOCAL=172.16.1

IP3=$(ip addr show dev eth0 | grep 'inet ' | awk '{print $2}' | awk -F'.' '{print $1,$2,$3}' | tr ' ' '.')
while [[ "$IP3" == "" ]];
do
sleep 1
IP3=$(ip addr show dev eth0 | grep 'inet ' | awk '{print $2}' | awk -F'.' '{print $1,$2,$3}' | tr ' ' '.')
done
if [[ "$LOCAL" == "$IP3" ]];
then
/sbin/iptables -t nat -D OUTPUT 1
fi

If this information were available in the doc or in a knowledgebase, the next SMB user to want offsite backups might not have to do nearly so much work. If your Engineers would implement either of my two suggestions to make the firewall hack and script unnecessary, that would help too. The answer “Most people have a VPN to their offsite location” was not particularly satisfying<g>.

Dan Barker, President
Software Projects, Inc.

[efi@zebratech.co.il]

Thanx !

[bsl]

Thanks for your post Dan,

I know 2 months have passed since your post, but I'd like to add my 2 cts to the need for NAT traversal. Your post definitely confirmed what I was experiencing, which was quite unexpected for us.

I must say it strikes me as odd that the remote linux storage server feature, intended for off site backups, would only work through either LAN, VPN or with the outward port forwarding you've done, which is not possible on a many firewalls.

We intended to run multiple sites with their own B&R servers to a 'public' linux target, but we're now stranded on our first tests.

It would be great if Veeam could add the option to tunnel the data transfer ports over the SSH connection, that would solve the NAT traversal and the unencrypted data transfers at the same time! Since SSH normally already supports this, it sounds feasible that the amount of effort to realize this isn't unjustifiable.

Even if we could just set the IP or host to connect to manually, that would at least allow us to do the data transfers, though unencrypted.

Anyway, I really hope Veeam has addressed this in their upcoming version...

With best regards,

Bastian Slikkerveer
Connections IT

[TommyTheKid]

This is a wicked old post, but I was just directed here and it mostly fixes problem. We have our offsite backups at a hosting provider, and don't really want to mess with a VPN. The actual command for the NAT, which needs to be run on the Linux repository server is:

Code: Select all

iptables -t nat -A OUTPUT -d <VEEAM_SERVER_INTERNAL_IP> -j DNAT --to <VEEAM_SERVER_PUBLIC_IP>

while you are doing iptables commands, you also need:

Code: Select all

iptables -A INPUT -p tcp -s <VEEAM_SERVER_PUBLIC_IP> -m state --state NEW -m tcp --dport 2500:5000 -j ACCEPT

... also on "CentOS" or RHEL type distros, you probably want to run

Code: Select all

service iptables save

(which saves that rule to /etc/sysconfig/iptables so that it starts with the system default iptables)