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

Reply via email to