Out-of-Band Management, Proxy-Only Egress and a 48-Hour Cutover

The proxy is being blamed before the dependency chain has been checked, and the 11-minute clock skew is a strong suspect on its own: certificate validation of the update server fails if system time is off by more than a few minutes, and the GUI usually reports that as a generic connection failure.

Order of work

1. Time first. Point both devices at the corporate NTP source, confirm the sync state and that both are within a few seconds of each other. Fixing anything else before this wastes a cycle.
2. Name resolution on the management plane only - confirm the DNS servers are reachable from 10.20.5.0/24 and that the update hostname resolves to the expected address.
3. Proxy binding. Verify the proxy is configured for the update/licensing client specifically, not just the web UI, that the device authenticates to it, and that CONNECT on 443 is permitted for that service account.
4. Packet capture on the management interface. No SYN to 10.20.5.10 means routing or DNS. A 407 means authentication. A TLS alert means time or certificate trust. This single capture tells you which of the three you own.
5. Only then re-register the license and pull content, licensing first because content entitlement depends on it.

If the capture shows the SYN leaving with a source other than 10.20.5.x, the temporary default route on the data plane is the culprit - remove it before troubleshooting further.

No. The 'temporary' route is the most dangerous thing in this setup, for three reasons:

• It breaks the segmentation you built the OOB network for. Any compromised workload on 10.10.0.0/16 now has a path straight into the management segment and out through a proxy that was never sized or logged for data-plane traffic.
• It creates a competing default route. Two defaults with similar metrics will flap, and traffic will silently follow whichever wins - the classic cause of 'it works from the test laptop but not from the server'.
• It invites asymmetric routing. Sessions entering via 203.0.113.8 would return via 10.20.5.1 and be dropped as out-of-order.

What to leave behind

• A static default inside the management VRF only, next to a route to 10.20.5.0/24 via its connected interface.
• No route leaking between the management and data virtual routers, with the data-plane default pointing at the real ISP next hop on 203.0.113.9.
• Source NAT and a security policy for any legitimate branch internet traffic, terminated on the untrust interface.

Prove it rather than assert it: dump both route tables, traceroute from the data plane to a public address, and confirm the hop list does not include 10.20.5.1.

Cabling the HA pair is a change-control event, not a step in the build. Before it happens:

• Dedicated HA connectivity. HA1 and HA2 on physically separate paths - a direct cable, or at minimum a dedicated VLAN on separate switches that carries no data traffic. Sharing the data access switch means one switch reboot takes out both heartbeats and you get two active nodes.
• Addressing and identity. HA peer addresses allocated in the management segment, device names and priorities set so the intended node is active, preempt left off until you trust the failover.
• Configuration parity. Licenses and content versions matching, the same policy and objects on both nodes, and the passive confirmed to be receiving state sync before go-live.
• A real failover test with a live session in flight - pull the active's power, confirm the passive takes over, that the session survives if session pickup is enabled, and that management access recovers.

Sequence it this way: fix time and licensing, validate the management path in isolation, remove the temporary data-plane route, then cable HA, then test failover. Doing HA first just multiplies the variables you are debugging.