Replication Network And Firewall Planning

Guide

Replication Network And Firewall Planning

Plan the control, inter-site and recovery-site network paths for controller-backed replication: Via SHA, Direct P2P, assigned SNA ranges and Controller connectivity.

ReadyCurrentreplicationnetworkingfirewallsnacontrollersdirect-p2p

Purpose And Scope

This guide covers the network paths and firewall rules required for controller-backed disaster-recovery replication between a protected site and a recovery site. It is written for customer infrastructure administrators, network and firewall teams, implementation partners, MSP and CSP operations teams, and Sendense support and deployment engineers.

It is not a complete list of every port used by every Sendense feature. It does not cover administrator access to the SHA GUI, EBA repository or object storage connectivity, source platform API access, or any backup-only path beyond the appliance connection that carries it.

Control Plane Versus Data Plane

SHA is the control plane on every route. For each sync it schedules the work, selects a healthy SNA at each site, applies the route policy, prepares the recovery-side ingress, and receives progress and health reporting. Choosing a different route never moves control traffic off SHA.

The route policy changes only the inter-site replication data path. Every route ends the same way: the replication stream arrives at the recovery-site SNA, which passes it to the Sendense Controller holding that protected VM's replica disks. Planning the recovery-site hop is required whichever route you choose.

Connectivity Matrix

Each connection below is initiated by the appliance in the initiator column. Normal stateful return traffic follows each established connection, so no separate reverse rule is needed for the replies on an allowed flow.

SNA to SHA - TCP 443 outbound - always required

Carries enrollment, control, health, backup and hub-routed replication traffic. The SNA always initiates it; SHA never dials into the customer site.

Source SNA to destination SNA - destination appliance's assigned replication ingress range - Direct P2P, or Automatic when the direct route is selected

Carries inter-site replication data across your own site-to-site network. The source SNA initiates it.

Destination SNA to Sendense Controller - TCP 10810 upward, one successive port per replica disk - every controller-backed route

Writes the replica disks. Stays inside the recovery site and is initiated by the destination SNA. Required on the hub route too.

Via SHA Requirements

The hub route is the lowest-friction route to plan for. Both sites need only the outbound SNA-to-SHA connection, and no direct site-to-site path exists in the data flow.

Via SHA: hub-routed replication path

On the hub route each site only needs its normal outbound connection to SHA. There is no site-to-site path and no inbound rule at either site for replication.

Replication data, solidHealth reporting, dotted

Text equivalent

Each SNA opens one outbound encrypted connection to SHA on TCP 443. SHA never dials into a customer site.
Replication data travels source SNA to SHA to target SNA inside those two established connections.
SHA relays the stream between the two connections and does not store replication data.
The target SNA then writes the replica disks on the Sendense Controller. That hop stays inside the recovery site and is still required on this route.
No site-to-site network path and no inbound firewall rule at either site are required for the hub route itself.

What you must allow

Outbound TCP 443 from every SNA to SHA, plus the recovery-site rule from the target SNA to the Sendense Controllers. Nothing else is needed between the sites.

Where the data lives

Nowhere on SHA. The hub relays the replication stream between the two appliance connections rather than buffering it to disk.

Both sites need SNA-to-SHA outbound TCP 443, and nothing else between the sites.
No inbound rule is required at the protected site or the recovery site for the hub route itself.
SHA relays the replication stream between the two appliance connections and does not store or buffer it to disk.
Replication data travels inside the enrolled encrypted appliance connections for the whole inter-site journey.
The recovery-site rule from the destination SNA to the Sendense Controller still applies. Via SHA removes the inter-site rule, not that one.

Direct P2P Requirements

Direct P2P moves the replication stream off the hub and onto your own network between the two sites. It is the only route that needs an inter-site firewall rule.

Direct P2P: firewall boundaries

On the direct route the source SNA initiates a connection across your own site-to-site link to a temporary listener on the destination SNA. Control and health still run through SHA.

Direct replication data, dashed (crosses the site boundary)Recovery-site replication data, solid (stays local)Control and health, dashed grey (always to SHA)

Text equivalent

The source SNA always initiates the direct connection. The destination SNA never dials back towards the protected site for replication data.
The destination SNA opens temporary listeners on ports leased from its own assigned replication ingress range, and releases them when the sync ends.
One active listener is used per replica disk of the protected VM, so a three-disk VM uses three listeners during its sync.
The inter-site rule crosses the protected-site boundary, the private link and the recovery-site boundary, and should run over a VPN, MPLS circuit or private interconnect.
Inside the recovery site the destination SNA writes the Controller replica-disk exports, starting at TCP 10810 and increasing by one per replica disk.
Control, health and route selection continue separately over each SNA's outbound TCP 443 connection to SHA.

