-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "KEVIN" == KEVIN ZEMBOWER <[EMAIL PROTECTED]> writes:
KEVIN> For the curious and those searching the archives, here's a long
KEVIN> explanation of my situation and how I've tried to diagnose it.
KEVIN> I've compiled amanda 2.4.3b1 on the tapehost with this configure
KEVIN> statement: ./configure --with-tcpportrange=10084,10100
KEVIN> --with-udpportrange=932,948 --with-user=amanda --with-group=disk
KEVIN> --with-config=DailySet1 --with-portrange=10084,10100
KEVIN> [Question: What does "portrange" affect, that "tcpportrange" and
KEVIN> "udpportrange" doesn't?]
My understanding is that "portrange" is simply historic. Or does it
affect the source port?
Also, specifying ranges on the server won't affect what ports are chosen
by the client.
KEVIN> (brought to you by Amanda 2.4.3b1) amanda@admin:~ > (One of my
KEVIN> hosts outside the firewall is disabled in disklist at this time.)
KEVIN> Note the error warning on host www: port 44937 not
KEVIN> secure. External just times out.
Yeah, one problem is that to be considered "secure", the request has to
originate on a "trusted" port (<1024). The firewall/NAT is translating the
port number.
KEVIN> My host external happens to have ipchains on it; www does
KEVIN> not. Ipchains is a firewall in Linux. I've set it up to log all
KEVIN> the denys. Here's the entry caused by the amcheck above: Jan 29
KEVIN> 12:33:42 external kernel: Packet log: PUB_IN DENY eth1 PROTO=17
KEVIN> 162.129.225.189:43821 162.129.225.201:10080 L=173 S=0x00 I=0
KEVIN> F=0x4000 T=64 (#36) Jan 29 12:34:02 external last message repeated
KEVIN> 2 times
KEVIN> This log entry says that a packet was denied because it came from
KEVIN> host 162.129.225.189 (my organization's firewall/gateway) on port
KEVIN> 43821 and was directed to host 162.129.225.201 (my amanda client,
KEVIN> external, outside the firewall) on port 10080 (the amanda
KEVIN> port). This packet was denied because I have ipchains set up to
KEVIN> only pass packets in the same ranges used in compiling amanda.
Well, the firewall is a NAPT box.
KEVIN> I think what's needed is to make the Source and Destination ports
KEVIN> the same in each line. However, when I make this suggestion to the
KEVIN> firewall managers, they reply, "A) We tried this and you told us
KEVIN> it didn't work, and B) none of the examples in the manual show the
KEVIN> Source and Destination ports the same, one set always has the
KEVIN> limits of the non-privileged ports, so we won't try it because it
KEVIN> couldn't be right."
Well, try it again, and do the tcpdump/DENY log again.
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPFcMvoqHRg3pndX9AQE+egP/ZBO1ZhFIAkZLl2euXYkOMr3IRzLeeMlr
063Txe+3RCvFV5a5A++6xdt1nDtwLAfb1AjDVw9lEVu6/8HdQDi4P97+yKGDIknt
VUDFsEm20GCvfTbMsxepq+mhIr5WfS90eqqP0yquY6PcMQdOZCmqJ4BiEjVNeMez
u2S9YqdubcE=
=TiKL
-----END PGP SIGNATURE-----
