Hello @And2 , I took a look at both internal and external documentation and here is what I found.
This looks like an inspection or outbound policy problem rather than a missing control plane IP range. Every failed entity came back with curl (35) "Connection reset by peer" during the TLS handshake, not the curl (28) timeout you'd see if a route or NSG rule were missing. A timeout means the packets never arrived. A reset means something in the path accepted the TCP handshake and then tore the session down. With a Palo Alto in the path, that points at the firewall.
Two things about the allow list. First, with secure cluster connectivity enabled, the Control Plane NAT ranges aren't in play; they're only used when SCC is disabled. What SCC needs is outbound access to the relay by FQDN. Your error shows eastus2-c3.azuredatabricks.net, so your relay is tunnel.eastus2c3.azuredatabricks.net, and Databricks is explicit about allowing it by domain name because the IPs behind it change. Second, none of the failing destinations live in the ranges you allowed. The artifact storage accounts (arprodeastus2aN, plus dbartifactsprodeastus, the East US secondary) resolve to Azure Storage addresses, and www.databricks.com is plain internet. An IP-only rule built from the control plane table can't cover them.
Two likely reset sources on the Palo Alto: a security policy that lets the SYN through, identifies the destination from the SNI via App-ID or URL filtering, then hits a deny with a reset action; or SSL Forward Proxy decryption, which the cluster nodes won't trust because they don't carry the firewall's CA. The Databricks troubleshooting guide calls out SSL inspection directly and notes it won't show as a drop at the network layer.
What I'd do, in order:
- Pull the Palo Alto session log for one failing hostname, say
arprodeastus2a6.blob.core.windows.net. That's the fastest discriminator. If the firewall is the reset source, the session end reason (policy-deny, decrypt-error, and so on) tells you which fix applies. If there's no session at all, move on to DNS, UDR propagation, the Databricks-managed NSG rules (make sure they haven't been deleted or overridden), and the return path through your next hop.
- Confirm from a VM in the Databricks subnet, on the same UDR, DNS, and firewall path:
curl -v https://eastus2-c3.azuredatabricks.net. If plain curl fails and curl -k succeeds, or openssl s_client -showcerts shows a cert from your corporate CA, decryption is the culprit. If both fail with a reset, it's the security policy.
- Replace the IP rules with FQDN address objects (or an EDL) covering the full East US 2 list, applied from both workspace subnets: webapp, SCC relay, artifact Blob storage primary and secondary, log Blob storage, metastore on 3306, Event Hubs on 9093, your DBFS root storage account, and
www.databricks.com. The complete list is in the IP addresses and domains doc below.
- Add a no-decrypt rule for those destinations from the Databricks subnets, and make sure SNI and return traffic are preserved.
Resist the temptation to open all internet as a workaround. If your design allows it, the cleaner long-term answer is service tags in the UDR (AzureDatabricks, Storage, EventHub) so this traffic goes straight out. If you scope Storage by region, the secondary artifact storage is in East US and one log storage account is in West US, so include those regions too.
References:
Regards,
Louis
