@PhilRawlings1 -
The timeout is happening in the network path, not in DNS. Your error already shows a resolved IP (3.232.90.132) for va-activation-global.secure-api.infra.identitynow.com, so name resolution is working fine. Something between the VA and that address on port 443 is dropping the connection rather than rejecting it, which is what “dial tcp … i/o timeout” means in Go’s HTTP client, as opposed to a “connection refused” or a TLS/certificate error.
*.secure-api.infra.identitynow.com is on SailPoint’s documented outbound allowlist for VAs, so the destination itself is legitimate and required. A few things worth having your network/firewall team check specifically, since “outbound 443 is open” in general isn’t the same as “this exact host is reachable”:
Is the firewall rule for *.secure-api.infra.identitynow.com built on the hostname/SNI, or on a specific IP that got hard-coded after being observed once? SailPoint doesn’t publish static IPs for this endpoint (unlike the separate Network Tunnel VA configuration, which does list fixed IPs per region). If the rule was written against an old IP, it breaks whenever that address rotates behind SailPoint’s load balancer, and it looks exactly like this: DNS resolves fine, the TCP handshake just never completes. See the system and network requirements.
Is all outbound traffic from that VA’s network forced through an explicit proxy? If so, confirm the VA was actually bootstrapped with the proxy flags: va-bootstrap set-passphrase --http-proxy <host:port> --https-proxy <host:port>, and the same on va-bootstrap pair. A VA that wasn’t told about the proxy will attempt a direct connection, and a default-deny egress firewall will typically just drop that silently instead of returning a clean error, again matching what you’re seeing. Flags are documented on the VA configuration page.
To isolate VA software from network path: SSH into the VA itself (inbound 22 is what’s documented as needed for that) and run a plain connectivity test against the same host and port, e.g. curl -v https://va-activation-global.secure-api.infra.identitynow.com/activation/code or openssl s_client -connect ``va-activation-global.secure-api.infra.identitynow.com:443. If that also hangs, the block is confirmed to be in your network path, not the VA build, and redeploying with a newer image won’t fix it. If it connects cleanly from the shell but the VA’s own pairing process still times out, the outdated-image angle you mentioned becomes worth chasing. There’s a similar thread where a VA stuck after pairing turned out to be an old image, and redeploying fixed it, but that case was stuck in Draft after a successful pair, not timing out during the activation call itself, so I wouldn’t jump to a redeploy first here.
Low-probability but cheap to rule out: the VA’s own network shouldn’t sit in 10.255.255.241/28 or 172.16.0.0/22. SailPoint documents both as ranges that break VA connectivity outright, regardless of firewall rules.
Thanks for your detailed response. I look into those points today.
Something I should have clarified in my original post is that this was a fully functioning VA. To be able to use the new functionality that only comes with the new clusters, I de-linked it from the old cluster, and its the re-pairing that is causing the issue.
We are experiencing similar errors on our setup. Since Sept 2nd, our previously functioning VA is on critical error state and the firewall team was able to monitor connection to this URL:va-activation-global.secure-api.infra.identitynow.com as blocked.
*BTW we are using Tunneling.
So,
Rebuilt the VM with a brand new Image. It made no difference what so ever.
However, this command ‘va-bootstrap set-passphrase’ successfully sets the passphrase, and this command ‘va-bootstrap pair’ successfully pairs the VA to the cluster. You just need to ignore the error message in between.