Configure Avamar Datastore for the backup of clients in external network - Avamar with NAT

Lets say the customer is using the following ip's (am not quoting your IP's as this makes it easier to explain..)

Host Name                  Actaul IP's                    NAT'd IP's                    Type

Genericname1            xxx.xxx.xxx           xxx.xxx.xxx           utility

Genericname2            xxx.xxx.xxx            xxx.xxx.xxx          node 0.0

Genericname3            xxx.xxx.xxx            xxx.xxx.xxx           node 0.1

The output of probe.xml before the NAT configuration looks as below.

admin@denwarner101:/usr/local/avamar/var/>: nodedb print

To configure probe.xml with NAT

Synatx:

nodedb update if --addr= --new-nat= =

Where

Interface - Actual IP address of the storage node (say node 0.0)

Initial - NAT'd IP of the utility node

Target - NAT'd IP of the corresponding storage node (say node 0.0)

In this above example, issue the below commands to configure NAT

nodedb update if --addr=xxx.xxx.xxx--new-nat=xxx.xxx.xxx=xxx.xxx.xxx

nodedb update if --addr=xxx.xxx.xxx --new-nat=6xxx.xxx.xxxxxx.xxx.xxx

Then the output of probe.xml after the NAT configuration looks as below

admin@genericname1:~/>: nodedb print

Note: There are scenarios seen where the NATTing is setup correctly however, still the job fails connecting to the utility node. There can be few causes:

1. GSAN was not restarted after NATTING was done..

Solution: Restart GSAN (dpnctl stop and then start)

2. Client IP setup might be the wrong one. Ensure that paging has the right IP.  Check Policy - Clients - Edit the client and see if paging is setup right..

Hope the above info helps

I would recommend engaging professional services for setting up NAT if this is a new install. Yes nodedb commands need to be run only on the utility node. These need to be run only for data node IP addresses and spare node IP if any and do take a backup of probe.xml file.

Thanks and Regards,

Sameer Khan

Hello Sameer,

I am currently involved in a project like the one mentioned above.I followed your steps accuratly. Now the "external" clients are able to activate the Avamar agents against the purblic IP of the Avamar, but when they right click on the agent Icon and choose backup or restore the web page tries to connect to the Avamar server's Local IP address. Needles to say the backups are not going through either. After studying the agent log file, I found that the agent keeps trying to connect to the Avamar server but using the Local IP instead of the NAT one.

Can you please advice?

Hi bayoumi,

This forum is exclusively for questions from customers.  I'll send you a message on how best to proceed.

How does this work with clients that might be behind the same firewall as the util & the grid servers?  Seems to me that this is a global setting.

I'm trying to modify our architecture so that we can backup clients outside of our local environment - so I have two NATs (client side & server side). 

Currently, I have the client downloading the software from the server and activating against it.  However, no backups are flowing.  DNS is setup so that the client points to the util servers NAT address and the util points to the clients NAT.  But, no joy.  so, I presume that I'm going to have to do something similar to this -- and the documentation only discusses the Avamar server/storage behind a NAT. 

Running 6.0

Thanks in advance,

Jim

Can this be done with 2 NATted networks?  I have 2 seperate external networks that need to talk to the Avamar grid in a third management network.

Yes this is possible. Please get in touch with professional services to set this up.

Khan, Sameer would like to recall the message, "[Avamar Support Forum] New message: "Configure Avamar Datastore for the backup of clients in external network - Avamar with NAT"".

This post has been edited to remove proprietary information of a private nature. For future reference please edit all posts you are putting together to remove proprietary  / private unique information. It is incumbent upon all Support Community members to ensure we all protect each others private and proprietary information.

Regards,

Mark Browne

EMC Support Community Manager

Silas, you put together a great post but unfortunately someone came along and deleted all the sample IPs. For anyone else who gets stuck, here's the trick.

The logic is that the client will learn the NAT of the utility node when you register the client.  From that point on the client knows that "if I am talking to and I am told to go to , I will go to instead."  The configuration lets you add more than one NAT address for each node and depending on which Utility Node NAT IP you use to register the client, the client then knows which relevant NAT IPs to use.

On the utility node only add these entries:

nodedb update if --addr=   --new-nat= =

nodedb update if --addr=   --new-nat= =

nodedb update if --addr=   --new-nat= =

etc

The wrong thing to do is to follow the pattern from the first line and add

nodedb update if --addr=   --new-nat= = (this is correct)

nodedb update if --addr=   --new-nat= =   (this is wrong)

If you mess up you need to use vi to clean up probe.xml

The 7.0 documentation mentions starting gsan.  Unless you are doing a fresh install of an Avamar node, gsan is already running so don't touch it otherwise you will be waiting a half hour for it to start.  The only thing you need to do after adding the nodedb entries is to run  avmaint networkconfig /usr/local/avamar/var/probe.xml --avamaronly

If the client is not working, run "back up now" and then run netstat -n repeatedly to see what IPs it tries to connect to.  If you see the client trying to connect to the real IPs and not the NAT IPs it mans you have an error and need to check probe.xml.  On the other hand if you see the NAT IP and time_wait you probably have a firewall problem.

Hope this helps,

Olgierd Bilanow