ITQ VCF 9.1 Deployment Planning

Reference

Binary Depot — Offline Depot & the VCF Download Tool

The binary depot the platform installs and patches from — online, offline (air-gapped), or manual transfer — plus the VCF Download Tool that populates it and the proxy the fleet may need to reach it. The prerequisites gate states what must exist; this page covers how to build and feed it. Companion page: SFTP Backup Target — the target every management component backs up to.

Contents

#SectionUse it when
1Three ways to feed binariesChoosing: online depot, offline depot, or manual transfer
2Setting up an offline depotThe site has no internet path to Broadcom
↳ Step 1 — Depot web serverSizing and certifying the box
↳ Photon OS variant (offline build)Air-gapped nginx install (ISO/RPM), serve the store, iptables — end to end
↳ Step 2 — Auth splitWhat to protect with basic auth, and what must stay open
↳ Step 3 — VCF Download ToolGetting the tool
↳ Step 4 — Activation codeStart here early — the Product Administrator role takes days
↳ Step 5 — Download the binariesThe actual binaries download / esx download runs
↳ Step 6 — Transfer to the air-gapped serverMoving the store across the gap intact
↳ Step 7 — Connect VCF to itPointing the Installer (and later the fleet) at the depot
3Manual transfer — feeding the VCF Installer without a depot serverYou have no depot server at all and need bits on the Installer
4Using the Download Tool standalonePulling binaries without standing up a depot
5Proxy for the VCF services runtimeThe fleet has no direct internet — set the G5 proxy on the runtime via the Fleet LCM API (+ tools/ scripts)
↳ Gotcha: precheck is a netcat test from the whole node blockPrecheck times out even with the documented access — firewall the whole services-runtime block
6ReferencesThe TechDocs behind the above

1. Three ways to feed binaries

Pick one (intake G1):

  • Online depot — VCF Installer (and later the fleet) connect to the Broadcom depot directly using the Download Service ID + Activation Code (intake G2/G3; how to obtain them — and the Product-Administrator-role gotcha — is in §2 step 4). Needs outbound 443 to the Public URLs table (via the proxy from intake G5 if there is one — for the fleet’s own proxy, set on the VCF services runtime, see §5). TechDocs: Connect VCF Installer to Broadcom or an Offline Depot and Download Binaries.
  • Offline depot — for air-gapped sites the VCF Download Tool is the only supported method in 9.1. It downloads a depot store on an internet-connected host; your own web server serves that store to the VCF Installer and the fleet. The tool replaced the old Offline Bundle Transfer Utility (OBTU) and wraps UMDS for ESX patch data. TechDocs: Download Binaries to an Offline Depot by Using the VCF Download Tool.
  • Manual transfer — no depot at all: run the VCF Download Tool on any internet-connected machine, copy the depot store onto the VCF Installer appliance itself and import it there. No web server to build — best for a one-off install; see §3 for the steps and the Day-N caveat. TechDocs: Manually Transfer Binaries to VCF Installer.

2. Setting up an offline depot

Step 1 — Depot web server

A Linux or Windows VM (any distribution), static IP (DNS record recommended), a dedicated disk for the depot store (sizing below), and any web server (Apache, NGINX) serving HTTPS with TLS 1.2/1.3. Give it a certificate with the FQDN and IP as SANs — signed by your CA, or self-signed if you accept the trust-import step (step 7 below).

Generating the cert (self-signed). The gotcha: modern clients — the VCF Installer included — ignore the CN and read only the subjectAltName, so a cert with just a CN is rejected even though it looks valid. Put the FQDN and the IP in the SANs:

mkdir -p /etc/nginx/ssl
openssl req -x509 -newkey rsa:2048 -nodes -days 825 \
  -keyout /etc/nginx/ssl/depot.key -out /etc/nginx/ssl/depot.crt \
  -subj "/CN=depot01.sfo.example.io" \
  -addext "subjectAltName=DNS:depot01.sfo.example.io,IP:10.11.10.20"
chmod 600 /etc/nginx/ssl/depot.key

-addext needs OpenSSL 1.1.1+ (Photon 4/5 both have it). For a CA-signed cert instead, swap -x509 … -out depot.crt for -new … -out depot.csr, hand the CSR to your CA, and drop the returned cert in as depot.crt. Once the cert is in place and referenced in the server block, load it with nginx -t && systemctl reload nginx (a running nginx re-reads its certs on reload; restart works too). A self-signed cert means the VCF Installer must trust it — see step 7.