Inter-site rule

Allow each eligible source SNA to reach the destination SNA on that destination appliance's assigned replication ingress range. Read the range from the appliance rather than copying an example.

Recovery-site rule

Allow the destination SNA to reach the Sendense Controllers on their replica-disk replication ports. This rule is required on the hub route too.

The source SNA initiates the connection. The destination SNA never dials back towards the protected site for replication data.
The destination SNA opens a temporary listener on a port taken from its own assigned replication ingress range, for the duration of the sync.
Sendense runs a live reachability probe from the source SNA before selecting the direct route, and only uses it when the probe succeeds.
Direct P2P should run over a private or trusted customer network such as a VPN, MPLS circuit or private interconnect.

Direct transport security comes from your link

Transport security on the direct leg is inherited from the VPN, MPLS circuit or private interconnect it crosses. Sendense does not add its own encryption layer to the direct replication stream, so do not plan Direct P2P across an untrusted or public path. If replication data must stay inside the Sendense encrypted appliance connections end to end, use Via SHA.

The Assigned Destination-SNA Range

The inter-site rule for Direct P2P targets a range that Sendense assigns to the destination appliance, not a fixed product-wide value.

A replication ingress range is assigned per SNA, at enrollment.
Two SNAs will normally have different assigned ranges, including two SNAs at the same recovery site.
There is no single deployment-wide constant. A range is a property of one appliance, not of Sendense.
Ports inside the range are leased for the duration of an active job and released afterwards. The range is the set of ports Sendense may use, not a set of permanently open sessions.
Build firewall rules from the range your own appliance reports, using the GUI or API method below.

Examples in this guide are not defaults

Every numeric range shown on this page is illustrative. Use the range assigned to your destination SNA. In the API and appliance model this value is currently named the NBD restore range; the customer-facing name for it is the assigned replication ingress range.

One Port Per Replica Disk

Sendense prepares one destination-SNA listener for each replica disk in the protected VM, and maps each listener to the matching replica-disk export on the Sendense Controller. A one-disk VM normally consumes one active listener during a sync; a four-disk VM normally consumes four.

A three-disk protected VM uses three destination-SNA listeners during its sync. Each listener forwards to the corresponding replica-disk export on the Controller.

This is why the assigned range also defines concurrent relay capacity for that appliance. Size the range against the total disk count of the VMs that will replicate concurrently through that SNA, not against the number of VMs.

Destination SNA To Controller

The final hop is inside the recovery site and is required on every controller-backed route, including Via SHA. The destination SNA initiates it; the Sendense Controller only listens and never dials the SNA for replication data.

The Controller exposes one replication port per replica disk, starting at TCP 10810 and increasing by one for each additional replica disk, ordered by source disk index. The same rule applies to CloudStack and VMware destination platforms.
The required upper port depends on the largest replica-disk count you expect a single protected VM to have. Illustrative only: for a maximum of 10 replica disks, allow TCP 10810-10819.
Scope the rule from the IP addresses of the eligible recovery-site SNAs to the Controller subnet. Do not open these ports broadly.
Sendense also maintains a host-level allowlist on the Controller restricting each replication port to eligible recovery-site SNA addresses. Treat that as defence in depth, not as a replacement for your own network policy.
The Controller appliance root disk is not the replicated workload disk. Replication writes the attached replica disks only.

Multi-SNA Sites

SHA may select any healthy eligible SNA at the source site and any healthy eligible SNA at the recovery site. Firewall policy must therefore cover every permitted source-SNA-to-destination-SNA pairing and each destination SNA's assigned ingress range.

Selection is health-based and dynamic. For each sync Sendense skips appliances that are offline, stale on heartbeat, or in maintenance mode, and balances work across the remaining healthy appliances with available capacity. An appliance that was not selected yesterday can be selected today, for example after a planned maintenance window on the appliance that normally handles the work.

The practical consequence is that a rule covering only one SNA pairing produces intermittent Direct P2P behaviour rather than a clean, repeatable failure. Syncs succeed whenever the covered pair happens to be selected, and fail or fall back whenever a different pair is selected.

Multi-SNA firewall planning

