Port NNNN is not secure: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
No edit summary
 
mNo edit summary
Line 19: Line 19:
My ipnat.conf:  
My ipnat.conf:  


map ex0 from 172.30.2.42 to 10.0.0.4 -> 10.0.0.6/32 portmap udp 600:800
map ex0 from 172.30.2.42 to 10.0.0.4 -> 10.0.0.6/32 portmap udp 600:800
 
map ex0 172.30.2.0/24 -> 10.0.0.6/32 portmap tcp/udp 1025:60000  
map ex0 172.30.2.0/24 -> 10.0.0.6/32 portmap tcp/udp 1025:60000 map ex0 172.30.2.0/24 -> 10.0.0.6/32  
map ex0 172.30.2.0/24 -> 10.0.0.6/32  


2. Allow the transport stream. This happens on a high numbered TCP port thats randomly chosen for both endpoints. It took me a while to determine this.
2. Allow the transport stream. This happens on a high numbered TCP port thats randomly chosen for both endpoints. It took me a while to determine this.
frags of my ipf.conf on the client: (These both have group tags that pulled the traffic from the particular interface.)
frags of my ipf.conf on the client: (These both have group tags that pulled the traffic from the particular interface.)
pass in proto udp from 10.0.0.0/28 to any port = amanda
pass in proto udp from 10.0.0.0/28 to any port = amanda
pass in proto tcp from 10.0.0.6 to 10.0.0.4 keep state
pass in proto tcp from 10.0.0.6 to 10.0.0.4 keep state


----
----


Note by sgw: This should go into a special Firewall-section.
Note by sgw: This should go into a special Firewall-section.

Revision as of 21:05, 5 December 2005

--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

Because `amcheck', as some other Amanda programs, must be installed as setuid-root. Run `make install' as `root', or `chown' all Amanda setuid programs to `root', then `chmod u+s' them again, if `chown' drops the setuid bit.


--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

It seems that there is another reason for this error-message, too. In my case it was a problem with masqueraded connections. I could solve the problem in my case, by simply not using masquerading ;) but other solutions like port forwarding or by tunneling over ssh could solve the problem (with some luck).


--- This text was originally contributed to the AMANDA-FAQ-O-Matic by [email protected]. ---

To get Amanda to work across a NAT (masquerade) boundry you need two things:

1. set up a forwarding that preserves the reserved port (which is silly in this day and age). 10.0.0.4 is the Amanda Client, 172.30.2.42 is the Amanda Server, 10.0.0.6 is the NAT's external IP. My ipnat.conf:

map ex0 from 172.30.2.42 to 10.0.0.4 -> 10.0.0.6/32 portmap udp 600:800
map ex0 172.30.2.0/24 -> 10.0.0.6/32 portmap tcp/udp 1025:60000 
map ex0 172.30.2.0/24 -> 10.0.0.6/32 

2. Allow the transport stream. This happens on a high numbered TCP port thats randomly chosen for both endpoints. It took me a while to determine this. frags of my ipf.conf on the client: (These both have group tags that pulled the traffic from the particular interface.)

pass in proto udp from 10.0.0.0/28 to any port = amanda
pass in proto tcp from 10.0.0.6 to 10.0.0.4 keep state

Note by sgw: This should go into a special Firewall-section.