Thank you to all the folks who have written to me personally and to the list, asking about the problems I'm experiencing using amanda and my organization's firewall. I'm now convinced that the problem is with the firewall, or, more accurately, with the ability of my organization to control and manage the firewall. I don't believe the problem is with amanda at all.
For the curious and those searching the archives, here's a long explanation of my situation and how I've tried to diagnose it. I've compiled amanda 2.4.3b1 on the tapehost with this configure statement: ./configure --with-tcpportrange=10084,10100 --with-udpportrange=932,948 --with-user=amanda --with-group=disk --with-config=DailySet1 --with-portrange=10084,10100 [Question: What does "portrange" affect, that "tcpportrange" and "udpportrange" doesn't?] The same version of amanda was compiled the same way on the clients, with "--without-server" added. In both cases, I used the patch-system script to alter /etc/services and /etc/inetd.conf. Amanda will backup my 5 hosts inside my firewall, but won't backup the three hosts outside. Amcheck outputs this: amanda@admin:~ > amcheck DailySet1 -c Amanda Backup Client Hosts Check -------------------------------- WARNING: external: selfcheck request timed out. Host down? ERROR: www: [host jhuccp.jhuccp.org: port 44937 not secure] Client check: 7 hosts checked in 30.080 seconds, 2 problems found (brought to you by Amanda 2.4.3b1) amanda@admin:~ > (One of my hosts outside the firewall is disabled in disklist at this time.) Note the error warning on host www: port 44937 not secure. External just times out. My host external happens to have ipchains on it; www does not. Ipchains is a firewall in Linux. I've set it up to log all the denys. Here's the entry caused by the amcheck above: Jan 29 12:33:42 external kernel: Packet log: PUB_IN DENY eth1 PROTO=17 162.129.225.189:43821 162.129.225.201:10080 L=173 S=0x00 I=0 F=0x4000 T=64 (#36) Jan 29 12:34:02 external last message repeated 2 times This log entry says that a packet was denied because it came from host 162.129.225.189 (my organization's firewall/gateway) on port 43821 and was directed to host 162.129.225.201 (my amanda client, external, outside the firewall) on port 10080 (the amanda port). This packet was denied because I have ipchains set up to only pass packets in the same ranges used in compiling amanda. To further confirm this. I ran tcpdump simultaneously on host admin (my tapeserver) and external. Here's the output from a trial I ran yesterday. These lines indicate UDP packets from admin (172.16.2.7) port 944 being sent to external (162.129.225.201) on the 'amanda' port (10080): admin:~ # tcpdump -n -vv host admin and external and not port syslog Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on eth0 14:50:54.729796 172.16.2.7.944 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 14:51:04.769796 172.16.2.7.944 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 14:51:14.769796 172.16.2.7.944 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 3 packets received by filter admin:~ # These next lines are from the same program running on external, and represent the same packets. This time, they are received from the firewall (162.129.225.189) on port 44593, instead of port 944, the port on admin from which they were sent. They're targeted to external (162.129.225.201) on the 'amanda' (10080) port. external:~ # tcpdump -n -vv host jhuccp and external and not port \( syslog or ssh or 41909 \) Kernel filter, protocol ALL, datagram packet socket tcpdump: listening on eth1 14:49:22.758761 162.129.225.189.44593 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 14:49:32.789395 162.129.225.189.44593 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 14:49:42.788526 162.129.225.189.44593 > 162.129.225.201.amanda: udp 145 (DF) (ttl 64, id 0) 14:49:55.127563 162.129.225.201.1190 > 162.129.225.189.http: S 2124065507:2124065507(0) win 32120 <mss 1460,sackOK,timestamp 2125952577 0,nop,wscale 0> (DF) (ttl 64, id 15892) 4 packets received by filter external:~ # (Note to the picky: The clock on external is 1:32 slower than that on admin. Also, one httpd packet snuck in there.) I think this shows conclusively that what is going into the firewall on one port is coming out on another one. However, if anyone sees a flaw in my logic, I'd be glad to hear of it. My organization's firewall is the CommandView Firewall version 3.0 from Elron Software. The problem with the system is that, like all GUI interfaces (in my opinion), ease of management by less experienced personnel is achieved by hiding the details of what's actually happening. To open up a range of ports, a form like this is required for each range: Inbound- SrcLower SrcUpper DestLower DestUpper Dir Ack 932 948 1024 65535 In Off 1024 65535 932 948 Out On Outbound- SrcLower SrcUpper DestLower DestUpper Dir Ack 1024 65535 932 948 In On 932 948 1024 65535 Out Off I think what's needed is to make the Source and Destination ports the same in each line. However, when I make this suggestion to the firewall managers, they reply, "A) We tried this and you told us it didn't work, and B) none of the examples in the manual show the Source and Destination ports the same, one set always has the limits of the non-privileged ports, so we won't try it because it couldn't be right." At this time, we're waiting to hear from the tech support folks at Elron to see if they suggest a method. In their manual, they say, "Some applications can't be made to work with the CommandView firewall." I hope this isn't the case here. Thank you all for your interest. If anyone has any suggestions or questions, I'd love to hear them. When this problem gets resolved one way or the other, I'll report back to the list. -Kevin Zembower ----- E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139