Comprehensive data protection for all workloads
Post Reply
efi@zebratech.co.il
Lurker
Posts: 2
Liked: never
Joined: Feb 03, 2011 2:27 pm
Full Name: Efi Mendelson
Contact:

Back up Over NAT with the new version

Post by efi@zebratech.co.il »

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

wdbarker3
Novice
Posts: 8
Liked: never
Joined: Jan 28, 2011 11:48 pm
Full Name: Dan Barker
Contact:

Re: Back up Over NAT with the new version

Post by 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
Lurker
Posts: 2
Liked: never
Joined: Feb 03, 2011 2:27 pm
Full Name: Efi Mendelson
Contact:

Re: Back up Over NAT with the new version

Post by efi@zebratech.co.il »

Thanx !

bsl
Lurker
Posts: 1
Liked: never
Joined: Apr 22, 2011 2:18 pm
Full Name: Bastian Slikkerveer
Contact:

Re: Back up Over NAT with the new version

Post by 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
Novice
Posts: 9
Liked: never
Joined: Feb 28, 2012 7:39 am
Full Name: Tommy McNeely
Location: Broomfield, CO, USA
Contact:

Re: Back up Over NAT with the new version

Post by 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)

Post Reply

Who is online

Users browsing this forum: No registered users and 44 guests