rsync Over the VPN: Daemon Port 873 vs SSH Mode

Allowing TCP 873 on the tunnel interface does not push rsync through OpenVPN, and it does not make the far end accept the module. A tunnel carries an inner connection whose protocol and destination rules stay exactly as they were. The first question is therefore not which port to open but which kind of connection rsync is making. Everything below assumes the tunnel is already up and only the inner service is still in doubt.

Decide Which Connection rsync Actually Makes

The remote argument in the command usually answers that question before any firewall change. A double colon or a URL scheme selects the daemon, while a single colon after a host name selects a remote shell. Read the argument you are actually running rather than the one in the documentation example.

An explicit remote-shell option can change the answer again, because it tells rsync which program to spawn for the transport. Read the whole command line, including inherited wrapper scripts, rather than only the host part.

Daemon Mode: Bind Address, Module and Port

In daemon syntax the path segment names a configured module, not a directory on disk. A module password is checked only after the connection has been accepted, and the module may additionally be read-only or hidden from listing. That ordering matters when you read an error, because a refused connection and a rejected module are failures at two different stages. Neither message tells you anything about the tunnel itself.

A standalone daemon can be pinned to the tunnel address in its configuration file, which keeps it off the public interface without any firewall rule. The value must exist when the daemon binds, and a socket-activated or inetd-managed listener may ignore it entirely.

address = 10.44.0.1
port = 873
[archive]
    path = /srv/archive
    read only = yes

Then test against the private address rather than the public name. A public host name resolves to a WAN address and exercises a different path, even when one machine answers on both.

rsync --list-only rsync://10.44.0.1/archive/

Remote-Shell Mode: SSH Carries the Transfer

With a single colon, rsync starts a remote-shell program and speaks its protocol over that channel, so the only reachable service is SSH on whatever port the server listens on. The rsync daemon never runs, port 873 is irrelevant, and the access decision becomes an SSH account decision. The remote path is then a real filesystem path interpreted by the shell on the far side. That is why a firewall change aimed at 873 does nothing at all for this mode.

That design needs an authorised account and host key verification, and it inherits SSH's own authentication policy. It is often the better choice when the transfer must cross an untrusted network, because the encryption belongs to a protocol that was built for it. A daemon with a password prompt is not the same thing.

Open Only the Path You Chose

Once the mode is settled, permit the one inner service on the one interface that carries the tunnel. Scope the rule by interface, source pool and destination address so a later default-deny change cannot silently widen it. Review rule order afterwards, because a permissive rule earlier in the chain makes the narrow one decorative.

If the daemon runs on a machine behind the VPN gateway rather than on the gateway itself, the gateway needs a forwarding path as well and the target needs its own permission and return route. Opening the port on the gateway alone produces a connection that is accepted and then goes nowhere.

Verify from the client with the same mode and destination you intend to use in production. A successful listing proves the listener, the route and the rule together; a timeout points at the path, and a refusal points at the listener.

ufw allow in on tun0 from 10.44.0.0/24 to 10.44.0.1 port 873 proto tcp
ss -ltnp | grep 873