> 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. ([EMAIL PROTECTED]) - + - + - + - + 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
