Error: No route to host when accessing appliance via VPN after upgrade to Protection and Recovery 9.1.0
search cancel

Error: No route to host when accessing appliance via VPN after upgrade to Protection and Recovery 9.1.0

book

Article ID: 447018

calendar_today

Updated On:

Products

VMware Live Recovery

Issue/Introduction

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

  • 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.0 (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 release 9.1.1 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.