Panellicense

R1Soft port reference and firewall rules for SBM and agents

Every port R1Soft Server Backup Manager and its agents need, the direction each connection runs, and copy-paste firewall rules for firewalld, CSF, UFW, and AWS security groups.

9 min readUpdated 2026-05-18r1soft · firewall · ports · network
schema: HowToschema: FAQPageschema: TechArticle

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

PortProtoDirectionUsed byRequired
8443TCPOperator → SBMSBM web UI and REST/SOAP API over HTTPSYes
8084TCPOperator → SBMSBM web UI over plain HTTP — legacyNo, disable in prod
1167TCPSBM → AgentBackup agent control and block-level transferYes
1167TCPSBM → SBMDisk safe replication, same protocol as agentIf replicating
25 / 587 / 465TCPSBM → SMTP relayEmail notifications and reportsIf using email alerts
443TCPSBM → licensingActivation against licensing.r1soft.com and licensing.tuxcare.comYes
443TCPAgent → licensingStandalone-licensed agents only — most fleets use SBM-managed licensesRarely

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.com
  • licensing.tuxcare.com
  • repo.r1soft.com for 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.pl returns OK but the agent rule got reset because it was in csf.allow and not csf.allow.locked. Move the rule, or add an LF_GLOBAL_ALLOW entry, 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=1380 on 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?+
TCP/8443 for the web UI and API, TCP/8084 for legacy HTTP (disable in production), and TCP/1167 outbound to each agent. Replication targets another SBM on TCP/1167. The SBM also needs outbound 443 to licensing.r1soft.com and licensing.tuxcare.com for license validation.
Which side initiates the R1Soft agent connection?+
The SBM connects to the agent on TCP/1167, not the other way round. The agent listens and the SBM dials. This is why agent-side firewalls must allow inbound 1167 from the SBM's IP, and why an agent behind aggressive NAT without a port forward will never be reachable.
Can the R1Soft agent connect outbound to the SBM instead?+
No. The agent is the listener and the SBM is the client — there is no reverse-call mode. For agents behind NAT, either configure a port forward to the agent on 1167, or place the SBM on the same private network.
Is it safe to expose port 1167 to the public internet?+
No. The agent protocol has no brute-force protection and a leaked SBM key gives block-level read access to the disk. Always restrict 1167 to the SBM's source IP using firewalld, CSF, UFW, or a cloud security group.
Does R1Soft replication use a different port from the agent?+
No — replication uses the same TCP/1167, with the source SBM acting as the client and the destination SBM acting as a listener. The destination's firewall rule for 1167 is identical to an agent rule, scoped to the source SBM's IP.
Why does my R1Soft SBM stop working after our network team adds egress filtering?+
The SBM re-checks its license against licensing.r1soft.com and licensing.tuxcare.com on a 24-hour cycle. Block outbound 443 to those hostnames and after the grace period the SBM returns to the activation screen and backups stop. Allowlist both hostnames and the repo at repo.r1soft.com.

Next steps

Switch in an afternoon

Switch from your current reseller — free.

We migrate active cPanel, Plesk, LiteSpeed and CloudLinux licenses from any reseller. We prorate the first month so you never pay twice, and your customers see zero downtime during the swap.