A replicated virtual machine changed to an error state with a message in this form:
A replication error occurred at the vSphere Replication Server.
No connection to VR Server for virtual machine ... on host ... : Network
The message identifies the failed relationship: an ESXi host currently running the protected VM cannot establish the required data connection to the vSphere Replication server handling the target. It does not automatically mean that vCenter is down, the VM is damaged or the appliance certificate has expired.
The shortest investigation starts with scope and network direction. Only then should you consider restarting or re-registering services.
Understand the data path
For standard vSphere Replication, the source ESXi host sends replication traffic to the target vSphere Replication server. Broadcom documents TCP 31031 for this traffic. When network encryption is enabled for the replication group, current Broadcom guidance also calls out TCP 32032.
The relevant test direction is therefore:
source ESXi VMkernel path → target VR Server → TCP 31031
Testing from an administrator workstation, vCenter or the appliance itself does not validate that path. Even a successful ping from the ESXi management interface may be irrelevant when vSphere Replication uses a different VMkernel adapter.
Broadcom’s current article for “No connection to VR server: Unknown” attributes the failure to port 31031 being closed. A separate network-path case documents a more subtle condition: management traffic could reach the appliance, while the dedicated replication VMkernel interface lacked a valid routed path.
Step 1: define the failure scope
Before changing anything, compare affected replications.
- One VM only: check which ESXi host currently runs it, its replication assignment and whether the failure followed a vMotion.
- Several VMs on one host: prioritize that host’s VMkernel selection, route, firewall and uplink.
- All VMs targeting one VR server: prioritize the target server, its listener, intervening firewall and target-side network.
- All replications: check shared infrastructure, service health and any recent network, certificate or appliance change.
Move no production VM merely to hide the symptom. A controlled vMotion can be a diagnostic comparison, but document it as such: if replication starts from a second host, the first host’s path becomes the leading suspect.
Step 2: identify the interface actually used
In vSphere, inspect VMkernel adapters and the enabled service tags for replication traffic. Record:
- VMkernel adapter name;
- IP address and subnet;
- VLAN or port group;
- TCP/IP stack and gateway behavior;
- physical uplink and teaming policy;
- target VR server address.
Do not assume that the default management gateway applies to a dedicated replication network. If source and target are in different subnets, that traffic needs a valid route from the selected stack. The failure described in the Broadcom case was precisely a missing path from the dedicated VMkernel interface even though management connectivity looked healthy.
From the ESXi shell, test the target from the relevant interface where supported:
vmkping -I vmkX VR_SERVER_IP
Replace vmkX and the target with the values observed in the environment. A ping verifies IP reachability only; it does not prove that the TCP listener is available.
Step 3: test the replication port
Broadcom’s troubleshooting procedure uses:
nc -zv VR_SERVER_IP 31031
Run it on the source ESXi host that owns the affected VM. Test the exact target address assigned to the replication, not a management alias chosen from memory.
Interpret the result carefully:
- Timeout: commonly a firewall drop, routing failure or wrong target path.
- Immediate refusal: the host is reachable, but nothing accepts the connection on that address and port, or a device actively rejects it.
- Successful handshake: the basic TCP path works at test time; move to replication mapping, listener health and logs.
If encryption is enabled, validate the additional port documented for that mode. Use Broadcom’s vSphere Replication port reference for the installed architecture instead of opening a generic list of vSphere ports.
Step 4: examine the network between the endpoints
When 31031 times out, compare the intended flow against every enforcement point:
- source VMkernel subnet and route;
- distributed or standard port-group VLAN;
- host uplink and upstream switch;
- inter-VLAN firewall or network security policy;
- destination VR server interface and local policy.
Ask the network team to search for the exact source IP, destination IP, port and timestamp. “The firewall allows vSphere” is not a useful verification. The flow must match the VMkernel source address, not merely the ESXi management address.
If a rule was recently added, confirm both policy and observed traffic. A rule can be correct but unused because the packet leaves with a different source address or follows another route.
Step 5: verify the target and replication assignment
After the network handshake succeeds, confirm that the expected vSphere Replication server is connected and assigned to the replication. Check the appliance and replication UI for:
- server connection state;
- listener/service health;
- target datastore availability;
- replication group registration;
- recent appliance replacement or IP change;
- errors at the same timestamp in replication and ESXi HBR logs.
A stale assignment can produce a valid network connection to the wrong service while the replication group remains unregistered. Preserve group identifiers and timestamps when comparing logs.
DNS, certificates and port 443
DNS and certificates matter to management and registration workflows, but they should be investigated when the evidence points there. Broadcom documents hostname misconfiguration as a cause of HTTP 503 errors during vSphere Replication configuration, which is a different symptom from an ESXi timeout to port 31031.
Likewise, management connectivity over HTTPS does not replace the replication data port. A broad checklist that tests 443, 902 and random service URLs can produce many green results while never testing the failed flow.
Escalate DNS or TLS only when you observe a name mismatch, trust error, registration failure, certificate event or 503-class management failure.
Why restart should not be the first action
Restarting the appliance may temporarily clear a failed listener, but it also interrupts multiple replications and destroys useful transient evidence. Re-registering it can have a larger blast radius and is not a remedy for an absent route.
Before a restart:
- export or preserve relevant logs;
- record which replications and hosts are affected;
- prove that the required TCP path reaches the appliance;
- verify the service state and target assignment;
- understand the recovery effect for all protected VMs.
If the listener is confirmed unhealthy after the network path is good, use the supported service or appliance procedure for the deployed version. Avoid generic Linux service names copied from another release.
Verification after the fix
Do not stop when the UI changes from red to green. Force or wait for a synchronization and confirm:
- TCP connectivity from the original ESXi host;
- replication status becomes active;
- bytes or changed blocks advance;
- recovery point objective returns within policy;
- no repeated HBR warning appears;
- a VM moved back to the original host continues replicating, if a diagnostic vMotion was used.
This workflow turns a vague “Network” error into a bounded test: identify the source host and selected VMkernel path, verify routing, establish TCP 31031 to the assigned VR server, then investigate service and registration state. It is faster and safer than restarting every VMware component in reach.
