Failing to adjust Front Door (Premium) to talk HTTPS to private CAs via Private Link

Hi, Sleiman Bassim

Thanks for the heads-up! I’ll wait to hear back from you later today.

Still, I am not succeeding.

• the nslookup is returning the wrong IP (public address) when hitting <app>.internal<location>azurecontainerapps.io
• the DNS zone's A record is correctly pointing to the private IPv4 of the dedicated subnet. And correctly showing succeeded and completed links to the vnet.
• no duplicate zones, so no conflicts in resolutions
• AFD has the correct origin definition pointing to the ingress FQDN

Hi @Sleiman Bassim

I just wanted to follow up and see if you had a chance to review my response to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Thank you Venkat. I confirm that your health checklist for AFD and PEC are correctly configured as described.

• vnet-dev is where all ACAs reside and connected to the right ACA env
  
• vnet-dev has the right dedicated subnet for the PEC
  
• PEC
  
• Private links checked for all origin groups in AFD
  
• The origin host names for each AFD origin group are also correctly pointing to the respective ACAs using the ingress FQDN. (AFD is set up with bicep)

Cheers

I hope you have followed the steps outlined in this doc Create a private link to an Azure Container App with Azure Front Door.

Hi, Sleiman Bassim

I tested the same in my lab environment, and it worked as expected.

container app ingress settings

**
ADF origin Settings

Container app Environment settings
**

Note: Make sure to approve the private link origin request in the environment settings to provide access to AFD

Private endpoint connection

If you create a private endpoint in the container app environment, you will receive an additional endpoint request from AFD origin that needs to be approved in order to allow access from the AFD endpoint.

Nslookup result from same Vnet
**

After configuring all the settings, when I try to access the container app using the AFD endpoint, I am able to access it as shown below.

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

Hi, Sleiman Bassim,

I just wanted to follow up and see if you had a chance to review my response to your question. Please let us know if it was helpful, and feel free to reach out if you have any further queries.

Hi Venkat,

Late response due to european holidays.

Even though the ACAs are configured like yours, the nslookup isnt returning the subnet IP. Ingress FQDNs are correctly set as internal and configured with origins hosts in AFD group origins. Including the PECs. Endpoints approved, no pending endpoints.

There is one step that differ from your test app/env/PEC (although i did see youve set up vnet) and the MS tutorial you shared with me. Im using a vnet and subnet. The tutorial is asking to disable Vnet on the ACAs.

Maybe here is the misconfiguration on my end. My ACAs are running in a dedicated subnet. The PEC in another. What do you think, subnet misconfiguration of the PEC with AFD? Because, if I use the portal and create a dummy AFD with Quick Create, the system automatically assigns 3 new PECs with 1 ACA set as origin. In my bicep, I have 2 origins and one PEC gets created.

ENV_ID=$(
  az resource show \
    --resource-group "$RG" \
 --resource-type "Microsoft.App/managedEnvironments" \
 --name "rg-dev-sponsored-env" \
 --query id -o tsv
)

az network private-endpoint create \
 --resource-group "$RG" \
  --name "$PE_NAME" \
 --vnet-name "$VNET_NAME" \
  --subnet "$SUBNET" \
 --private-connection-resource-id "$ENV_ID" \
  --group-ids "managedEnvironments" \
  --connection-name "${PE_NAME}-conn"

Below, expected configs:

Hi Sleiman Bassim

As I can see, you are selecting the container app environment as External instead of Internal.Make sure to select the ACA type as Internal and then set the Ingress traffic to be limited to the VNet.

I hope this is helpful! Do not hesitate to let me know if you have any other questions.

Done.

Issue: It was the External flag over the ACAs environment set with --internal-only true when creating the env with az cli. Although the flag is correctly set in the azure pipeline files, the env was originally created through az cli and without it.

Having an env as internal (correct choice), the 2 ingress options change and I get the second rule limiting traffic to Vnet.

Then switching in the bicep files the ingress to external: true, only publishes the ACAs on the internal load balancer IP so all services on my vnet would reach it (opposite to when env was external, external: false would be the correct secure option).

Thank you for your commitment to help me find the missing piece.

Cheers