virtizik.com
VCF 9.1 Protection & Recovery Troubleshooting

Fixing “Unable to connect host …:443” When Protection & Recovery Uses a .local Domain

My P&R appliance and vCenter were on the same management network, TCP/443 was reachable, and the vCenter credentials were correct — but registration still failed. The actual problem was DNS handling of my home.local domain inside the Photon OS appliance.

Keywords: VCF 9.1, Protection & Recovery, P&R, vCenter, Photon OS, DNS, .local, systemd-resolved, nmctl

The situation

I was configuring VMware Cloud Foundation 9.1 Protection and Recovery in my lab and registering the appliance with my management vCenter, vcsa-b.home.local. The P&R appliance itself was on the same 10.20.10.0/24 management network as vCenter, so I expected this part of the configuration to be straightforward.

P&R appliance
srm-b — 10.20.10.11
vCenter
vcsa-b.home.local — 10.20.10.10
DNS / gateway
10.20.10.1
P&R version
9.1.0.0200 — build 25525235

During the vCenter Connection step, the wizard immediately returned:

Unable to connect host 'vcsa-b.home.local:443'
VCF 9.1 Protection and Recovery vCenter Connection wizard showing Unable to connect host vcsa-b.home.local:443 while vCenter netstat shows an established HTTPS session
The initial P&R configuration failure. The useful clue was on the right side of the screenshot: vCenter already showed an established TCP/443 session from the P&R appliance.

Why I did not treat this as a basic firewall problem

The error text sounds like a straightforward network failure, but the vCenter shell showed an established HTTPS connection from the P&R appliance. That told me the appliance could at least reach vCenter at Layer 3/4.

Same subnet The P&R appliance and vCenter were both on 10.20.10.0/24.
TCP/443 established vCenter showed an active HTTPS session from the P&R appliance.
Registration still failed The wizard could not complete the higher-level vCenter lookup and registration workflow.
Lesson: “Unable to connect host” is a generic message. A successful TCP connection does not prove that DNS, TLS identity, Lookup Service, SSO, or the application-level registration workflow is healthy.

The first concrete failure: DNS resolution

I logged into the P&R appliance and checked its network and resolver configuration. The VAMI showed my DNS server as 10.20.10.1, but the operating system was using the local systemd-resolved stub at 127.0.0.53.

admin@srm-b [ ~ ]$ ls -l /etc/resolv.conf
/etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

admin@srm-b [ ~ ]$ cat /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search home.local

The important test was resolving the vCenter FQDN through the resolver that P&R itself was using:

admin@srm-b [ ~ ]$ nslookup vcsa-b.home.local
Server:         127.0.0.53
Address:        127.0.0.53#53

** server can't find vcsa-b.home.local: REFUSED

And the HTTPS test failed before it ever got as far as TLS:

admin@srm-b [ ~ ]$ curl -vk --connect-timeout 5 https://vcsa-b.home.local/sdk
* Could not resolve host: vcsa-b.home.local
curl: (6) Could not resolve host: vcsa-b.home.local
This was the real break point. The P&R VAMI could display the correct DNS server while applications on the appliance still failed because the local resolver was refusing the .local name.

The root cause: .local handling in Photon OS

My lab uses the DNS suffix home.local. Broadcom documents a VMware Live Recovery 9.x issue where FQDNs ending in .local can fail to resolve from the appliance even though the correct DNS server is configured. The documented symptom is almost identical to mine: the vCenter connection fails and nslookup against 127.0.0.53 returns REFUSED.

Why .local is special: the suffix is reserved for multicast DNS (mDNS). Photon OS and systemd-resolved can therefore treat it differently from an ordinary unicast DNS suffix unless the DNS search/routing domain is explicitly associated with the interface.

Broadcom's KB for this behavior is Article 415597 — “Appliance deployment is unable to resolve .local domain names”.

The fix

I elevated to root and explicitly associated my lab DNS domain with eth0 using the Photon Network Configuration Manager CLI:

su root

nmctl set-dns-domains dev eth0 domains home.local

I then verified that the domain was attached to the interface:

root@srm-b [ /home/admin ]# nmctl show-domains
Search Domains: home.local

