yesterday
Public access to the Azure Databricks workspace is currently disabled. Access is required through a Private Link (private endpoint – api_ui).
A private endpoint has already been configured successfully:
An application hosted on a VM in a different Azure VNet needs to access the Databricks workspace. However, the access must be routed through an on-premises proxy server.
The VM hosted in a separate Azure VNet should be able to securely access the Azure Databricks workspace through the on-premises proxy, while ensuring that all traffic is routed via the private endpoint.
yesterday
This is a classic hub-spoke + on-premises hybrid networking scenario. Here's how to architect it end-to-end.
The traffic flow will be:
VM (VNet-App) --> ExpressRoute/VPN Gateway --> On-Prem Proxy Server --> ExpressRoute/VPN Gateway --> VNet-PE-ENDPOINT --> Private Endpoint --> Azure Databricks
You need two connectivity paths -- both going through your on-premises network:
VM VNet (VNet-App) to On-Premises:
On-Premises to Private Endpoint VNet (VNet-PE-ENDPOINT):
Recommended: Hub-Spoke Topology
Rather than connecting each VNet individually, use a hub VNet with a single ExpressRoute/VPN gateway:
VNet-App (spoke) ---peering---> Hub VNet <---peering--- VNet-PE-ENDPOINT (spoke)
|
ExpressRoute/VPN
|
On-Premises Network
(Proxy Server here)
Enable "Allow Gateway Transit" on the hub peering and "Use Remote Gateway" on each spoke peering so all spokes can use the hub's gateway.
The proxy server (e.g., Squid, nginx, or an enterprise proxy like Zscaler/Blue Coat) must be configured to:
Allow HTTPS traffic to Databricks endpoints:
Forward traffic toward the Azure private endpoint IP:
Proxy configuration example (Squid):
# Allow Databricks workspace traffic
acl databricks_hosts dstdomain .azuredatabricks.net
http_access allow databricks_hosts
This is the most important step. The proxy server must resolve Databricks URLs to private IPs, not public IPs.
Option A: Conditional DNS Forwarding (Recommended)
On your on-premises DNS server, configure a conditional forwarder:
Important: Do NOT forward directly to 168.63.129.16 -- this Azure DNS IP only responds to queries from within Azure VNets. You need an intermediary forwarder.
Azure DNS Forwarder options:
Option B: Manual DNS A Records
If conditional forwarding isn't possible, create static A records on your on-premises DNS:
adb-xxxxxxxxxxxx.xx.azuredatabricks.net --> 10.x.x.x (private endpoint IP)
region.pl-auth.azuredatabricks.net --> 10.x.x.x (same private endpoint IP)
Find the private IP from: Azure Portal > Private Endpoint > Network Interface > IP Configuration
Note: Do NOT override accounts.azuredatabricks.net -- the Account Console must resolve publicly.
Configure the VM in VNet-App to route Databricks traffic through the on-premises proxy:
Environment variables (Linux):
export HTTPS_PROXY=http://proxy.onprem.company.com:8080
export HTTP_PROXY=http://proxy.onprem.company.com:8080
export NO_PROXY=169.254.169.254,168.63.129.16
For Databricks CLI or API calls:
export HTTPS_PROXY=http://proxy.onprem.company.com:8080
databricks clusters list --profile my-workspace
For application code (Python example):
import os
os.environ['HTTPS_PROXY'] = 'http://proxy.onprem.company.com:8080'
Ensure Network Security Groups allow the required traffic:
VNet-App NSG (outbound):
On-premises firewall:
VNet-PE-ENDPOINT NSG (inbound to private endpoint subnet):
From the on-premises proxy server:
nslookup adb-xxxxxxxxxxxx.xx.azuredatabricks.net
# Should resolve to the private IP (e.g., 10.x.x.x)
From the VM (through proxy):
curl -x http://proxy.onprem.company.com:8080 \
https://adb-xxxxxxxxxxxx.xx.azuredatabricks.net/api/2.0/clusters/list \
-H "Authorization: Bearer <token>"
|
Component |
Configuration |
|
VNet-App to On-Prem |
ExpressRoute or VPN (via hub VNet peering) |
|
On-Prem to VNet-PE-ENDPOINT |
ExpressRoute or VPN (via hub VNet peering) |
|
DNS Resolution |
Conditional forwarder for privatelink.azuredatabricks.net to Azure DNS Forwarder |
|
Proxy Server |
Allow *.azuredatabricks.net on port 443 |
|
VM Proxy Config |
Set HTTPS_PROXY environment variable |
|
NSGs |
Allow 443 (and 6666, 3306, 8443-8451) between all hops |
|
Validation |
nslookup from proxy + curl from VM through proxy |
The most common failure is DNS resolution. If the proxy resolves the Databricks URL to a public IP instead of the private endpoint IP, the connection will fail because public access is disabled. Always verify with nslookup from the proxy server itself.
yesterday
This is a classic hub-spoke + on-premises hybrid networking scenario. Here's how to architect it end-to-end.
The traffic flow will be:
VM (VNet-App) --> ExpressRoute/VPN Gateway --> On-Prem Proxy Server --> ExpressRoute/VPN Gateway --> VNet-PE-ENDPOINT --> Private Endpoint --> Azure Databricks
You need two connectivity paths -- both going through your on-premises network:
VM VNet (VNet-App) to On-Premises:
On-Premises to Private Endpoint VNet (VNet-PE-ENDPOINT):
Recommended: Hub-Spoke Topology
Rather than connecting each VNet individually, use a hub VNet with a single ExpressRoute/VPN gateway:
VNet-App (spoke) ---peering---> Hub VNet <---peering--- VNet-PE-ENDPOINT (spoke)
|
ExpressRoute/VPN
|
On-Premises Network
(Proxy Server here)
Enable "Allow Gateway Transit" on the hub peering and "Use Remote Gateway" on each spoke peering so all spokes can use the hub's gateway.
The proxy server (e.g., Squid, nginx, or an enterprise proxy like Zscaler/Blue Coat) must be configured to:
Allow HTTPS traffic to Databricks endpoints:
Forward traffic toward the Azure private endpoint IP:
Proxy configuration example (Squid):
# Allow Databricks workspace traffic
acl databricks_hosts dstdomain .azuredatabricks.net
http_access allow databricks_hosts
This is the most important step. The proxy server must resolve Databricks URLs to private IPs, not public IPs.
Option A: Conditional DNS Forwarding (Recommended)
On your on-premises DNS server, configure a conditional forwarder:
Important: Do NOT forward directly to 168.63.129.16 -- this Azure DNS IP only responds to queries from within Azure VNets. You need an intermediary forwarder.
Azure DNS Forwarder options:
Option B: Manual DNS A Records
If conditional forwarding isn't possible, create static A records on your on-premises DNS:
adb-xxxxxxxxxxxx.xx.azuredatabricks.net --> 10.x.x.x (private endpoint IP)
region.pl-auth.azuredatabricks.net --> 10.x.x.x (same private endpoint IP)
Find the private IP from: Azure Portal > Private Endpoint > Network Interface > IP Configuration
Note: Do NOT override accounts.azuredatabricks.net -- the Account Console must resolve publicly.
Configure the VM in VNet-App to route Databricks traffic through the on-premises proxy:
Environment variables (Linux):
export HTTPS_PROXY=http://proxy.onprem.company.com:8080
export HTTP_PROXY=http://proxy.onprem.company.com:8080
export NO_PROXY=169.254.169.254,168.63.129.16
For Databricks CLI or API calls:
export HTTPS_PROXY=http://proxy.onprem.company.com:8080
databricks clusters list --profile my-workspace
For application code (Python example):
import os
os.environ['HTTPS_PROXY'] = 'http://proxy.onprem.company.com:8080'
Ensure Network Security Groups allow the required traffic:
VNet-App NSG (outbound):
On-premises firewall:
VNet-PE-ENDPOINT NSG (inbound to private endpoint subnet):
From the on-premises proxy server:
nslookup adb-xxxxxxxxxxxx.xx.azuredatabricks.net
# Should resolve to the private IP (e.g., 10.x.x.x)
From the VM (through proxy):
curl -x http://proxy.onprem.company.com:8080 \
https://adb-xxxxxxxxxxxx.xx.azuredatabricks.net/api/2.0/clusters/list \
-H "Authorization: Bearer <token>"
|
Component |
Configuration |
|
VNet-App to On-Prem |
ExpressRoute or VPN (via hub VNet peering) |
|
On-Prem to VNet-PE-ENDPOINT |
ExpressRoute or VPN (via hub VNet peering) |
|
DNS Resolution |
Conditional forwarder for privatelink.azuredatabricks.net to Azure DNS Forwarder |
|
Proxy Server |
Allow *.azuredatabricks.net on port 443 |
|
VM Proxy Config |
Set HTTPS_PROXY environment variable |
|
NSGs |
Allow 443 (and 6666, 3306, 8443-8451) between all hops |
|
Validation |
nslookup from proxy + curl from VM through proxy |
The most common failure is DNS resolution. If the proxy resolves the Databricks URL to a public IP instead of the private endpoint IP, the connection will fail because public access is disabled. Always verify with nslookup from the proxy server itself.