"Error: No route to host or network configuration failure in VCF 9.1 Protection and Recovery (Includes Firstboot Deployment)"

Products

• VMware Live Recovery

Issue/Introduction

After upgrading VMware Live Recovery to Protection and Recovery version 9.1.x, the appliance becomes unreachable for users connecting via a VPN network.

During initial 'firstboot' deployment of Protection and Recovery 9.1.x, the appliance network configuration may fail to apply if the management network overlaps with the RFC 1918 (172.16.0.0/12) Docker network bridge used by the appliance. This manifests as an inability to apply the correct FQDN, with the appliance defaulting to a 'photon-uuid' hostname instead of the FQDN.

• Users on VPN subnets in the 172.16.0.0/12 range receive "No route to host" or timeout errors when accessing URL of appliance.
• The appliance functions as intended when accessed from other networks.
• Running ip route on the appliance shows bridge networks (br-####) utilizing the 172.17.x.x or 172.18.x.x ranges.

Environment

• Protection and Recovery 9.1.x (Live Site Recovery)
• VPN infrastructure using subnets within 172.16.0.0/12

Cause

During the upgrade to VLSR 9.1.0, the appliance deploys Docker containers for Data Protection and monitoring services. The default Docker bridge networks provisioned in the docker-compose.yaml files overlap with the 172.16.0.0/12 subnet, creating a routing conflict that prevents external VPN traffic from reaching the appliance host.

Resolution

This issue is fixed in next release and higher

Additional Information

Workaround

To restore connectivity in version 9.1.0, modify the Docker configuration to use host networking mode.

1. Take snapshot of appliance. Does not need to be an offline snapshot
2. Log in to the Protection and Recovery (VLSR) appliance as admin via SSH or console and sudo root account
3. Edit the snapservice compose file: vi /opt/vmware/etc/snapservice/docker-compose.yaml
4. Locate the snapservice-appliance-config section and add the following line: network_mode: host
   • The line should be added after the labels section and should look like this:
     

       snapservice-appliance-config:
         image: harbor-repo.packages.vcfd.broadcom.net/snapservice/snapservice-appliance-config:9.1.0.0
         labels:
           com.vmware.dpca.service-name: "snapservice"
           com.vmware.dpca.config: ""
           com.vmware.dpca.db: ""
         network_mode: host    ####Add the line here

5. Edit the monitoring compose file: vi /opt/vmware/etc/dp-monitoring/docker-compose.yaml
   • The line should be added after the labels section and should look like this:
     

       dp-monitoring-appliance-config:
         image: harbor-repo.packages.vcfd.broadcom.net/dp-monitoring/dp-monitoring-appliance-config:9.2.0.0
         labels:
           com.vmware.dpca.service-name: "dp-monitoring"
           com.vmware.dpca.config: ""
           com.vmware.dpca.db: ""
         network_mode: host    ####Add the line here

6. Clean up the existing conflicting containers and networks:
   

   docker container prune
   docker network prune

7. Rebuild the container configurations:
   

   docker compose -f /opt/vmware/etc/snapservice/docker-compose.yaml up --no-start
   docker compose -f /opt/vmware/etc/dp-monitoring/docker-compose.yaml up --no-start

8. Restart the appliance to apply all changes.

9. For customers encountering this during firstboot deployment:

   1. Manual intervention via nmctl is required to persist network settings within the Photon OS environment.
   2. Verify settings persist across reboots.
   3. Update the appliance certificate to match the manually configured FQDN to allow for successful vCenter registration.

   Note: This issue is expected to be addressed in next version release. Future deployments should verify that the management network does not conflict with the internal Docker IP range (172.16.0.0/12) to ensure native deployment success