> I am still confused why 6 out of 7 servers in my DMZ (behind 
> a firewall) work as-is, it is just one server that is giving 
> me a headache. I know it is a firewall related issue cause if 
> I turn off the firewall the Amanda dump works fine on all 7 
> servers, but with it on one server fails to connect. I am 
> rebuilding the client first with the --with-tcp* and
> --wint-udp* options to see if this works.
> 
> My Amanda server in on my private LAN connecting in to the DMZ.
> 
> Jay

I think you may be having a problem that we experienced in my company as
well.  I attach below the full diagnosis that I posted on that occasion
- hope it helps.

Michael Brantley
KBC Financial Products UK Ltd.
(Michael.Brantley AT kbcfp DOT com)

- + - + - + - +

Amanda was recently modified for use with packet filtering firewalls and
Tokyo has been making use of this feature.  However, the reliability of
dumps for systems behind the firewall have not been 100%, with a few
dumps each evening failing to complete on a seemingly random basis.

After some debugging effort we have identified the problem.  When amanda
first fires up it forks off a number of "dumper" processes that collect
streams of backup data from the various hosts.  Each dumper binds to a
UDP socket in order to contact the amanda service (managed by inetd) at
port 10080.  In order to assure that the UDP packets from the client to
the server can pass through the firewall, the "dumper" process on the
server attempts to bind to a port within a reserved range (previously
850-859) so that the return packets for that socket can pass through the
corresponding hole in the packet filters.

Unfortunately, efforts to maximize the speed of backups in Tokyo led to
our increasing the number of dumpers being started to 20, a number that
exceeded the number of ports in the reserved range.  The result was that
roughly half of the dumpers started were able to traverse the firewall
while the other half were not.  It was then a matter of "pot luck" as to
which dumper process was scheduled to start a given dump; in practice we
observed that dumps for filesystems on firewalled hosts succeeded if
they were started by dumpers 0-9 and failed if they were started by
dumpers 10-19.  

Having (finally) arrived at the proper diagnosis, the solutions were
simple:

* increase the portrange to exceed the number of dumpers being started
(amanda's inparallel parameter)
* decrease the amanda inparallel parameter to be less than the number of
ports within the port range
* relax the firewall filter to allow UDP ports originating from the
client's port 10080
* rewrite amanda to only employ "reserved" UDP ports when servicing
"firewalled" clients in an effort to conserve them
* employ a different firewall using reflexive access lists

For expediency sake I went with the first option above by doing the
following:

* compiled a new version of amanda using the
"--with-udpportrange=850,875" option to configure
* installed this new version on deputy
* added entries for ports 860-875 in the global services file
* updated the [ firewall configs ]

The Tokyo dumps have just completed successfully, so it seems this has
done the trick.
--
- Michael