File replication across a WAN - can't get it to work

Scenario. I have a DSS on an internal server serving files to users. I setup another internal server with DSS to test file replication (rsync). File replication worked fine. I rent a server in a data centre, install DSS and fully setup shares etc etc. On the internal DSS, I can setup the replication job and choose the share from the remote DSS with no problem. Every time I run the replication job it fails with destination does not exist. I check the firewall that is protecting the internal DSS and there are no errors or requests from the external DSS being blocked. I browse the forums and see mention of needing to open a tcp port from the outside to the internal address of the DSS which I do but this doesn't make any difference. Hard to understand why this would needed anyway since replication is being intiated from the internal DSS which can make any outbound connections that it likes. I also use rsync quite a bit to make a copy of internal server files on remote rync servers with no problem at all. What is special about the way that rsync works on DSS that causes this to fail? Please, please can anyone help? I have checked and double checked every setting and can see no issues and as mentioned, when done between two servers within the same network, it also works fine. Many, many thanks

Before you point out how very insecure this arrangement is, I have restricted access to specific IPs and turned off all unnecessary protocols etc.

Just to make sure that I understand, are you using the Data Replication (rsync) over a WAN?
If so make sure you have the port 873 on the firewall.

Hi, I did try this but it made no difference. I opened tcp/873 from the public IP of the hosted DSS and pointed it to the internal address of the source DSS. I am a Cisco Certified Network Professional, so I am pretty sure that I know how to this.

I would be grateful if you could explain why the destination DSS needs to initiate a connection to the source DSS when it is the source DSS that is pushing data to the hosted DSS?

As also stated, I already use rsync for backup of linux internal servers to hosted servers without any problems.

Thanks,

Martin

The Destination does not need to initiate a connection. If your able to see the Shares of the Destination and your Snapshot is assigned to that NAS Logical Volume then it should work as it is that easy as you have it setup on the other servers internally.

What does the rsync logs say on the Source server? We might want to see the logs from both systems so you might want to submit a support ticket.

Tood, I did reply to this thread before, but it seems that it was not accepted, so here goes again...

Please can explain why port 873 should be open to allow traffic from the public to reach the DSS on an internal network when it is the internal DSS that is replicating with a DSS on a public network. This just does not make sense. At the moment, it seems that I will have to configure a generic Linux with rsync running and use this as a backup destination rather than DSS, but I would prefer to use another DSS for this role.

Thank you

As stated in the manual "In order to perform data (file) replication over the Internet you have to configure the firewall port to 873." We have certain security measures. Again send the logs to support and we can review them.

Todd,

Could you tell me which exact log contains more information on why the rsync replication fails please. I have looked through and can not see which one it is. Thanks

The log file is located in the GUI STATUS -> Hardware -> Function: Logs then click on the Download button. Then use a program like WinRAR to open the ..tar.gz file then search in the main dir listings for the rsync.log other logs you should look at to make sure all is ok is the Tasks, dmesg2, critical errors there are a few others and how to understand them we have a video on our website as with many other videos that you can learn logs.

Todd,

Have now got to the bottom of this, by dedicating a whole public IP address to the internal DSS using static NAT/PAT. It turns out that after the internal DSS (the source DSS on an internal IP address) initiates the replication, that the remote DSS sends an icmp packet back to the source DSS. Once this is allowed, the replication starts fine. The tcp/873 is utterly irrelevant in this scenario.

Surely someone at Open-E knows this perfectly well. Why did I have spend so many hours discovering this for myself?

I hope this post can help someone else...

Martin,

I was assuming that your where RTFMing from the manual "reading the fine manual" :)
This is why I was mentioning the port 873 as this is clearly mentioned in the manual as I stated SEE top page of 107 in 3rd note
down from the top explaining what to do w/ WAN replication. In the future let me know that you did not read the manual about a certain function that you are inquiring about, I am Cisco certified as well and those tests days are long over :) but reading the manual was critical when learning the functions.

Adding another note: The forum is community based so forum moderators are assisting outside of their normal work hours so it is out of our free interest to help and assist.

Todd,

I did indeed read the manual before raising a ticket in the forum and I do appreciate that you do not have to answer any particular question out of work hours. I have just re-visited the manual on page 107 and feel no more enlightened. As a fellow CCNP, could you explain what the relevance of tcp/873 is then for my scenario eg. internal DSS is replicating to a DSS on the outside? I first allowed access to this port from outside and the file rep still did not work. I saw on my Cisco log that the outside DSS was trying to send icmp packets to the internal DSS, so allowed this and then everything works. I have removed access to tcp/873 from outside and everything continues to work. Perhaps I am rather thick, but I have read nothing about needing to allow ICMP packets from the outside to the internal address of the inside DSS. Are you saying that the documentation is clear in this case?