HTTP depot (9.1) — skips the cert, but drops auth and the UI. VCF 9.1 added support for an offline depot served over plain HTTP (the VCF Installer and the Fleet Depot Service). It avoids the certificate entirely, but two things change: there is no authentication — an HTTP depot is anonymous (the Step 2 auth split exists only on HTTPS, as the Installer UI itself notes: “Authentication is supported only with an HTTPS offline depot”) — and the Installer UI will not register an HTTP depot; you must use the VCF Installer API. On nginx it is just listen 80; with no ssl_* and no auth_basic (open 80 instead of 443 in iptables). Only worth it on a locked-down segment where an unauthenticated depot is acceptable; otherwise stay on HTTPS + a self-signed cert + the step 7 trust-import. Ref: William Lam, New HTTP Offline Depot Support for VCF Installer & Fleet Depot Service.

Disk sizing. Start around 300 GB for the initial INSTALL depot (the bring-up bundles + component OVAs + ESX ISO). Broadcom’s own recommendation is to provision ≥ 1 TB, and that headroom is real rather than padding: the store grows every Day-N patch cycle — the fleet Depot Service side-loads too (see the §3 Day-N caveat) — on the order of a few GB per ESX patch pull. So build on ~300 GB, provision the 1 TB. No authoritative content footprint is published; 300 GB is a field starting point, not a hard minimum.

Ports. The only listening port the platform needs on the depot server is inbound TCP 443 (HTTPS) — the web server. The clients that pull from it are the same “Needed by” set as the Public URLs table, just pointed at your depot instead of Broadcom: the VCF Installer at bring-up, then the SDDC Manager / VCF Operations depot services runtime / vCenter for Day-N patching. Open 443 to the depot from the management network and the whole services-runtime block — the fleet Depot Service pulls from there, the same “firewall the block” lesson as the proxy in §5. No inbound 80 is required; serve HTTPS only (an 80 → 443 redirect is optional convenience, not a requirement). Outbound: the depot box needs none — unless it is also the internet-connected host running the VCF Download Tool, in which case it needs outbound TCP 443 to the Broadcom Public URLs. An air-gapped depot (store copied in) makes no outbound connections.

Photon OS variant (offline build)

Photon is a natural pick for the depot box — lightweight and VMware-native — but it is a minimal image, and it is usually the air-gapped box, so the generic “tdnf install nginx, point a web server at the store” needs spelling out. End to end:

1. Install nginx — offline. The box typically has no internet, so tdnf needs a local source. Two ways, no internet required either way:

  • From the Photon ISO (no second machine). Photon ships a preconfigured photon-iso repo pointing at file:///mnt/cdrom/RPMS. Mount the full ISO the appliance was built from (the minimal ISO may not carry nginx), refresh the cache, and install from it alone:

    mkdir -p /mnt/cdrom && mount /dev/cdrom /mnt/cdrom   # or: mount -o loop photon-full-<ver>.iso /mnt/cdrom
tdnf makecache
tdnf install --disablerepo=* --enablerepo=photon-iso nginx

  • Or pre-download on an online Photon of the identical version/arch, copy the RPMs across (scp / USB), and install locally — deps resolve among them:

    # online box:      tdnf install --downloadonly --downloaddir=/root/nginx-rpms nginx
# air-gapped box:  cd /root/nginx-rpms && tdnf install ./*.rpm

    (If the box can reach the proxy from §5, set proxy= in /etc/tdnf/tdnf.conf and just tdnf install nginx.)

2. Create the store directory — this is what you serve, and what the Download Tool writes into (pass it as --depot-store in Step 5):

mkdir -p /var/www/offline_depot
chown -R nginx:nginx /var/www/offline_depot && chmod -R a+rX /var/www/offline_depot

nginx runs as the nginx user, so it must be able to read the tree; Photon has no SELinux, so there is no doc-root labeling step you would hit on RHEL.

3. Serve it over HTTPS with the Step 2 auth split. Add a server block to the http { } of /etc/nginx/nginx.conf (or /etc/nginx/conf.d/depot.conf if it includes conf.d):

