Troubleshoot Failed External Calls Between App Services Using AppServiceIPSecAuditLogs

[Guest ronelson]

Azure App Service is a cloud-based service that allows developers to deploy and manage web applications. It provides an easy way to host your web applications without worrying about the underlying infrastructure. Sometimes, you may face issues when making external calls between two App Services. In this blog post, we will discuss how to troubleshoot failed external calls between App Services using the App Service IP Sec audit logs.

 

 

 

App Service IP Sec audit logs provide detailed information about the traffic that passes through your IPsec tunnel. This information can be used to troubleshoot issues related to failed external calls between App Services. The audit logs provide details such as source IP address, destination IP address, protocol, and port number.

 

 

 

Azure Monitor Logs reference - AppServiceIPSecAuditLogs | Microsoft Learn

 

 

 

Scenario: The customer has set up a client-server model using VNet integration in Azure. The client is an app service that makes HTTPS requests to a backend-end app service acting as the server. This front-end app service has a private endpoint, which means that it can only be accessed from within the customer's VNet.

 

 

 

To troubleshoot failed external calls between App Services, follow these steps:

 

 

 

Step 1: Enable IP Sec Audit logs, enable IP Sec audit logs, navigate to your App Service and select the "Diagnostic logs" option under the "Monitoring" section. Then, select "IPSecurity Audit logs" and turn on the "Enabled" switch.

 

 

 

Step 2: Select Send to Storage account or Log Analytics workspace.

 

 

 

Step 3: Check Audit logs for CIp, ServiceEndpoint and Details

 

 

 

The CIP field shows the client IP address that initiated the request[1]. The ServiceEndpoint field shows the service endpoint that was accessed[1]. The Details field provides additional information about the request, such as whether it was denied due to public network access[1].

 

azure-docs/troubleshoot-network-connectivity.md at main · MicrosoftDocs/azure-docs (github.com)

 

 

 

CIp":"47.234.195.85:50629"

 

"ServiceEndpoint":"False"

 

"Details":"Denied non-PrivateEndpoint requests for private link enabled due to PublicNetworkAccess"

 

 

 

The error message "Details":"Denied non-PrivateEndpoint requests for private link enabled due to PublicNetworkAccess" means that the request was rejected due to name resolution resolving to a public IP address and the client calling the app service using a public IP address.

 

 

 

CIp":"[fd00::7ca4:6b0c:200:a00:2fe]:50140"

 

"ServiceEndpoint":"True",

 

"Details":"Traffic was received via service tunneling but no private link identifier was provided."

 

 

 

The error message "Details":"Traffic was received via service tunneling but no private link identifier was provided." means that the request was received via service tunneling, but the private link identifier was not provided.

 

 

 

1. Check that the client in a client-server model is using the correct private endpoint DNS name to connect to the app service. The private endpoint DNS name should resolve to the private IP address of the private endpoint of the app service.
   
2. Check that the private endpoint is configured correctly on the server in a client-server model. Make sure that the private endpoint is associated with the correct subnet and virtual network, and that the private DNS zone is configured correctly.
   
3. If the client in a client-server model uses custom DNS servers and is in an ASEv3 environment, App Service Environment v3 doesn't fall back to Azure DNS if your configured custom DNS servers in the virtual network are not able to resolve a given name. If this behavior is required, ensure that you have a forwarder to a public DNS or include Azure DNS in the list of custom DNS servers. Migrate to App Service Environment v3 by using the migration feature - Azure App Service Environment | Microsoft Learn
   

 

Continue reading...