Thanks, Martin

http://www.liutilities.com/tcp-udp-port/873/

The rsync application essentially uses the port 873. This application can only be found on computers that are running on the UNIX OS. Rsync is utilized in the synchronization of folders and files in computers, even when the machines are not connected or physically close to each other. This information is transferred through the Local Access Network or the LAN or the Internet. The application associated with the port runs a background process and also listens to the port 873 on the TCP protocol. This information that is passing through this port 873 flows to and fro the computer.

http://ss64.com/bash/rsync.html

In this case you will connect to a remote rsync server running on TCP port 873.
You may establish the connection via a web proxy by setting the environment variable RSYNC_PROXY to a hostname:port pair pointing to your web proxy.
Note that your web proxy's configuration must allow proxying to port 873.
Using rsync in this way is the same as using it with rsh or ssh except that:


http://www.auditmypc.com/tcp-port-873.asp
PORT 873 – Information

• Port Number: 873
• TCP / UDP: TCP
• Delivery: Yes
• Protocol / Name: rsync
• Port Description: rsync.’rsync’
• TCP Port 873 may use a defined protocol to communicate depending on the application. A protocol is a set of formalized rules that explains how data is communicated over a network. Think of it as the language spoken between computers to help them communicate more efficiently.
• TCP port 873 uses the Transmission Control Protocol. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered on port 873 in the same order in which they were sent. Guaranteed communication over port 873 is the key difference between TCP and UDP. UDP port 873 would not have guaranteed communication in the same way as TCP.

http://www.open-e.com/site_media/dow...April_2009.pdf

There is so much more about this when you google about rsync and port 873. Ok time for me to go now see everyone next week!

removed for double post

Any other explanation, please contact me directly! This is fairly to the point, and understand we use rsync as open source, nothing special here!

Quote:

---

Originally Posted by To-M

http://www.liutilities.com/tcp-udp-port/873/

The rsync application essentially uses the port 873. This application can only be found on computers that are running on the UNIX OS. Rsync is utilized in the synchronization of folders and files in computers, even when the machines are not connected or physically close to each other. This information is transferred through the Local Access Network or the LAN or the Internet. The application associated with the port runs a background process and also listens to the port 873 on the TCP protocol. This information that is passing through this port 873 flows to and fro the computer.

http://ss64.com/bash/rsync.html

In this case you will connect to a remote rsync server running on TCP port 873.
You may establish the connection via a web proxy by setting the environment variable RSYNC_PROXY to a hostname:port pair pointing to your web proxy.
Note that your web proxy's configuration must allow proxying to port 873.
Using rsync in this way is the same as using it with rsh or ssh except that:


http://www.auditmypc.com/tcp-port-873.asp
PORT 873 – Information

• Port Number: 873
• TCP / UDP: TCP
• Delivery: Yes
• Protocol / Name: rsync
• Port Description: rsync.’rsync’
• TCP Port 873 may use a defined protocol to communicate depending on the application. A protocol is a set of formalized rules that explains how data is communicated over a network. Think of it as the language spoken between computers to help them communicate more efficiently.
• TCP port 873 uses the Transmission Control Protocol. TCP is one of the main protocols in TCP/IP networks. Whereas the IP protocol deals only with packets, TCP enables two hosts to establish a connection and exchange streams of data. TCP guarantees delivery of data and also guarantees that packets will be delivered on port 873 in the same order in which they were sent. Guaranteed communication over port 873 is the key difference between TCP and UDP. UDP port 873 would not have guaranteed communication in the same way as TCP.

http://www.open-e.com/site_media/dow...April_2009.pdf

There is so much more about this when you google about rsync and port 873. Ok time for me to go now see everyone next week!

---

I never suggested that tcp/873 was not used by rsync! I know that it is used by rsync, but my original question was asking how to allow a DSS on an internal network to replicate to an external DSS on a public IP. In this scenario, allowing tcp/873 has nothing to do with it since in the vast majority of cases, most types of trafiic are allowed out from a internal server. The solution was allowing icmp packets from outside and mapping them back to the internal DSS address which is something your documentation mentions nothing about. It seems that your documentation covers the reverse situation only. I sincerely hope this thread helps someone else out there and I really don't want to upset anyone, but this whole business should not have been such hard work!

Further to the above, I have used rsync for years to keep a copies of files on rsync servers hosted in data centres without needing any special firewall changes. The issue relates to some kind of check that DSS is doing prior to starting the sync!