server {
    listen 443 ssl;
    server_name depot01.sfo.example.io;        # must be in the cert SANs
    ssl_certificate     /etc/nginx/ssl/depot.crt;
    ssl_certificate_key /etc/nginx/ssl/depot.key;
    ssl_protocols       TLSv1.2 TLSv1.3;

    root      /var/www/offline_depot;          # the --depot-store dir
    autoindex on;                              # directory listing — handy to verify the tree

    # Step 2 auth split: protect COMP + metadata; HCL + UMDS stay open
    location /PROD/COMP     { auth_basic "VCF Depot"; auth_basic_user_file /etc/nginx/.htpasswd; }
    location /PROD/metadata { auth_basic "VCF Depot"; auth_basic_user_file /etc/nginx/.htpasswd; }
    # /PROD/vsan/hcl and /umds-patch-store have no auth_basic -> open, as required
}

Create the basic-auth user without htpasswd (it ships in httpd-tools, absent on the minimal image) — generate the hash with openssl and write the line:

printf 'depotuser:%s\n' "$(openssl passwd -apr1)" > /etc/nginx/.htpasswd
chmod 640 /etc/nginx/.htpasswd && chown root:nginx /etc/nginx/.htpasswd

4. Open inbound 443 in iptables. Photon’s default firewall allows only SSH (22) inbound and drops ICMP, so the rule must be added and persisted or it is lost on reboot:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT
iptables-save > /etc/systemd/scripts/ip4save   # Photon's iptables persistence file
systemctl restart iptables

(Add iptables -A INPUT -p icmp -j ACCEPT before saving if you also want the box to answer ping for reachability tests — see the ICMP note in Backup Target §3.)

5. Start + verify:

nginx -t && systemctl enable --now nginx
curl -k https://depot01.sfo.example.io/PROD/vsan/hcl/            # open      -> 200
curl -k -u depotuser https://depot01.sfo.example.io/PROD/COMP/  # protected -> prompts

Everything else — the cert SANs, the auth-split rationale (Step 2), and connecting VCF (Step 7) — is the same as the generic build.

Step 2 — Auth split

Protect PROD/COMP and PROD/metadata with basic auth (htpasswd); leave PROD/vsan/hcl and umds-patch-store open. The umds-patch-store directory name is hardcoded — don’t rename it.

Step 3 — VCF Download Tool

Download it from the Broadcom Support Portal (My Downloads → VMware Cloud Foundation → your version → Drivers & Tools) and extract it on an internet-connected host — the depot server itself if it’s allowed out, otherwise any staging machine.

Step 4 — Activation code

From 9.1, whatever connects to Broadcom for binaries (VCF Installer, a software depot, the Download Tool) must be registered in the VCF Business Services console — the authoritative how-to is Software Depot Registration in the VCF Business Services Console (per-component registration sub-pages). For the Download Tool: generate a software depot ID with the tool (./vcf-download-tool configuration generate --software-depot-id), then log in to the console, select the tenant + site ID that map to your VCF entitlement, and generate the activation code against that depot ID. Save the code to a text file for the --depot-download-activation-code-file flag. (Code not appearing? — KB 399124.)

Token vs. activation code: Broadcom is mid-transition. The older download token (support portal → My Dashboard → Generate Download Token, see KB 390098) still works for 9.1 downloads — the 9.0-era tool took it as a download-token file — but the activation code is the go-forward mechanism that replaces the token workflow.

Get the credential early: generating either requires the Product Administrator role on the Broadcom support-portal site. If your named contact doesn’t have it, the site’s User Administrator must assign it first — plan days for this, not minutes.

Don’t confuse it with the licensing activation code. VCF 9 also uses an activation code to register VCF Operations with the licensing service (vcf.broadcom.com) for the single fleet license file — a separate credential from the depot-download one, generated in its own registration wizard. The activation/registration model is explained in the VMware blog Licensing in VMware Cloud Foundation 9.0 (Sehjung Hah & Kyle Gleed).

Step 5 — Download the binaries

Into the depot store (the web server’s document root, or a staging directory):

./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.x \
  --depot-download-activation-code-file /path/activation-code.txt \
  --type INSTALL --depot-store /var/www/offline_depot

./vcf-download-tool esx download \
  --depot-download-activation-code-file /path/activation-code.txt \
  --depot-store /var/www/offline_depot

binaries list (same flags) previews what a run will pull; --type UPGRADE fetches lifecycle bundles for Day-N patching.