SHA picks a healthy appliance at each site per sync, so firewall policy has to cover every pairing the scheduler may select, using each destination appliance's own assigned range.

Direct replication pairing, dashed (one rule each)Recovery-site Controller path, solid

Text equivalent

SHA may select any healthy eligible SNA at the source site and any healthy eligible SNA at the recovery site for a given sync.
With two eligible SNAs at each site there are four possible pairings, and firewall policy must cover all four.
Destination SNA A and destination SNA B have different assigned ingress ranges, so the rule for each pairing uses the range belonging to that destination appliance.
Selection is health-based: appliances that are offline, stale on heartbeat, or in maintenance mode are skipped, so the pairing in use can change between syncs.
Covering only one pairing produces intermittent Direct P2P behaviour rather than a clean repeatable failure.
Every destination SNA also needs the recovery-site rule to the Sendense Controllers.

Rule count

Plan the inter-site rules as a full matrix of eligible source SNAs by eligible destination SNAs, then add one recovery-site Controller rule per destination SNA.

Common symptom

Direct P2P that works some days and falls back or fails on others is usually an incomplete pairing matrix, not an unstable network.

Obtaining Your Assigned Values

Two supported methods return the range assigned to a specific appliance. Both are authoritative for that appliance.

In the SHA GUI, open DenseView, select the Appliances tab in the left rail, expand the site, and select the SNA. The right panel shows a Port allocations section containing Restore slots, which is that appliance's assigned replication ingress range together with the number of concurrent slots it provides.

Record the returned range with the rest of your firewall documentation and recheck it after an appliance is replaced or re-enrolled, because a re-enrolled appliance can receive a different slot.

API requesthttp

GET /api/v1/appliances/{id}/ports

Required permission: settings.read

Relevant response fieldsjson

{
  "nbd_restore_range": { "start": 13000, "end": 13019 },
  "nbd_backup_range":  { "start": 12200, "end": 12219 }
}

Read the restore range, not the backup range

nbd_restore_range is the assigned replication ingress range and is the value your Direct P2P rule needs. nbd_backup_range is a separate SHA-side backup allocation and is not the Direct P2P ingress rule. The values shown above are illustrative only.

Firewall Examples

The examples below use RFC 5737 documentation addresses. Assume protected-site SNAs 192.0.2.10 and 192.0.2.11, recovery-site SNAs 198.51.100.10 and 198.51.100.11, and a recovery-site Controller subnet of 203.0.113.0/24.

Example A - Via SHA onlytext

ALLOW  192.0.2.10      -> SHA address   TCP 443   (outbound)
ALLOW  192.0.2.11      -> SHA address   TCP 443   (outbound)
ALLOW  198.51.100.10   -> SHA address   TCP 443   (outbound)
ALLOW  198.51.100.11   -> SHA address   TCP 443   (outbound)

# No inter-site rule and no inbound rule at either site are required
# for the hub route. The recovery-site Controller rule still applies.

Example B - Direct P2P, one SNA at each sitetext

# 1. Inter-site, at the recovery-site perimeter
ALLOW  192.0.2.10 -> 198.51.100.10   TCP 13000-13019
# Illustrative only. Use the range assigned to your destination SNA.

# 2. Inside the recovery site
ALLOW  198.51.100.10 -> 203.0.113.0/24   TCP 10810-10819
# Illustrative only. The upper port depends on your largest replica-disk count.

# 3. Plus the always-required TCP 443 outbound from both SNAs to SHA.

Example C - Direct P2P, multiple SNAstext

# Every eligible source SNA to every eligible destination SNA,
# each on that destination appliance's own assigned range.
ALLOW  192.0.2.10 -> 198.51.100.10   TCP 13000-13019
ALLOW  192.0.2.11 -> 198.51.100.10   TCP 13000-13019
ALLOW  192.0.2.10 -> 198.51.100.11   TCP 13020-13039
ALLOW  192.0.2.11 -> 198.51.100.11   TCP 13020-13039
# Illustrative only. The two destination SNAs have different assigned
# ranges; read each appliance's own value rather than assuming they are
# contiguous or identical.

# Both destination SNAs also need the recovery-site Controller rule.
ALLOW  198.51.100.10 -> 203.0.113.0/24   TCP 10810-10819
ALLOW  198.51.100.11 -> 203.0.113.0/24   TCP 10810-10819

Route Policy Behaviour

The route policy is set per replication pattern and evaluated for every sync. The same missing firewall rule shows up differently depending on which policy is in force.

