R1Soft Server Backup Manager (SBM) and its agents have a small but specific set of network requirements, and most "agent shows offline" tickets come down to a firewall rule that was right for the wrong direction. This article is the reference: every port the product uses, which side initiates the connection, and ready-to-paste rules for the firewalls you actually run on a hosting fleet.
It assumes you have an SBM up at backups.example.com and agents on the cPanel, Plesk, or DirectAdmin boxes you want to protect. If you have not yet enrolled an agent, start with installing the R1Soft agent on AlmaLinux or on Windows Server and come back here when something refuses to connect.
The connection model — who calls whom
R1Soft has three traffic flows. Getting the direction right is the whole game, because a stateful firewall that allows return traffic will silently mask a missing ingress rule until you reboot it.
- Operator → SBM. Humans and monitoring hit the SBM web UI on TCP/8443. Nothing on the public internet should reach the SBM on any other port.
- SBM → Agent. The SBM initiates outbound connections to each protected server on TCP/1167. The agent never calls home; if you cannot reach the agent from the SBM, the SBM cannot back it up.
- SBM → SBM (replication). A source SBM connects to a destination SBM on TCP/1167, exactly as if the destination were an agent. The destination does not initiate. See disk safe replication setup for the full configuration.
There is no agent-initiated callback, no UDP, and no broadcast discovery. If you remember nothing else: the SBM is the client, the agent is the server, and 1167 is the door.
Port reference
| Port | Proto | Direction | Used by | Required |
|---|---|---|---|---|
| 8443 | TCP | Operator → SBM | SBM web UI and REST/SOAP API over HTTPS | Yes |
| 8084 | TCP | Operator → SBM | SBM web UI over plain HTTP — legacy | No, disable in prod |
| 1167 | TCP | SBM → Agent | Backup agent control and block-level transfer | Yes |
| 1167 | TCP | SBM → SBM | Disk safe replication, same protocol as agent | If replicating |
| 25 / 587 / 465 | TCP | SBM → SMTP relay | Email notifications and reports | If using email alerts |
| 443 | TCP | SBM → licensing | Activation against licensing.r1soft.com and licensing.tuxcare.com | Yes |
| 443 | TCP | Agent → licensing | Standalone-licensed agents only — most fleets use SBM-managed licenses | Rarely |
The HTTP listener on 8084 is enabled out of the box. Disable it once you have TLS working — there is no good reason to leave a plaintext admin port open. The procedure is in installing a Let's Encrypt cert on the SBM.
Operator → SBM (port 8443)
This is the only port that should be reachable from your office, your home, or a jump host. The web UI is a Tomcat application; the REST and SOAP APIs share the same connector, so locking down 8443 locks down everything an operator can do.
If you only have a handful of static operator IPs, allow them directly:
firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
source address="203.0.113.10"
port port="8443" protocol="tcp" accept'
firewall-cmd --reload
For more than a few operators, put the SBM behind a Cloudflare Tunnel or a WireGuard bastion and keep 8443 closed on the public interface entirely. The SBM is not designed to be a public-facing service.
SBM → Agent (port 1167)
The rule lives on the agent side, scoped to the SBM's IP. For a single-SBM deployment on a Linux agent with firewalld:
firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
source address="198.51.100.5"
port port="1167" protocol="tcp" accept'
firewall-cmd --reload
On a cPanel server running ConfigServer Firewall, edit /etc/csf/csf.allow:
tcp|in|d=1167|s=198.51.100.5
Then csf -r to apply. Do not add 1167 to TCP_IN in csf.conf — that opens it to the world.
On Ubuntu with UFW:
ufw allow from 198.51.100.5 to any port 1167 proto tcp
On Windows Server agents, the installer creates a Windows Firewall rule called R1Soft Backup Agent scoped to "Any". Edit the rule and replace the remote IP scope with the SBM IP under Properties → Scope → Remote IP address.
SBM → SBM replication (port 1167)
Replication targets the destination SBM on the same TCP/1167 the agent uses. The destination treats the source SBM as if it were an agent, so the firewall rule on the destination is identical to an agent rule with the source SBM's IP allowed in:
firewall-cmd --permanent --add-rich-rule='
rule family="ipv4"
source address="198.51.100.5"
port port="1167" protocol="tcp" accept'
If source and destination are in different data centres with private interconnect, prefer the private IPs and disable 1167 on the public interface entirely. Replication traffic is bulk block data — keeping it off the public NIC saves both bandwidth bills and attack surface.
SBM → outbound (licensing, SMTP, updates)
The SBM needs unrestricted outbound 443 to the vendor licensing endpoints. If your egress firewall is a default-deny, allowlist:
licensing.r1soft.comlicensing.tuxcare.comrepo.r1soft.comfor package updates
License activation re-checks on a 24-hour cycle. If the SBM cannot reach licensing for more than the grace period, the web UI returns to the activation screen and backups stop. This is the most common cause of "everything was fine last week" tickets after a network team adds an egress firewall.
SMTP for notifications is whichever relay you configure — the SBM does not need direct port 25 outbound if you point it at a relay on your network.
Verifying the path end-to-end
From the SBM, prove you can reach an agent before opening a support ticket:
nc -vz agent.example.com 1167
ss -tnp | grep ':1167'
A successful nc returns succeeded. If nc hangs, the firewall is dropping rather than rejecting — confirm with tcpdump -ni eth0 'port 1167 and host agent.example.com' on the agent side. If you see SYN with no SYN-ACK, the agent is not listening; if you see SYN-ACK then RST, a stateful firewall in the middle is killing the session.
From the operator workstation to the SBM:
curl -vI https://backups.example.com:8443/ 2>&1 | grep -E 'HTTP/|subject|issuer'
A HTTP/1.1 302 redirect to /login.do is the healthy response.
Common breakages
- Agent shows "Cannot connect" after a CSF rule reload on cPanel.
csftest.plreturns OK but the agent rule got reset because it was incsf.allowand notcsf.allow.locked. Move the rule, or add anLF_GLOBAL_ALLOWentry, depending on the CSF version. - Replication runs locally but fails over WireGuard. The MTU on the tunnel is below the path MTU and the SBM is fragmenting on a 1167 stream. Set
MTU=1380on the tunnel interface or enable PMTUD on the firewall. - All agents go offline simultaneously after a hypervisor migration. The SBM's outbound source IP changed and you scoped agent firewalls to the old address. Update the agent-side rules first, then restart the SBM.
- Web UI works on 8443 but the REST API returns 401 from a script. Two things share 8443 — the Tomcat servlet and the API. The API uses a separate API key, not the operator's session cookie. Generate one under Settings → API Keys.
- Replication target SBM rejects the source after an SSL cert renewal. Disk safe replication validates the destination's TLS certificate on the 8443 control channel, not on 1167. If you replaced the cert on the destination without updating the source's trust store, replication breaks. Re-pair them under Replication → edit destination → Test.
FAQ
What ports does R1Soft Server Backup Manager use?+
Which side initiates the R1Soft agent connection?+
Can the R1Soft agent connect outbound to the SBM instead?+
Is it safe to expose port 1167 to the public internet?+
Does R1Soft replication use a different port from the agent?+
Why does my R1Soft SBM stop working after our network team adds egress filtering?+
Next steps
- Lock the web UI down with a real cert: Let's Encrypt on R1Soft SBM.
- Plan the second-site copy on the right private network: disk safe replication setup.
- Buy or renew agent and SBM keys: R1Soft license.