INDEX DEVICE               Search Domain
    2 eth0                 home.local

resolvectl status also showed the expected DNS server and domain:

Global
         Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
        DNS Domain: home.local

Link 2 (eth0)
    Current Scopes: DNS
Current DNS Server: 10.20.10.1
       DNS Servers: 10.20.10.1
        DNS Domain: home.local

Validation

After explicitly configuring the DNS domain on eth0, the same lookups that had previously failed started working:

root@srm-b [ /home/admin ]# nslookup vcsa-b.home.local
Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer:
Name:   vcsa-b.home.local
Address: 10.20.10.10

root@srm-b [ /home/admin ]# getent hosts vcsa-b.home.local
10.20.10.10     vcsa-b.home.local

I also queried my DNS server directly to confirm that the DNS record itself had never been the problem:

root@srm-b [ /home/admin ]# nslookup vcsa-b.home.local 10.20.10.1
Server:         10.20.10.1
Address:        10.20.10.1#53

Name:   vcsa-b.home.local
Address: 10.20.10.10
The distinction mattered: 10.20.10.1 had a perfectly good record for vCenter. The failure was between applications on the P&R appliance and the local 127.0.0.53 resolver path.

Registration succeeded

With DNS resolution working, I returned to the Protection and Recovery Appliance Management interface and retried the configuration. This time the process moved past the vCenter connection stage and started creating the required registrations.

Protection and Recovery Appliance Management showing Configuring protection and recovery and Creating registrations
After fixing the DNS domain handling, the P&R appliance successfully advanced to Creating registrations.

The registration then completed successfully and the appliance showed that it was configured with vcsa-b.home.local.

Resolution confirmed: no firewall change, vCenter service restart, certificate replacement, or credential change was required. Correcting DNS handling for the home.local domain allowed P&R to complete its vCenter registration.

Quick troubleshooting checklist

If I hit this again on a VCF 9.x Protection & Recovery appliance, these are the checks I would run first:

1
Confirm basic reachability.
ip route and a TCP/443 test verify that this is not simply routing or firewall.
2
Test DNS through the appliance resolver.
nslookup <vcenter-fqdn> and getent hosts <vcenter-fqdn>.
3
Compare with the DNS server directly.
nslookup <vcenter-fqdn> <dns-server>. If direct DNS succeeds but the local resolver fails, focus on the appliance resolver.
4
Inspect resolver state.
resolvectl status, cat /etc/resolv.conf, and nmctl show-domains.
5
For a .local suffix, explicitly associate the domain with the interface.
nmctl set-dns-domains dev eth0 domains <domain.local>.
6
Retry registration only after name resolution is clean.
This keeps certificate, SSO, and Lookup Service troubleshooting from being mixed with a basic resolver failure.

Commands from the incident

# Network
ip -br addr
ip route

# Resolver configuration
ls -l /etc/resolv.conf
readlink -f /etc/resolv.conf
cat /etc/resolv.conf
resolvectl status
nmctl show-domains

# Test vCenter resolution
nslookup vcsa-b.home.local
getent hosts vcsa-b.home.local
nslookup vcsa-b.home.local 10.20.10.1

# Configure the .local search/routing domain
nmctl set-dns-domains dev eth0 domains home.local

# Verify HTTPS after DNS is healthy
curl -vk --connect-timeout 5 https://vcsa-b.home.local/sdk

Lessons learned

VAMI state is not the whole story Seeing the correct DNS server in the appliance UI does not prove that applications using the local resolver can successfully resolve the same FQDN.
TCP/443 is only one layer An established HTTPS socket can coexist with a failed registration workflow if DNS, certificate identity, Lookup Service, or SSO operations are still failing.
.local deserves extra attention Existing lab domains that use .local can work, but appliances based on Photon OS may require an explicit DNS domain configuration.

In this case, the P&R appliance was on the correct network, vCenter was listening on 443, the credentials were valid, and the DNS record existed. The missing piece was how Photon OS was routing queries for my home.local namespace. Once that was corrected, VCF 9.1 Protection and Recovery registered with vCenter successfully.

Reference

Broadcom KB 415597 — Appliance deployment is unable to resolve .local domain names