Peer site connection and VRA replication fail after the protected site switches to a backup internet line with a different public IP

Peer site connection and VRA replication fail after the protected site switches to a backup internet line with a different public IP

Machine-distilled from a resolved support ticket on 2026-09-28. Source ref: cbf8420afc8f. Verify before relying on it.

Applies to: Zerto in an aggregation or cloud service provider setup where site to site traffic passes through firewalls or a VPN that filter on the customer site's public IP; seen on vSphere, not version specific.

Symptom: The ZVM raises an alert that it cannot connect to the peer site on port 9071, and replication from the affected site stops (VRAs show as unhealthy or disconnected). This happens after the protected site moves to a secondary or backup broadband connection, for example during an ISP outage or when a primary line is ceased. Nothing inside the site has changed except its public (egress) IP address.

Cause: Firewall rules (and in some setups the site to site VPN or tunnel configuration) on the path between the sites only allowed the original public source IP. When traffic started leaving from the backup line's public IP, the rules dropped ZVM to ZVM (port 9071) and VRA replication traffic, so the peer connection and replication failed.

Resolution: 1. Confirm with the customer whether the site's public egress IP has changed, for example because of a failover to a backup line or an ISP change, and get the new address. 2. Check that the protected site's internal addressing (host, VRA and ZVM IPs) has not changed, so the problem is limited to the public IP. 3. Update the firewall source rules for the Zerto ports (including 9071 for ZVM to ZVM and the VRA replication ports) to allow the new public IP. Also update any VPN or tunnel peer configuration that references the old address. The source can be widened to allow all addresses, but adding the specific new IP, or all known public IPs for the site's lines, is preferable for security. 4. Check that the peer site reconnects and that VPGs resync and return to meeting SLA. 5. As a preventive step, include the public IPs of all backup internet lines in the firewall rules in advance, so an ISP failover does not interrupt replication.