Automatic route selection

Automatic evaluates the direct route for every sync and falls back to the hub route when it cannot be used. The other two policies remove that choice.

Evaluation step, dashed greyDirect route selected, dashedHub route selected, solidSync refused, dotted

Text equivalent

Via SHA policy: the hub route is always used and the direct route is never attempted.
Automatic policy: if the destination appliance has no usable direct address, the sync uses Via SHA.
Automatic policy: if it does have one, Sendense runs a live reachability probe. A successful probe selects Direct P2P; a failed probe falls back to Via SHA.
Direct P2P policy: the probe must succeed. If it fails, the sync fails with an error rather than rerouting through the hub.
The same missing firewall rule therefore appears as a silent fallback under Automatic and as an outright failure under Direct P2P.

Why this matters for firewalls

A pattern running happily on Automatic can still have a broken direct path. Check which route the last sync actually used before concluding the inter-site rule is correct.

Automatic uses the direct route when the destination SNA has a usable direct address and the live probe succeeds. Otherwise the sync uses Via SHA.
Direct P2P requires the direct route. If the probe fails, the sync fails with an error instead of rerouting through the hub.
Via SHA always uses the hub route and never attempts the direct route or the probe.
A pattern that is working on Automatic can still have a broken direct path. Check which route the sync actually used rather than assuming the direct rule is correct.

Security Characteristics

Source restriction: every rule here can and should be scoped to specific appliance addresses rather than to whole networks.
Stateful return traffic: each flow is initiated by one side, so stateful firewalls do not need a matching reverse rule.
Private or trusted link: Direct P2P inherits the security of the link it crosses. Use it over VPN, MPLS or a private interconnect.
Least privilege: allow only the eligible appliance addresses on the exact ranges involved. Do not use any-source rules for convenience.
No Internet exposure: a destination SNA's assigned ingress range must never be reachable from the public Internet, only from eligible source SNAs.
Controller scoping: Controller replication ports should be reachable only from eligible recovery-site SNAs, never from general recovery-site subnets or from across the site boundary.
Hub route data handling: SHA relays hub-routed replication data between the two appliance connections and does not store it.

Validation Checklist

Work through these in order, using supported product checks first.

Confirm both SNAs are online and healthy in SHA, and that neither is in maintenance mode.
Confirm each SNA shows a current heartbeat, which proves its outbound TCP 443 connection to SHA is working.
Confirm the destination SNA's assigned replication ingress range in the GUI or API, and check it against the rule you deployed.
Run or observe the Sendense reachability probe for the pattern. This is the product's own test of the inter-site rule.
Verify the route Automatic actually selected for the last sync. Selecting Via SHA when you expected direct means the direct path is not usable.
Verify the Controller for the protected VM is healthy and reachable from the destination SNA, which exercises the recovery-site rule.
Distinguish probe failure, range exhaustion, Controller offline and route-policy failure rather than treating them as one fault.

Troubleshooting

Automatic unexpectedly uses Via SHA

The direct route was not selected, so either the destination SNA has no usable direct address recorded or the reachability probe failed. Check the inter-site rule against the destination appliance's own assigned range, then re-run the probe.

Forced Direct P2P fails

Under the Direct P2P policy a failed probe fails the sync by design. This is the same root cause as the previous item. Switching to Automatic restores service via the hub route but hides the underlying network problem.

One target SNA works while another fails

The working pairing is covered by a rule and the failing pairing is not, or the second destination SNA has a different assigned range. Read each destination appliance's range separately and complete the matrix.

Multi-disk sync fails partway through setup

Sendense prepares one listener per replica disk. If the rule covers only part of the assigned range, the first disks succeed and a later disk fails. Verify the rule spans the full assigned range.

Range capacity exhausted

The appliance had no free ports for the replica disks required. Reduce concurrent replication through that appliance, add another SNA at the site, or have the range widened. The constraint is total concurrent replica disks, not VMs.

Controller port unreachable

The inter-site path can be healthy while the recovery-site hop is not. Confirm the destination SNA can reach the Controller subnet on TCP 10810 upward for the number of replica disks that VM has, scoped from the correct SNA addresses.

Address mismatch behind NAT

Sendense uses the address recorded for the destination appliance as the direct target, and there is currently no separate advertised or translated address setting for the direct route. If the recorded address is not the address the source site should dial, plan Via SHA for that pairing or provide a routed private path where the recorded address is reachable.