Enhanced replication mapping test fails with Input/Output error and the replication enters Not Active state in VLR 9.0.5

Products

• VMware Live Recovery

Issue/Introduction

Symptoms:

• Unable to configure vSphere Replication between two sites with VMware Live Recovery (VLR) 9.0.5. Replications enter a "Not Active" state, and enhanced replication mappings fail with the below error message

  The source host (id: 'host-#', name: 'hostname') successfully connected to the target broker '#.#.#.#', but there is no network connectivity between the source host 'hostname' and the target host (id: 'host-#', name: 'hostname'). Details: 'Connect: Input/output error'.

• There is a dedicated vmkernel adapter configured for replication on both the source and the target ESXi hosts

• A second VM network adapter is configured on the combined VMware Live recovery appliance to use for incoming replication traffic

• Static routes are configured for the additional network adapter as documented in Configure a Static Route on an Additional VM Network Adapter

• Networking team have confirmed that port 32032 is open between hosts and VR appliances

• Whenever a mapping test is initiated, below events are observed in /var/run/log/hbr-agent.log of source ESXi host

  2026-03-11T09:15:47.577Z In(166) hbr-agent-bin[70088607]: [0x0000006321a28700] info: [Proxy [Group: PING-GID-9d50ba28-1461-4e9b-b033-0556803e069d] -> [#.#.65.14:32032]] [b2c41fad-4fa3-40f1-a43e-bc1d01698022-HMS-1524] Bound to vmk: vmk3 for connection to #.#.65.14:32032
2026-03-11T09:17:02.585Z In(166) hbr-agent-bin[70088607]: [0x0000006321aa9700] error: [Proxy [Group: PING-GID-9d50ba28-1461-4e9b-b033-0556803e069d] -> [#.#.65.14:32032]] [b2c41fad-4fa3-40f1-a43e-bc1d01698022-HMS-1524] Failed to connect to #.#.65.14:32032. Using nic 'vmk3'. Error: Connection timed out
2026-03-11T09:17:02.585Z In(166) hbr-agent-bin[70088607]: [0x0000006321aa9700] error: [Proxy [Group: PING-GID-9d50ba28-1461-4e9b-b033-0556803e069d] -> [#.#.65.14:32032]] [b2c41fad-4fa3-40f1-a43e-bc1d01698022-HMS-1524] Failed to bind to any of the specified VMKs for connection to #.#.65.14:32032
2026-03-11T09:17:02.585Z In(166) hbr-agent-bin[70088607]: [0x0000006321aa9700] error: [Proxy [Group: PING-GID-9d50ba28-1461-4e9b-b033-0556803e069d] -> [#.#.65.14:32032]] [b2c41fad-4fa3-40f1-a43e-bc1d01698022-HMS-1524] Failed to connect to server #.#.65.14:32032 using broker info: Input/output error

• vmkping between replication VMkernel interfaces of the source and target ESXi host succeeds with 0% packet loss

Environment

VMware Live Recovery 9.0.4
VMware Live Recovery 9.0.5

Cause

The target ESXi hosts lacks a specific static route to the source site's replication network, resulting in asymmetric routing. Due to this, the enhanced replication mapping tests fails with the Input/Output error

While ICMP based diagnostics (such as vmkping) may succeed because network switches can often reflect simple echo requests, vSphere Replication requires a successful TCP three way handshake on ports 31031 and 32032. Without a defined return path in the ESXi routing table, the acknowledgment packets are sent via the default gateway (typically vmk0) rather than the dedicated replication interface. This mismatch causes the connection to be rejected or time out, manifesting as an Input/output error in the vSphere Replication interface.

Cause Justification:

The failure is rooted in asymmetric routing at the network layer. Diagnostic analysis of the routing tables confirms a discrepancy between the source and target ESXi host configurations:

In the below illustration, consider source ESXi host replication adapter (vmk3) IP as  #.#.9.1 and target ESXi host replication adapter (vmk3) IP as #.#.65.1

• The source ESXi host has a specific static route for the target replication network (#.#.65.0/24) bound to vmk3. This allows the initial TCP SYN packet to reach the target correctly.
  
  esxcfg-route -l
VMkernel Routes:
Network        Netmask    Gateway              Interface
#.#.3.0      255.#.#.128  Local Subnet              vmk0
#.#.65.0     255.#.#.0    #.#.#.#                   vmk3
#.#.5.0      255.#.#.0    Local Subnet              vmk1
#.#.9.0      255.#.#.0    Local Subnet              vmk3
default      0.0.0.0      #.#.#.#                   vmk0

• Analysis of esxcfg-route -l on the target ESXi host reveals that no specific route exists for the source replication subnet (#.#.9.0/24)
  
  esxcfg-route -l
VMkernel Routes:
Network       Netmask      Gateway              Interface
#.#.77.0      255.#.#.128  Local Subnet             vmk0
#.#.22.0      255.#.#.0    Local Subnet             vmk1
#.#.65.0      255.#.#.0    Local Subnet             vmk3
default       0.0.0.0      #.#.#.#                  vmk0

• When the target host attempts to send the TCP SYN/ACK response, the lack of a specific route forces the stack to use the Default Gateway on vmk0.

• Because the response packet exits via a different interface than the ingress packet, the source host or intermediate firewalls reject the stateful connection. This explains why ICMP succeeds as it does not require a stateful three-way handshake while the vSphere Replication (TCP 32032) connection fails with a Connection timed out and subsequent Input/output error

Resolution

To resolve the connectivity issue, a static route must be added to the target ESXi hosts to ensure the return traffic for the TCP handshake uses the correct replication interface.

1. Log in to the ESXi host via SSH as root.

2. Verify the current routing table:

   esxcfg-route -l

3. Add the required static route for the source replication network on the target ESXi host

   esxcli network ip route ipv4/ipv6 add --gateway <IPv4_address_of_source_router> --network <IPv4_address_destination_network>


4. Verify the route is now present in the routing table.

5. Re-run the replication mapping test.