NSX Edge nodes need no extra binary. There is no separate NSX Edge bundle in the depot — the edge node OVA ships inside the NSX Manager appliance (NSX_T_MANAGER, already part of the --type INSTALL set), and NSX Manager deploys the edge VMs itself when you create an edge cluster after bring-up. The Broadcom edge-cluster prerequisites are network/resource-only (Edge TEPs, uplinks, DNS, BGP) and never mention the depot, and the depot component list confirms it (see William Lam’s depot structure deep-dive). An air-gapped depot loaded per this section therefore already covers a later edge-cluster deployment; Day-N, edge nodes are upgraded through the NSX upgrade bundle (--type UPGRADE), not a separate download.

Behind a proxy? Use the tool’s own flags — the shell env vars are ignored. http_proxy/https_proxy have no effect; the Download Tool reads only its own options. Add --proxy-server <FQDN:Port> (-s, no http:// scheme). The symptom without it is Fail to obtain access token from Broadcom OAuth Authorization server plus name-resolution errors — because with a proxy the proxy resolves the Broadcom names, not the depot box:

./vcf-download-tool binaries download --sku VCF --vcf-version 9.1.x \
  --depot-download-activation-code-file /path/activation-code.txt \
  --type INSTALL --depot-store /var/www/offline_depot \
  --proxy-server proxy01.sfo.example.io:3128

If the proxy is an HTTPS proxy, add --proxy-https — which first requires the proxy’s certificate imported into the tool’s JRE default trust store. If it authenticates, add --proxy-user <user> (-r) and --proxy-user-password-file <path>. (The depot … upload subcommands cannot use the proxy filter.)

Gotcha — Failed to get last updated time for HCL. Even once the proxy works the download can fail here: the tool queries vsanhealth.vmware.com for the vSAN HCL and chokes. Fix is an endpoint swap — change vsan.hcl.client.endpoint=vsanhealth.vmware.com to vsan.hcl.client.endpoint=eapi.broadcom.com in both conf/application-prod.properties and conf/application-prodV2.properties, then retry. Broadcom KB 438222.

(Re)apply the Step 2 security after the download. The binaries download creates and refreshes the depot’s PROD/… tree, so the Step 2 auth split has to be applied once the store is populated — not before — protecting PROD/COMP and PROD/metadata while leaving PROD/vsan/hcl and umds-patch-store open. Do it again after every Day-N --type UPGRADE refresh, since each run rewrites the tree. Re-verify with the curl checks (open paths return 200, protected paths prompt) and confirm the web-server user can still read the newly written files.

Step 6 — Transfer to the air-gapped server

Move the depot store to the air-gapped web server if the download host is a separate machine — the directory tree (PROD/COMP, PROD/metadata, PROD/vsan/hcl, umds-patch-store) must arrive intact under the document root.

Step 7 — Connect VCF to it

Point the VCF Installer at the depot URL (e.g. https://depot.sfo.rainpole.io/) with the basic-auth user (intake G4). The Installer must trust the depot’s TLS certificate — with a self-signed or internal-CA cert, plan the certificate import (in 9.0 there was no accept-certificate prompt; the cert had to be imported over SSH — see the vTam walkthrough below). Day-N, the fleet connects under VCF Operations → Depot Configuration (fleet-level and per-instance).

3. Manual transfer — feeding the VCF Installer without a depot server

For a one-off installation (lab, PoC, or a small air-gapped site) you can skip building the depot web server entirely: download the depot store with the VCF Download Tool on any internet-connected machine, copy it onto the VCF Installer appliance, and import it locally. “Manual” means no depot server — not hand-picked downloads: the binaries still come exclusively through the VCF Download Tool + activation code (§2 steps 3–4 apply unchanged); pulling OVAs/ISOs by hand from the support portal is not a supported substitute in 9.1.

  1. Download the install set on the internet-connected machine — §2 step 5’s binaries download --type INSTALL command, with --depot-store pointing at a local staging directory. Metadata comes with it; plan the same order of disk space.

  2. Copy to the Installer — put the Download Tool itself on the appliance (extract the .tar.gz under /nfs/vmware/vcf/nfs-mount/vcfdt) and transfer the staged store:

    rsync -aP /path/to/binaries vcf@installer-fqdn:/nfs/vmware/vcf/nfs-mount/depot

  3. Import on the appliance — save the admin@local password to a text file, then:

    ./vcf-download-tool binaries upload --depot-store /nfs/vmware/vcf/nfs-mount/depot \
  --sddc-manager-fqdn installer-fqdn --sddc-manager-user admin@local \
  --sddc-manager-user-password-file /path/to/password.txt

    Once the upload finishes, the Installer shows the binaries as available and deployment proceeds as normal — no depot configured anywhere.

Day-N caveat (new in 9.1). After bring-up the fleet runs its own Depot Service, and with no depot connected, patch/upgrade binaries must be side-loaded there too — a second upload per cycle (vcf-download-tool depot binaries upload --ops-fqdn <vcf-ops-fqdn> --depot-fqdn <fleet-depot-fqdn>, optionally per --component). In 9.0 this extra step didn’t exist. Manual copies at every patch cycle get tedious fast — beyond a lab or one-off, the offline depot (§2) is the smoother long-term setup. Walkthrough incl. the Fleet Depot Service step: William Lam’s Side-loading VCF binaries into VCF Installer & Fleet Depot Service.

4. Using the Download Tool standalone

You don’t need to be air-gapped to use the tool. Run it on any internet-connected machine with the same activation-code file to pre-stage binaries locally — for example to pull the --type INSTALL set before an installation window, or ESX patch data via its built-in UMDS, without letting the VCF appliances out to the internet. Whatever machine runs it needs outbound 443 to the Public URLs — plan that host’s egress (or proxy allowlist) as part of the prereq gate.

5. Proxy for the VCF services runtime (via the Fleet LCM API)

When the VCF Management Services components have no direct route to the internet, the fleet reaches the online depot (and everything else it downloads) through a proxy set on the VCF services runtime — the VSP component in Fleet lifecycle. This is the G5 proxy referenced in §1, applied to the fleet rather than the Installer. TechDocs: Configure a Proxy Server for VCF Management Services Components and VCF Automation.

The TechDocs procedure reads as a wall of curl/jq token-juggling; underneath it is short. It’s the same Fleet LCM API pattern as the backup config in Backup Target §5, so the field notes there apply here too.

The flow, distilled:

  1. Authenticate through VCF Operations (the only issuer the Fleet lifecycle service trusts):

    • POST https://<VCFOps>/suite-api/api/auth/token/acquire (username/password) → an OpsToken
    • POST https://<VCFOps>/suite-api/api/auth/token/exchange with header Authorization: OpsToken <token> and body {"serviceKeys":["fleet-lcm"]} → the Fleet LCM Bearer JWT

  2. Find the runtime: GET https://<FleetLCM>/fleet-lcm/v1/components → the component whose componentType is VSP, take its id.

  3. Set the proxy: PATCH https://<FleetLCM>/fleet-lcm/v1/components/<vspId>/config

    {
  "type": "VspClusterConfigSpec",
  "peerProxy": {
    "host": "10.11.10.250",
    "port": 3128,
    "tlsEnabled": false,
    "credentialsEnabled": false
  }
}

    Returns a task id.

  4. Watch / verify: GET .../fleet-lcm/v1/tasks/<taskId>, then GET .../fleet-lcm/v1/components/<vspId>/config.

Optional peerProxy fields: username + password (with credentialsEnabled: true for an authenticating proxy), encodedCertificate (base64 PEM, with tlsEnabled: true for an HTTPS proxy), and excludeDomains / excludeIpAddresses for no-proxy bypasses.

Set the exclusions — a bare proxy sends everything out. With only a host and port, all of the services runtime’s HTTP egress is forced through the proxy, including traffic that must stay on the management network: the other VCF appliances (vCenter, NSX, SDDC Manager, VCF Operations) and — the one that bites in an air-gapped build — your on-prem offline depot. At best that adds a hop; at worst the proxy refuses to route the internal/RFC1918 destination and the connection fails. So set:

  • excludeDomains — your internal DNS suffix(es), e.g. sfo.example.io, so every internal FQDN bypasses the proxy.
  • excludeIpAddresses — the management / services-runtime CIDRs and the subnets holding vCenter/NSX/SDDC Manager/VCF Operations, plus the offline depot’s IP or subnet so bundle pulls stay internal.

With the scripts: -ExcludeDomains 'sfo.example.io' -ExcludeIpAddresses '10.11.0.0/16','<depot-ip>'. They ride the same merge PATCH, so re-running Set-VCFProxyConfig.ps1 adds them alongside the existing host/port; confirm with Get-VCFProxyConfig.ps1 (empty exclude lines mean everything is being proxied).

Three traps worth knowing (all cost time to discover):

  • Go straight to the fleet appliance, not the VCF Operations proxy route. The browser sends this to https://<VCFOps>/vcf-operations/plug/fleet-lcm/..., but that path is the user interface’s session-authenticated route (it works because the browser holds a JSESSIONID cookie). A Bearer-token client gets 405 on a PATCH there and HTML on a GET. Both the lookup and the write go to https://<FleetLCM>/fleet-lcm/v1/..., where the token is accepted — the same lesson as the backup write (Backup Target §5, and issue #150).
  • Skip the /casa/services service-key lookup. The TechDocs procedure fetches a service key from <VCFOps>/casa/services with a hard-coded Basic-auth header; you don’t need it. The fleet-lcm service key is just the literal string "fleet-lcm" in the exchange body (proven live by the backup scripts).
  • port is a number here. In VspClusterConfigSpec the proxy port is a JSON number (3128), unlike the SFTP backup payload where port is a string. Send the wrong type and validation rejects it.

The two scripts in tools/ do exactly this, reusing the backup scripts’ auth chain — download them straight from the site:

ScriptWhat it does
Get-VCFProxyConfig.ps1Read-only. Shows the peerProxy the platform actually stored on each VSP (VCF services runtime) component. Changes nothing
Set-VCFProxyConfig.ps1Sets the proxy through the API. -WhatIf prints the exact payload (secrets masked) without sending it; supports an authenticating proxy (-ProxyUsername), a TLS proxy (-CertificateFile), and -ExcludeDomains / -ExcludeIpAddresses; -Remove clears it by sending explicit empty values (blank host, port 0) — the Fleet LCM PATCH is a merge, so a null peerProxy is a silent no-op (task completes, nothing changes). Verify with Get-VCFProxyConfig.ps1 afterwards

Gotcha: the precheck is a netcat test from the whole node block — even when the documented access is in place

Setting the proxy is not the end of it. The PATCH is accepted (you get a task ID), and the platform then runs a peer-proxy-precheck workflow on the VCF services runtime. If that precheck fails, the proxy is never applied — the config submit stores nothing, exactly like the backup submit in Backup Target §5. And the failure the platform surfaces is misleading: “the proxy server may be slow, overloaded, or network latency is too high.”

What the precheck actually does — read it yourself. Get a kubectl session on the control-plane node (recipe in Backup Target §6 — SSH in as root, kubectl is already wired up), then:

kubectl -n vmsp-platform get pods | grep peer-proxy-precheck        # the failing Error pods
kubectl -n vmsp-platform logs <peer-proxy-precheck-...-main-pod> -c main --tail=200

The log shows it is a plain L4 nc (netcat) TCP connect to the proxy host:port — no auth, no TLS, pure reachability:

Testing TCP port connectivity/reachability using nc (netcat)
nc: connect to 10.11.10.250 port 3128 (tcp) failed: Connection timed out
Proxy connectivity test failed: 10.11.10.250:3128

The gotcha: that nc runs from a pod that can be scheduled on any VCF services-runtime node, and its egress SNATs to that node’s IP. So the source of the proxy connection is the entire services-runtime node block — not the depot or VCF Operations IPs. Broadcom’s documented access for the proxy does not call this out, so the firewall gets opened only for the depot + Ops IPs (the hosts you’d expect to use a download proxy), the precheck lands on a node that isn’t permitted, and it times out. This is the same trap as the backup target in Backup Target §5: firewall the block, not the named hosts you think talk to it.

Fix: allow the whole services-runtime node block outbound to the proxy on its port (e.g. TCP 3128). List the exact source IPs to hand the network team with:

kubectl get nodes -o wide      # the INTERNAL-IP column = the source IPs to allow

Then re-submit (Set-VCFProxyConfig.ps1 again, or let the platform retry) and the nc check passes. Because it is L4-only, an authenticating (credentialsEnabled) or TLS (tlsEnabled) proxy still has to clear this reachability gate first — fix the firewall before chasing credentials or certificates.

6. References