--On Thursday, September 16, 2004 09:59:46 -0400 KEVIN ZEMBOWER <[EMAIL PROTECTED]> wrote:
> Hi, Frank, thanks for your work and efforts to help me with my problem. Please see > my remarks, preceded by "***" (stupid GroupWise email client won't quote correctly), > below. -Kevin > >>>> Frank Smith <[EMAIL PROTECTED]> 09/15/04 07:34PM >>> > --On Wednesday, September 15, 2004 15:28:21 -0400 KEVIN ZEMBOWER <[EMAIL PROTECTED]> > wrote: > >> The discussion's petered out on my request for which ports to ask the firewall >> administrator to open to allow amanda to work through our firewall, but I'm still >> hoping for an answer, as I still can't come up with one myself. There was one >> comment that >> ports 10080-10083 are fixed, no matter what --with-???portrange switches are used. >> Is this fact or fiction? > > I think fact. Those are the ones listed in /etc/services. > > *** I thought that these were set up in /etc/services based on the settings > --with-portrange, --with-tcpportrange and --with-udpportrange, or if they're fixed > and unchangeable. There's no 'amanda' listing in the assigned numbers in RFC 1700 > (http://www.faqs.org/rfcs/rfc1700.html). The ports in /etc/services (and [x]inetd) are the ports Amanda connects to in order to initiate a process, the portranges you used at configure time are used for the source ports and data connections. Regardless of what portrange you specify, Amanda still uses a few ports around 10080, although you may not need all of them for your configuration. >> In the spirit of re-phrasing the question, can anyone help me complete the >> following sentence to my firewall administrator: >> Please open port numbers ____ through ____ for [UDP|TCP|both] packets [from|to] my >> tapehost (inside fw) [to|from] my client(s). >> >> That sentence may have to be completed more than once for each different range, >> protocol or direction. > > Usually, when discusion dies down without a clear answer it means nobody is > really sure of the exact answer, although I think someone gave you a very > good description of the backup process port usage. > > ***Yes, I really appreciate Michael taking the time to try to explain that to me. > Unfortunately, I didn't understand it completely and had some follow-up questions, > which went unanswered. My next attempt will be to look into the files John Jackson > mentions in the port usage document, and see if I can figure out from the source > code what ports are used. I've been putting this off, as I don't know C, but it's > looking like this is the only way to answer the questions I have. Whatever I learn, > I'll > post back here. > > I've got firewall rules that work (for me), but they may be allowing more > than absolutely necessary (i.e., some ports open bidirectionally when they > only need to be open one direction with the 'established allow' rule > covering the response packets). > > In the interest of science (and my own curiosity) I've set up a packet capture > on one of my VPN boxes to log network traffic between one of my tape servers > and a remote client tonight. Since the two servers don't normally talk with > each other except for the backup, tomorrow I should be able to see the exact > sequence of events, and since that client is a very small backup (/etc and > /vaar/spool/cron/crontabs) it shouldn't be a huge mass to wade through. > > I'll let you know tomorrow what I discover. > > *** Thank you so much for offering to do this. I'm anxious to learn what you find > out. OK, here's what I learned from my packet capture. In my setup, /etc/services on the backup client contains: amanda 10080/udp # Amanda backup and on the backup server (with the tape drive): amanda 10080/udp # Amanda backup amandaidx 10082/tcp # Amanda backup amidxtape 10083/tcp # Amanda backup My Amanda was cnfigured with (among other things): --with-tcpportrange=40000,40030 --with-udpportrange=920,940 So the backup runs, and I see the following traffic (de-duped): UDP server.930 > client.10080 UDP client.10080 > server 930 UDP server.939 > client.10080 UDP client.10080 > server 939 TCP server.40004 > client.40020 TCP client.40020 > server.40004 TCP server.40005 > client.40021 TCP client.40021 > server.40005 TCP server.40006 > client.40022 TCP client.40022 > server.40006 UDP server.939 > client.10080 UDP client.10080 > server.939 TCP server.40021 > client.40011 TCP client.40011 > server.40021 TCP server.40026 > client.40012 TCP client.40012 > server.40026 TCP server.40027 > client.40013 TCP client.40013 > server.40027 UDP server.939 > client.10080 UDP client.10080 > server.939 UDP client.10080 > server.939 UDP server.939 > client.10080 TCP server.40012 > client.40015 TCP client.40015 > server.40012 TCP server.40013 > client.40016 TCP client.40016 > server.40013 TCP server.40014 > client.40017 TCP client.40017 > server.40014 All told it was over 24,000 packets. The firewall rules would need to allow the following: UDP: client src port 10080 -> server dst port (udpportrange) server src port (udpportrange -> client dst port 10080 TCP: server src port (tcpportrange) -> client dst port (tcpportrange) If your firewall doesn't automatically pass return traffic from established connections you will also need: client src port (tcpportrange) -> server dst port (tcpportrange) All this is just for backups. To do a remote restore you would also need to allow connections to the server's index (if you use them) and tape ports (udp 10082 and udp 10083, respectively), and if you use a Kerborized Amanda I think you may need tcp 10081. A restore may also need the second tcp rule above since I'm not sure which end initiates the data connection on the restore. If anyone needs the raw tcpdump output of the backup I can send it to you (I just grabbed the headers, so my data isn't in it) if you want to do more detailed analysis. Frank -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
