>I have been trying to post a question to the amanda-users lists, but
>there is some screwup with yahoo, and they will not let me post. ...
I'm including [EMAIL PROTECTED] in the Cc list so if anyone else
has a bright idea, maybe they can contact you offline.
Maybe just posting to [EMAIL PROTECTED] would work for you, too?
>I ask you, because you seem to have the best answers to various
>questions on this (which I can read, but not send to).
Don't confuse quantity with quality :-).
>There were messages on list I think in May that addressed this problem,
>but it was not resolved. ...
Yeah, I just reviewed them and didn't really see a good answer, either,
although I was searching by Subject so if a followup came through in a
different thread I may have missed it.
>... We are using NAT.
I know zip about firewalls, so may not be able to help much. You may want
to do some Amanda EGroup searches for "NAT" and "firewall" (see below)
to see if any general issues are covered that happen to also fix your
specific problem.
>bsd security: remote host localhost.proceryon.net ...
This is the first thing that caught my eye. My local network guru is not
around to ask, but I seriously doubt you're ever supposed to get back a
fully qualified name involving "localhost". I'm pretty sure the sequence
of events was amandad got a request from 127.0.0.1, did a gethostbyaddr
on that and got back "localhost.proceryon.net" as the first name.
You might take a look at:
ftp://gandalf.cc.purdue.edu/pub/amanda/gethostby*.c
Those are just trivial command line interfaces to gethostbyname() and
gethostbyaddr(), but they've proven to be very useful tracking down some
types of name/address configuration issues.
>amandad: received dup packet, ACKing it
>...
>amandad: waiting for ack: Connection refused, retrying
The rest of the log implies the server sent the request to the client,
but that the client can't talk back to the sender (server). That's why
the server sent the duplicates (because it never saw the ACK) and why
the client is upset at the server not ACK'ing the REPly.
Here's what's supposed to happen:
* Planner creates a socket bound to any IP address but to a privileged
port.
* It sends a UDP packet to the amandad port on the client using the
above socket.
* Amandad on the client does a recvfrom so it knows who sent the packet.
* It sends UDP packets (e.g. the ACK) back to the same address it got
the initial packet from.
Again, I don't know anything about NAT, but maybe the request from the
server no longer looks like it came from the "correct" port when it gets
to the client and so sending it back goes off in the weeds? Or perhaps
it is trying to go back to the right place but the server has rules
that don't allow connections to whatever arbitrary (but privileged)
UDP port planner picked?
Did you configure Amanda with any port ranges? Did you do both the
client and server the same way?
Is there any chance you could upgrade to 2.4.2p2 (or even the latest CVS
code in the 2.4.2 branch)? Among many other things, it logs a lot more
information about what's going on during the network traffic, such as
the ports and IP addresses involved.
Also, it appears to have support for --with-udpportrange that is not
in 2.4.1p1. You may need that to limit the range of ports chosen so
you can let them through NAT unmolested.
It's not documented (yet), but --with-udpportrange needs values in the
privileged range (< 1024) and --with-portrange (TCP) needs values above
the privileged range (>= 1024).
I looked through my archives of the past couple of months for " NAT "
and came up with a couple of interesting articles. One is appended (Doug
already graciously posted the info in an FAQ item, so I don't think he'll
mind the letter being posted). You might look in the E-mail archives
for Subject "NAT" -- that was the other thread. Maybe they will help.
>Ben
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
=====
Date: Tue, 29 May 2001 11:35:09 MST
To: [EMAIL PROTECTED]
From: Doug Silver <[EMAIL PROTECTED]>
Subject: Amanda/firewall solution!
Hi John -
I'd like to pass along my solution, so perhaps the next poor soul won't
have to go through my frustrations. If you could post this to the FAQ
area I'm sure someone will appreciate it later!
It's actually quite simple, the typical setup for a firewall is to do NAT,
with something like this:
(This is with IP Filter, but I think ipchains should be similar)
map <interface> <IP range> -> <external IP address>
e.g.
map fxp0 192.168.0.0/16 -> 63.123.456.78 portmap tcp/udp 30000:50000
map fxp0 192.168.0.0/16 -> 63.123.456.78
I found that simply putting this line first worked:
map fxp0 <Amanda server IP> -> <external IP>
map fxp0 192.168.10.141/32 -> 63.123.456.78/32
I still compiled with the restrictive udp/tcp portranges and the firewall
be setup to pass those ranges.
-Doug
...
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Doug Silver
619 235-2665
Quantified Systems, Inc
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
