This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .
What's communicating with what? What are the various IP addresses involved when App Service Linux container talks to a remote resource (e.g., Databases)? From the remote end of the connection, would I see a private IP or Public IP as the Linux Container source address?
Let's explore!
Given -
- A VNet Integrated App Service Linux app.
- Remote Azure resource (VM in this case; Private IP 10.1.0.4, public IP obfuscated) to connect to.
Open an SSH session from Azure Portal to App Service Linux app container.
Case #1
Ping public IP (obfuscated) from app container.
Network packets captured at app container.
Result -
Simultaneous network packet capture at the remote Azure resource (VM).
Result -
The IP address obfuscated with indigo colour (screenshot above) is an outbound IP address for the App Service Webspace.
Note: An App Service app runs in an App Service plan, and App Service plans are deployed into one of the deployment units in the Azure infrastructure (internally called a webspace). Each deployment unit is assigned a set of virtual IP addresses, which includes one public inbound IP address and a set of outbound IP addresses.
Inbound/Outbound IP addresses - Azure App Service | Microsoft Learn
Case #2
Ping VM Private IP 10.1.0.4 from app container.
When pinging from App container, packets have been captured on the remote resource (VM). This is shown in screenshot below. You may notice that the destination is the Private IP of the VM, and the Source (app container) shows up having another private IP 10.0.0.126.
Observations and explanation -
- What is this Source IP 169.254.254.0/24 range?
If you check the network interfaces (e.g., ifconfig command), you will notice an interface starting with 'vnet' as shown below. This interface is assigned an IP from this range (container specific network).
2. Why does the simultaneous packet capture (Case #1) on remote Azure resource show Source as a public IP (obfuscated in indigo color)?
This public IP is an outbound IP address for App Service app. By default, routable (public) traffic will be routed via one of the outbound IP addresses for App Service. This outbound IP becomes the 'From' address for any remote resource that's communicating with App service.
3. When App service communicates with the Private IP (in contrast to Public IP) of the remote resource, what is this another App service private IP 10.0.0.126 that shows up in trace (Case #2)?
The Source is the Private IP that got assigned to the VNet interface as result of VNet integration. You can confirm it from the following page for your app -
https://<yoursite>.scm.azurewebsites.net/newui/env
You can also check it by doing an SSH to container and printing variable value as shown in screenshot below.
How do I apply this knowledge? Where does this all help us in practical scenarios?
Well, now at this point, I hope you are comfortable understanding the different IP addresses involved here.
This information may help you, for example, troubleshooting TCP channel/SSL connectivity. The screenshot below depicts a successful TCP and SSL handshake between App Service Linux container and MySQL Database (it could be any other remote resource as well that requires SSL).
While connecting to a DB, the handshakes above were captured from Azure Portal SSH session on Linux App Service app container using following command (to stop capturing, press Ctrl + C) -
Tcpdump -i any -s0 -w handshakes.pcap
As another example, this might also help you investigate when app container is dealing with misconfigured DNS settings.
Showing below a typical DNS query from app container to Azure DNS attempting to resolve 'A' record.
(The Azure DNS Virtual Server IP address is 168.63.129.16
Reply from Azure DNS shows it failed to resolve 'A' record as only CNAME type is returned -
After fixing configuration, the type 'A' record is resolved and the IP address is returned by Azure DNS -
The scenarios above were randomly taken to demonstrate how we can apply this knowledge to practical usage. You may apply it to a broader spectrum of scenarios as you see fit. Thanks for reading.