The way I usually debug this is by watching what packets the firewall is rejecting from that specific host. Or if that is not possibe simply do a tcpdump host AMANDAHOST on the client host and a tcpdump CLIENTHOST on the server while doing an amtest -c hostname.
That way you can see what is going astray. Dw -- Dirk-Willem van Gulik On Sun, 30 Jun 2002, Jordan Erickson wrote: > I'm sorry if I'm being redundant, but maybe someone can help me with my > problem, I would greately appriciate it. I'm not sure if this message > got out the first time. I really need to backup my web/mail server, I > feel naked without a backup... Thanks! =) > > --------- > > Hi Everyone, > > I'm a new Amanda user, and have been working on it for the past few > days. I have sucessfully gotten it to back up one of my clients from > the same subnet (192.168.0.0/24), which doesn't traverse my firewall. My > firewall has 2 subnets (192.168.0.0 [private network] and 192.168.1.0 > [DMZ]) and an internet connected interface. Basically, the trouble I'm > having right now is getting my backup server talk to my webserver on the > DMZ through my iptables firewall. > > The Amanda FAQ-O-MATIC entry for Amanda and firewalls at > http://amanda.sourceforge.net/cgi-bin/fom?_highlightWords=firewall&file=139 > helps a bit, but it doesn't go into any depth on connection-tracking > firewalls. Basically it just says it should work. I have the following > rules in my nifty firewall to allow traffic to pass back and forth: > > iptables -A internal-dmz -p tcp --dport 10080:10083 -m state --state \ > NEW,RELATED,ESTABLISHED -j ACCEPT > iptables -A internal-dmz -p udp --dport 10080:10083 -m state --state \ > NEW,RELATED,ESTABLISHED -j ACCEPT > > I understand that the client opens up a random UDP port on the server > for communication while the backup process is happening, and I'm pretty > sure that's where it's getting hung up. I added the following to my > firewall to try and get iptables to recognize the connections initiated > from the entries above by putting these entries in below them (they were > actually there before I started using Amanda: > > iptables -A dmz-internal -p tcp -m state --state \ > RELATED,ESTABLISHED -j ACCEPT > iptables -A dmz-internal -p udp -m state --state \ > RELATED,ESTABLISHED -j ACCEPT > > Here's my /tmp/amanda/sendbackup.debug file from the client on the DMZ: > # cat sendbackup.debug > sendbackup: debug 1 pid 19975 ruid 34 euid 34 start time Wed Jun 26 > 13:27:32 2002 > /usr/lib/amanda/sendbackup: got input request: DUMP /var 0 > 1970:1:1:0:0:0 OPTIONS |;bsd-auth;compress-fast; > parsed request as: program `DUMP' disk `/var' lev 0 since > 1970:1:1:0:0:0 opt `|;bsd-auth;compress-fast;' > waiting for connect on 1445, then 1446 > /usr/lib/amanda/sendbackup: timeout on data port 1445 > /usr/lib/amanda/sendbackup: timeout on mesg port 1446 > sendbackup: pid 19976 finish time Wed Jun 26 13:28:32 2002 > > If anyone has any ideas on why this is happening, I would greately > appriciate it. Thanks!! > > > Oh, I'm running the Amanda server on Debian Woody (testing), and the > client on Debian Potato (stable) if that makes any difference. > > Sincerely, > Jordan Erickson > Network Consultant, Logical Networking Solutions > Santa Rosa, CA > > >
