Re: Amanda through translated addresses
I haven't been paying attention to this whole thread, but thought I'd throw my two cents in. I was never able to get amanda to work through a firewall using NAT. The way NAT works in the Elron Commander firewall, and most other ones, I think, is by arbitrarily reassigning port numbers to keep track of which connection on the inside corresponds to which communication on the outside. Example: Amanda on host tapehost talks to host X from port 932/UDP (I'm making this up from my setup). Host X responds correctly, because it was addressed from the proper privileged (1024) port. Now, amanda on host tapehost wants to talk to host X from port 932/UDP, but the request gets sent to the firewall. The firewall assigns a random port, in the unprivileged range (1024), let's say 10080. It records in it's lookup table that packets from tapehost are assigned to port 10800. In most applications, this would be fine, as the recipient would send the packets back to the firewall at port 10080, and the firewall would match port 10080 with tapehost and send the packet in to it. However, with amanda, when host X gets the packet from port 10080, it rejects it with an error message like Unprivileged port To diagnosis this, I used a combination of netcat and tcpdump, on both the sender and recipient. I was never able to overcome this, because the Elron firewall software can't not translate the port, as far as I and our Information Services group could tell. Since the original poster didn't mention this error message at all, this explanation may not relate to his problem. Sorry if this doesn't apply. If it does, and you have further questions, please write. -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
Re: Amanda through translated addresses
I haven't been paying attention to this whole thread, but thought I'd throw my two cents in. I was never able to get amanda to work through a firewall using NAT. The way NAT works in the Elron Commander firewall, and most other ones, I think, is by arbitrarily reassigning port numbers to keep track of which connection on the inside corresponds to which communication on the outside. Example: Amanda on host tapehost talks to host X from port 932/UDP (I'm making this up from my setup). Host X responds correctly, because it was addressed from the proper privileged (1024) port. Now, amanda on host tapehost wants to talk to host X from port 932/UDP, but the request gets sent to the firewall. The firewall assigns a random port, in the unprivileged range (1024), let's say 10080. It records in it's lookup table that packets from tapehost are assigned to port 10800. In most applications, this would be fine, as the recipient would send the packets back to the firewall at port 10080, and the firewall would match port 10080 with tapehost and send the packet in to it. However, with amanda, when host X gets the packet from port 10080, it rejects it with an error message like Unprivileged port To diagnosis this, I used a combination of netcat and tcpdump, on both the sender and recipient. I was never able to overcome this, because the Elron firewall software can't not translate the port, as far as I and our Information Services group could tell. Since the original poster didn't mention this error message at all, this explanation may not relate to his problem. Sorry if this doesn't apply. If it does, and you have further questions, please write. -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
Re: Amanda through translated addresses
yes, i solved this by patching this file security.c
it's a dirty hack, but in my setup it doesn't worry me...
*** security.c Mon Dec 4 22:45:01 2000
--- ../../amanda-2.4.2p2-patched/common-src/security.c Thu Mar 14
18:58:51 2002
***
*** 227,233
/* next, make sure the remote port is a reserved one */
! if(ntohs(addr-sin_port) = IPPORT_RESERVED) {
ap_snprintf(number, sizeof(number), %d,
ntohs(addr-sin_port));
*errstr = vstralloc([,
host , remotehost, : ,
--- 227,233
/* next, make sure the remote port is a reserved one */
! /*if(ntohs(addr-sin_port) = IPPORT_RESERVED) {
ap_snprintf(number, sizeof(number), %d,
ntohs(addr-sin_port));
*errstr = vstralloc([,
host , remotehost, : ,
***
*** 235,241
], NULL);
amfree(remotehost);
return 0;
! }
/* extract the remote user name from the message */
--- 235,241
], NULL);
amfree(remotehost);
return 0;
! } */
/* extract the remote user name from the message */
On Wed, 2002-03-20 at 15:23, KEVIN ZEMBOWER wrote:
I haven't been paying attention to this whole thread, but thought I'd
throw my two cents in.
I was never able to get amanda to work through a firewall using NAT.
The way NAT works in the Elron Commander firewall, and most other ones,
I think, is by arbitrarily reassigning port numbers to keep track of
which connection on the inside corresponds to which communication on the
outside.
Example:
Amanda on host tapehost talks to host X from port 932/UDP (I'm making
this up from my setup). Host X responds correctly, because it was
addressed from the proper privileged (1024) port.
Now, amanda on host tapehost wants to talk to host X from port 932/UDP,
but the request gets sent to the firewall. The firewall assigns a random
port, in the unprivileged range (1024), let's say 10080. It records in
it's lookup table that packets from tapehost are assigned to port 10800.
In most applications, this would be fine, as the recipient would send
the packets back to the firewall at port 10080, and the firewall would
match port 10080 with tapehost and send the packet in to it. However,
with amanda, when host X gets the packet from port 10080, it rejects it
with an error message like Unprivileged port
To diagnosis this, I used a combination of netcat and tcpdump, on both
the sender and recipient.
I was never able to overcome this, because the Elron firewall software
can't not translate the port, as far as I and our Information Services
group could tell.
Since the original poster didn't mention this error message at all,
this explanation may not relate to his problem.
Sorry if this doesn't apply. If it does, and you have further
questions, please write.
-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
--
este email foi escrito ao som de:
%s
Re: Amanda through translated addresses
Well, in my situation I just compiled Amanda to use a restricted portrange for both the tcp and udp connections and setup the firewall with a special NAT rule to pass packets from the amanda server to our clients unchanged. I can't help you with the Elron Commander because I'm not familiar with that; I'm using IP Filter. IP Filter typically does the same NAT portmap translation, but by preceding the rules with this one prevents the amanda packets from being changed. Obviously your environment will probably dictate what you can and can't do in regards to your firewall rules. good luck. ;| -- ~ Doug Silver Network Manager Quantified Systems, Inc ~ On 20 Mar 2002, Pedro Caria wrote: yes, i solved this by patching this file security.c it's a dirty hack, but in my setup it doesn't worry me... [snip] On Wed, 2002-03-20 at 15:23, KEVIN ZEMBOWER wrote: I haven't been paying attention to this whole thread, but thought I'd throw my two cents in. I was never able to get amanda to work through a firewall using NAT. The way NAT works in the Elron Commander firewall, and most other ones, I think, is by arbitrarily reassigning port numbers to keep track of which connection on the inside corresponds to which communication on the outside. Example: Amanda on host tapehost talks to host X from port 932/UDP (I'm making this up from my setup). Host X responds correctly, because it was addressed from the proper privileged (1024) port. Now, amanda on host tapehost wants to talk to host X from port 932/UDP, but the request gets sent to the firewall. The firewall assigns a random port, in the unprivileged range (1024), let's say 10080. It records in it's lookup table that packets from tapehost are assigned to port 10800. In most applications, this would be fine, as the recipient would send the packets back to the firewall at port 10080, and the firewall would match port 10080 with tapehost and send the packet in to it. However, with amanda, when host X gets the packet from port 10080, it rejects it with an error message like Unprivileged port To diagnosis this, I used a combination of netcat and tcpdump, on both the sender and recipient. I was never able to overcome this, because the Elron firewall software can't not translate the port, as far as I and our Information Services group could tell. Since the original poster didn't mention this error message at all, this explanation may not relate to his problem. Sorry if this doesn't apply. If it does, and you have further questions, please write. -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
Re: Amanda through translated addresses
Ok, if you run this: nslookup `hostname` on the amanda server, does that resolve? ... That may not be relevant. Amanda does not use DNS (directly). All it does is call gethostbyname(), which is a standard system call that does the right thing, depending on how you have configured your system. For instance, on my Solaris boxes, I set up /etc/nsswitch.conf to look to DNS first and then fall back on /etc/hosts (there are numerous other combinations). Running nslookup only tests DNS. If gethostbyname() isn't also using DNS, this isn't telling you anything. This is why I spent all of five minutes one day writing command line versions of the three standard calls Amanda makes (I'm thinking of tossing these into the Amanda release): ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyaddr.c ftp://gandalf.cc.purdue.edu/pub/amanda/gethostbyname.c ftp://gandalf.cc.purdue.edu/pub/amanda/getservbyname.c Compile these up (may take a little tweaking, depending on your OS) and then: * On the server, use gethostbyname on the client name from the disklist. Do you get back the IP you expect? * Go to the client and run gethostbyaddr on the IP you *think* the server is presenting itself as. * Then run gethostbyname on the client result, on the client, and make sure you get back the IP you started with. In the special case of the server not being able to back itself up, that sounds more like a problem setting up amandad. There are a couple of articles in the FAQ about this. Finally, I wrote up how Amanda uses ports in docs/PORT.USAGE (it was also posted here quite a while ago). If you don't have the file, grab a copy of the 2.4.3 beta test just to get it. Or ask me offline and I'll send it to you. It's not all that great a debugging paper, but does faithfully (I hope) describe exactly how Amanda does its port allocation, and maybe that will trigger an idea. Doug Silver John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Amanda through translated addresses
We tried it both ways. The backup server actually refers to another machine on the NAT range for its DNS, so when it pings the names of the machines with NAT addresses, it will get responses from their NAT IPs. We also added them manually to the /etc/hosts file on the backup server to point to their NAT addresses just to avoid confusion. That made no difference. Then we changed the disklist file to point to the internal machines by their NAT addresses, which also made no difference. What else could be causing it? All the machines with translated addresses are reporting selfcheck request timed out. Host down? Including the backup server itself when running amcheck. What are we not seeing here? --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Mon, 18 Mar 2002, John Koenig wrote: Do your names refer to external (public) IP addresses while your machines behind the NAT actually have internal (private) IP addresses?
Re: Amanda through translated addresses
If the server can't back up itself, I'd start there. I just checked on my system and IP's seem to work, at least with amcheck, so perhaps that will solve your problem. If you used the FBSD port (/usr/ports) system on your server to build Amanda, I think it automatically required FQDN for the hosts. Check the debug files on the server to confirm what amandad reports for the defaults. I use FQDN for all machines, but that's just me ;) ~ Doug Silver Network Manager Quantified Systems, Inc ~ On Mon, 18 Mar 2002, Lee Parsons wrote: Can I use IP addresses in the disklist files rather than the FQDNs? If I could do that then I wouldn't have to worry about DNS to begin with. I haven't seen anything explicitly say we can or cannot but every disklist file I've seen always has the FQDN. Although the other thing I notice i that I can ping the NAT servers from the amanda server by their names without a problem. I'll try IPs in the disklist file and see what happens. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Mon, 18 Mar 2002, Doug Silver wrote: On Mon, 18 Mar 2002, Lee Parsons wrote: We began using NAT addresses on our network a few months ago, but at first we kept all of our systems that were backed up by amanda outside the NAT range. As time moved on we started bringing some of them inside, and it seemed that the easiest way to get both the inside (translated) and outside (nontranslated) addresses would be to build an amanda server and place it inside. After building a system with FreeBSD 4.5 and amanda, we found that it was able to connect to the machines outside, but none of the machines inside, including itself. Is there something we missed? We enabled the operator accounts on all the systems, we used inetd to start amanadad as operator on all the systems, and added the UDP and the two TCP ports into /etc/services. But yet we still cannot get the new amanda server to get anything inside, including itself. When we run amcheck it reports all the systems inside to be host down?. Any ideas would be much appreciated. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com I would check your DNS settings (and /etc/resolv.conf) and if they correspond to what you have listed in your disklist file. If the amanda server has a problem with the user it will complain about that in particular (i.e. root/operator/etc). In your case, start with one machine and get that one working -- it's probably the same problem everywhere. Perhaps you aren't using the correct FQDN? Debug files will be in /tmp/amanda.
Re: Amanda through translated addresses
Our NAT addresses are class C (192.168.0.xxx). The Amanda server resides at 192.168.0.18. It is unable to back itself up. We have a DNS server set up for the NAT addresses at 192.168.0.10 that is referred to in /etc/resolv.conf as the only DNS server for the Amanda server. However the Amanda server has no difficulties with the machines on the public IPs when it runs amcheck. We also tried to put the IP addresses of the internal machines into the disklist file, and it made no difference. Still the host timeout. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Perhaps a bit more detail would let us figure out the problem. For example, here's my setup: Amanda server: 172.16.20.140 (private IP) it's resolv.conf allows it to resolve both internal and external names since I have an internal DNS machine. I back up a bunch of private IP's (172.10.x) and external (public IPs). Do you have an internal dns server that the amanda server can use to resolve all IPs? I'm not sure if Amanda would use /etc/hosts to resolve IP/names, so that might be a cause too. When you said you tried pointing to the internal machines by their NAT addresses, don't you mean the external machines? Regardless, on the server, recheck inetd, HUP it, and run 'amcheck -c CONFIG'. There should be some sort of /tmp/amanda debug files available. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Amanda through translated addresses
Ok, if you run this: nslookup `hostname` on the amanda server, does that resolve? In the resolv.conf file, are there 'domain' and 'search' entries? You can ping all the internal machines, correct? What about some other service like ssh? As a last resort, you could run tcpdump while running amcheck to one or two clients to see what the packets actually look like. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~ On Tue, 19 Mar 2002, Lee Parsons wrote: Our NAT addresses are class C (192.168.0.xxx). The Amanda server resides at 192.168.0.18. It is unable to back itself up. We have a DNS server set up for the NAT addresses at 192.168.0.10 that is referred to in /etc/resolv.conf as the only DNS server for the Amanda server. However the Amanda server has no difficulties with the machines on the public IPs when it runs amcheck. We also tried to put the IP addresses of the internal machines into the disklist file, and it made no difference. Still the host timeout. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Perhaps a bit more detail would let us figure out the problem. For example, here's my setup: Amanda server: 172.16.20.140 (private IP) it's resolv.conf allows it to resolve both internal and external names since I have an internal DNS machine. I back up a bunch of private IP's (172.10.x) and external (public IPs). Do you have an internal dns server that the amanda server can use to resolve all IPs? I'm not sure if Amanda would use /etc/hosts to resolve IP/names, so that might be a cause too. When you said you tried pointing to the internal machines by their NAT addresses, don't you mean the external machines? Regardless, on the server, recheck inetd, HUP it, and run 'amcheck -c CONFIG'. There should be some sort of /tmp/amanda debug files available. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Amanda through translated addresses
Yes. We can run nslookup from the amanda server on the hostnames of any of the machines with NAT addresses we want it to backup and they resolve to the proper NAT addresses. The file /etc/resolv.conf has a domain and a nameserver entry, no search entry, unless thats a synonymous term with nameserver. Ping and ssh work fine from the amanda server to other internal machines. Whats the proper syntax for running tcpdump on amcheck? Thats not something that I often need to run. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Ok, if you run this: nslookup `hostname` on the amanda server, does that resolve? In the resolv.conf file, are there 'domain' and 'search' entries? You can ping all the internal machines, correct? What about some other service like ssh? As a last resort, you could run tcpdump while running amcheck to one or two clients to see what the packets actually look like. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~ On Tue, 19 Mar 2002, Lee Parsons wrote: Our NAT addresses are class C (192.168.0.xxx). The Amanda server resides at 192.168.0.18. It is unable to back itself up. We have a DNS server set up for the NAT addresses at 192.168.0.10 that is referred to in /etc/resolv.conf as the only DNS server for the Amanda server. However the Amanda server has no difficulties with the machines on the public IPs when it runs amcheck. We also tried to put the IP addresses of the internal machines into the disklist file, and it made no difference. Still the host timeout. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Perhaps a bit more detail would let us figure out the problem. For example, here's my setup: Amanda server: 172.16.20.140 (private IP) it's resolv.conf allows it to resolve both internal and external names since I have an internal DNS machine. I back up a bunch of private IP's (172.10.x) and external (public IPs). Do you have an internal dns server that the amanda server can use to resolve all IPs? I'm not sure if Amanda would use /etc/hosts to resolve IP/names, so that might be a cause too. When you said you tried pointing to the internal machines by their NAT addresses, don't you mean the external machines? Regardless, on the server, recheck inetd, HUP it, and run 'amcheck -c CONFIG'. There should be some sort of /tmp/amanda debug files available. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Amanda through translated addresses
If, for example, you setup your internal machines to have domains like 'host.private.daily.umn.edu', you would want your resolv.conf to look like this: domain private.daily.umn.edu search private.daily.umn.edu daily.umn.edu nameserver x It all depends how you've setup your internal DNS, since there are a 1000 different ways to do it. And even more opinions as to their correctness. As for tcpdump, I would read the man page, but probably something like this: tcpdump -i interface -l -n udp | tee tcpdump.output that way you can see the output and also go back to view the file later if you're seeing a ton of udp traffic. If you comment out all entries except the server in the disklist (just to narrow your focus), are you getting anything in /tmp/amanda? -doug On Tue, 19 Mar 2002, Lee Parsons wrote: Yes. We can run nslookup from the amanda server on the hostnames of any of the machines with NAT addresses we want it to backup and they resolve to the proper NAT addresses. The file /etc/resolv.conf has a domain and a nameserver entry, no search entry, unless thats a synonymous term with nameserver. Ping and ssh work fine from the amanda server to other internal machines. Whats the proper syntax for running tcpdump on amcheck? Thats not something that I often need to run. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Ok, if you run this: nslookup `hostname` on the amanda server, does that resolve? In the resolv.conf file, are there 'domain' and 'search' entries? You can ping all the internal machines, correct? What about some other service like ssh? As a last resort, you could run tcpdump while running amcheck to one or two clients to see what the packets actually look like. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~ On Tue, 19 Mar 2002, Lee Parsons wrote: Our NAT addresses are class C (192.168.0.xxx). The Amanda server resides at 192.168.0.18. It is unable to back itself up. We have a DNS server set up for the NAT addresses at 192.168.0.10 that is referred to in /etc/resolv.conf as the only DNS server for the Amanda server. However the Amanda server has no difficulties with the machines on the public IPs when it runs amcheck. We also tried to put the IP addresses of the internal machines into the disklist file, and it made no difference. Still the host timeout. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Tue, 19 Mar 2002, Doug Silver wrote: Perhaps a bit more detail would let us figure out the problem. For example, here's my setup: Amanda server: 172.16.20.140 (private IP) it's resolv.conf allows it to resolve both internal and external names since I have an internal DNS machine. I back up a bunch of private IP's (172.10.x) and external (public IPs). Do you have an internal dns server that the amanda server can use to resolve all IPs? I'm not sure if Amanda would use /etc/hosts to resolve IP/names, so that might be a cause too. When you said you tried pointing to the internal machines by their NAT addresses, don't you mean the external machines? Regardless, on the server, recheck inetd, HUP it, and run 'amcheck -c CONFIG'. There should be some sort of /tmp/amanda debug files available. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Amanda through translated addresses
On Mon, 18 Mar 2002, Lee Parsons wrote: We began using NAT addresses on our network a few months ago, but at first we kept all of our systems that were backed up by amanda outside the NAT range. As time moved on we started bringing some of them inside, and it seemed that the easiest way to get both the inside (translated) and outside (nontranslated) addresses would be to build an amanda server and place it inside. After building a system with FreeBSD 4.5 and amanda, we found that it was able to connect to the machines outside, but none of the machines inside, including itself. Is there something we missed? We enabled the operator accounts on all the systems, we used inetd to start amanadad as operator on all the systems, and added the UDP and the two TCP ports into /etc/services. But yet we still cannot get the new amanda server to get anything inside, including itself. When we run amcheck it reports all the systems inside to be host down?. Any ideas would be much appreciated. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com I would check your DNS settings (and /etc/resolv.conf) and if they correspond to what you have listed in your disklist file. If the amanda server has a problem with the user it will complain about that in particular (i.e. root/operator/etc). In your case, start with one machine and get that one working -- it's probably the same problem everywhere. Perhaps you aren't using the correct FQDN? Debug files will be in /tmp/amanda. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
Re: Amanda through translated addresses
Can I use IP addresses in the disklist files rather than the FQDNs? If I could do that then I wouldn't have to worry about DNS to begin with. I haven't seen anything explicitly say we can or cannot but every disklist file I've seen always has the FQDN. Although the other thing I notice i that I can ping the NAT servers from teh amanda server by their naems without a problem. I'll try IPs in the disklist file and see what happens. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com On Mon, 18 Mar 2002, Doug Silver wrote: On Mon, 18 Mar 2002, Lee Parsons wrote: We began using NAT addresses on our network a few months ago, but at first we kept all of our systems that were backed up by amanda outside the NAT range. As time moved on we started bringing some of them inside, and it seemed that the easiest way to get both the inside (translated) and outside (nontranslated) addresses would be to build an amanda server and place it inside. After building a system with FreeBSD 4.5 and amanda, we found that it was able to connect to the machines outside, but none of the machines inside, including itself. Is there something we missed? We enabled the operator accounts on all the systems, we used inetd to start amanadad as operator on all the systems, and added the UDP and the two TCP ports into /etc/services. But yet we still cannot get the new amanda server to get anything inside, including itself. When we run amcheck it reports all the systems inside to be host down?. Any ideas would be much appreciated. --- Lee Parsons LAN Administrator The Minnesota Daily www.mndaily.com I would check your DNS settings (and /etc/resolv.conf) and if they correspond to what you have listed in your disklist file. If the amanda server has a problem with the user it will complain about that in particular (i.e. root/operator/etc). In your case, start with one machine and get that one working -- it's probably the same problem everywhere. Perhaps you aren't using the correct FQDN? Debug files will be in /tmp/amanda. -- ~ Doug Silver Network Manager Quantified Systems, Inc ~
