Azure Key Vault returns 403 with "This TCP connection does not allow access to {host}"

When I attempt to access my Key Vault using a Private Link (or maybe not, not sure), the service returns 403 (Forbidden) with this message:

This TCP connection does not allow access to {host}.

What is causing this?

This can be caused by the following reasons:

Your DNS record to the Key Vault is pointing to the wrong IP address

This is the most common reason. The following steps help diagnosing:

1. Go the virtual machine or client that is getting the error.
2. Run nslookup <key-vault-name>.vault.azure.net or the appropriate command for resolving the IP address (host <key-vault-name>.vault.azure.net for most Linuxes).
3. Make note of the IP address.
4. Using the Azure Portal, open the Key Vault resource and select Networking > Private Endpoint Connections.
5. Click the link under Private endpoint column. This will open the Private Endpoint resource.
6. Click the link at Network interface field. This will open the NIC resource.
7. Check the Private IP address field. That must match the one you got in nslookup or host command in step 2. If that does not match, you have to fix. For detailed instructions, see validate-the-dns-resolution topic of Azure documentation.

Your client, or some proxy you are using, is sending the wrong value at host header in the request to Key Vault

When you access Key Vault, the HTTP host header must always match the Key Vault hostname. This is the default behavior for vast majority of clients, but certain clients allow customization. Also if you use a proxy, the proxy may change this value.

1. Go to Key Vault resource in Azure Portal, and in the Overview tab, check the value of Vault URI property.
2. Extract the hostname from that property. For example, if the vault URI is https://contoso.vault.azure.net/, then the value of host header must be contoso.vault.azure.net.
3. Examine your client or proxy settings. Check for HTTP handlers, proxy handlers, name resolution handlers, etc. Make sure the host header sent to Key Vault service matches the one you captured in step 2.
4. Also make sure your client is really resolving the hostname to the IP address of your Key Vault (see previous section).

Your private endpoint is not in "approved" state, or it is approved but is not successfully provisioned

This is uncommon, but may happen when you migrate from Service Endpoints to Private Endpoints, and the migration is not complete. The following steps help diagnosing:

1. Go to Key Vault resource in the Azure Portal, and select Networking > Private Endpoint Connections.
2. Check if the connection is approved and provisioning state is succeeded. If that is not the case, fix by either approving or re-creating the Private Endpoint resource.
3. If the connection is approved and provisioning is succeeded, click the link below the Private endpoint column. That will open the Private Endpoint resource.
4. Check the properties Provisioning state and Connection status. They must show Succeeded and Approved, respectively. If they don't, you have to either approve or re-create the Private Endpoint resource.
5. If both the values reported in Key Vault resource and Private Endpoint resource are both approved and succeeded, you have to double-check the other possible causes.