Troubleshoot connection to a project with a private endpoint
Important
Items marked (preview) in this article are currently in public preview. This preview is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
When connecting to a project that has been configured with a private endpoint, you may encounter a 403 or a messaging saying that access is forbidden. Use the information in this article to check for common configuration problems that can cause this error.
Securely connect to your project
To connect to a project that's secured behind a VNet, use one of the following methods:
Azure VPN gateway - Connects on-premises networks to the VNet over a private connection. Connection is made over the public internet. There are two types of VPN gateways that you might use:
- Point-to-site: Each client computer uses a VPN client to connect to the VNet.
- Site-to-site: A VPN device connects the VNet to your on-premises network.
ExpressRoute - Connects on-premises networks into the cloud over a private connection. Connection is made using a connectivity provider.
Azure Bastion - In this scenario, you create an Azure Virtual Machine (sometimes called a jump box) inside the VNet. You then connect to the VM using Azure Bastion. Bastion allows you to connect to the VM using either an RDP or SSH session from your local web browser. You then use the jump box as your development environment. Since it is inside the VNet, it can directly access the workspace.
DNS configuration
The troubleshooting steps for DNS configuration differ based on whether you're using Azure DNS or a custom DNS. Use the following steps to determine which one you're using:
In the Azure portal, select the private endpoint resource for your Azure AI Studio. If you don't remember the name, select your Azure AI Studio resource, Networking, Private endpoint connections, and then select the Private endpoint link.
From the Overview page, select the Network Interface link.
Under Settings, select IP Configurations and then select the Virtual network link.
From the Settings section on the left of the page, select the DNS servers entry.
- If this value is Default (Azure-provided), then the VNet is using Azure DNS. Skip to the Azure DNS troubleshooting section.
- If there's a different IP address listed, then the VNet is using a custom DNS solution. Skip to the Custom DNS troubleshooting section.
Custom DNS troubleshooting
Use the following steps to verify if your custom DNS solution is correctly resolving names to IP addresses:
From a virtual machine, laptop, desktop, or other compute resource that has a working connection to the private endpoint, open a web browser. In the browser, use the URL for your Azure region:
Azure region URL Azure Government https://portal.azure.us/?feature.privateendpointmanagedns=false Microsoft Azure operated by 21Vianet https://portal.azure.cn/?feature.privateendpointmanagedns=false All other regions https://portal.azure.com/?feature.privateendpointmanagedns=false In the portal, select the private endpoint for the project. From the DNS configuration section, make a list of FQDNs listed for the private endpoint.
Open a command prompt, PowerShell, or other command line and run the following command for each FQDN returned from the previous step. Each time you run the command, verify that the IP address returned matches the IP address listed in the portal for the FQDN:
nslookup <fqdn>
For example, running the command
nslookup df33e049-7c88-4953-8939-aae374adbef9.workspace.eastus2.api.azureml.ms
would return a value similar to the following text:Server: yourdnsserver Address: yourdnsserver-IP-address Name: df33e049-7c88-4953-8939-aae374adbef9.workspace.eastus2.api.azureml.ms Address: 10.0.0.4
If the
nslookup
command returns an error, or returns a different IP address than displayed in the portal, then your custom DNS solution isn't configured correctly.
Azure DNS troubleshooting
When using Azure DNS for name resolution, use the following steps to verify that the Private DNS integration is configured correctly:
On the Private Endpoint, select DNS configuration. For each entry in the Private DNS zone column, there should also be an entry in the DNS zone group column.
If there's a Private DNS zone entry, but no DNS zone group entry, delete and recreate the Private Endpoint. When recreating the private endpoint, enable Private DNS zone integration.
If DNS zone group isn't empty, select the link for the Private DNS zone entry.
From the Private DNS zone, select Virtual network links. There should be a link to the VNet. If there isn't one, then delete and recreate the private endpoint. When recreating it, select a Private DNS Zone linked to the VNet or create a new one that is linked to it.
Repeat the previous steps for the rest of the Private DNS zone entries.
Browser configuration (DNS over HTTPS)
Check if DNS over HTTP is enabled in your web browser. DNS over HTTP can prevent Azure DNS from responding with the IP address of the Private Endpoint.
- Mozilla Firefox: For more information, see Disable DNS over HTTPS in Firefox.
- Microsoft Edge:
Proxy configuration
If you use a proxy, it may prevent communication with a secured project. To test, use one of the following options:
- Temporarily disable the proxy setting and see if you can connect.
- Create a Proxy auto-config (PAC) file that allows direct access to the FQDNs listed on the private endpoint. It should also allow direct access to the FQDN for any compute instances.
- Configure your proxy server to forward DNS requests to Azure DNS.
- Ensure that the proxy allows connections to AML APIs, such as ".<region>.api.azureml.ms" and ".instances.azureml.ms"
Troubleshoot configurations on connecting to storage
When you create a project, a number of connections to Azure storage are auto-created for data upload scenarios and artifact storage including prompt flow. When your hub's associated Azure Storage account is having public network access set to 'Disabled', there may be a delay in these storage connections to be created.
Try the following steps to troubleshoot:
- In Azure Portal, check the network settings of the storage account that is associated to your hub.
- If public network access is set to Enabled from selected virtual networks and IP addresses, ensure the correct IP address ranges are added to access your storage account.
- If public network access is set to Disabled, ensure you have a private endpoint configured from your Azure virtual network to your storage account with Target sub-resource as blob. In addition, you must grant the Reader role for the storage account private endpoint to the managed identity.
- In Azure Portal, navigate to your AI Studio hub. Ensure the managed virtual network is provisioned and the outbound private endpoint to blob storage is Active. For more on provisioning the managed virtual network, see How to configure a managed network for Azure AI Studio hubs.
- Navigate to AI Studio > your project > project settings.
- Refresh the page. A number of connections should be created including 'workspaceblobstore'.