Communication between subnets in the same virtual network is not working

Question

Communication between subnets in the same virtual network is not working

Kenneth Webb Vargas 0

I have the following configuration on Azure:

Virtual Network: dev-network
Subnets:
- containers: 10.0.0.0/24 delegated to Microsoft.App/environments
- dev-db: 10.0.1.0/24 (A private endpoint exists to connect a PostgreSQL Flexible Server to this subnet)

The containers subnet is associated to an Azure Container Apps Environment where a Container App hosting service A is trying to connect to the PostgreSQL Flexible Server. Every time the service A tries to establish a connection to the PostgreSQL using the FQDN a connect timeout error is thrown.

I've tried a ping from the Container App that host the service A to the PostgreSQL and find out there is no response.

What configuration is required to establish the communication between the two subnets?

Praveen Bandaru 5,215 Reputation points Microsoft External Staff Moderator

2025-05-13T17:47:43.9533333+00:00
Hello Kenneth Webb Vargas

I understand that you're having issues with communication between your subnets in the Azure virtual network.

For further investigation please share the below information:

If you have any VM in the same subnet, please test nslookup and share the screenshot with us.

Also, please test continuous psping and share the results. Check the PsPing public document. " psping -t privateip:portno "

Additionally, please share the screenshot of the networking part of the container app.

Ensure there are no NSG rules blocking traffic. Check that the inbound rules allow traffic between the two subnets. You might want to allow all traffic briefly to test if it resolves the issue.

Your containers subnet is delegated to Microsoft.App/environments. Please ensure it is configured correctly and that no additional restrictions are applied.

Please ensure the private endpoint for PostgreSQL is properly configured and associated with the dev-db subnet. Additionally, the private DNS zone should be linked to the virtual network for accurate name resolution.

You mentioned attempting to ping from your Container App to the PostgreSQL server. If ping is unsuccessful, try using tcping to check specific ports (such as the default PostgreSQL port 5432) to determine if the service is reachable.

If routes are attached on the subnets pointing to any firewall, make sure that firewall rules are created to allow this traffic from source to destination subnets.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Kenneth Webb Vargas 0 Reputation points

2025-05-13T18:13:21.9433333+00:00
Hello,

Here is the information requested:

No VMs exists on the subnets.

PsPing is not available in the Container App shell:

This is the ingress configuration of the container app:

No NSG exists:

The containers subnet configuration doesn't have any additional restrictions:

Private endpoint configuration is mapped to the db-dev subnet and configured to communicate with PostgreSQL:

Private DNS zone linked to the virtual network:

Tcping doesn't exist in the Container App:

No route tables exists:

No Firewalls are configured:
Praveen Bandaru 5,215 Reputation points Microsoft External Staff Moderator

2025-05-13T19:27:07.8366667+00:00

Hello Kenneth Webb Vargas

Thank you for your response.

For testing purposes, please deploy a test VM and perform a nslookup. Share the resolution screenshot with me.

Also, install the psping tool in the VM, test it, and share the results with us.

Additionally, let me know PostgreSQL server are accessible publicly or not ?

Additionally, please check the private messages and share the necessary details in a private message.
Kenneth Webb Vargas 0 Reputation points

2025-05-13T21:56:02.9466667+00:00

Hi Praveen,

I needed to stop the VM creation since I can't connect the VM to the containers subnet:

PostgreSQL is accesible publicly:

1 answer

Your answer

Praveen Bandaru 5,215 Reputation points Microsoft External Staff Moderator

2025-05-13T17:47:43.9533333+00:00

Hello Kenneth Webb Vargas

I understand that you're having issues with communication between your subnets in the Azure virtual network.

For further investigation please share the below information:

If you have any VM in the same subnet, please test nslookup and share the screenshot with us.

Also, please test continuous psping and share the results. Check the PsPing public document. " psping -t privateip:portno "

Additionally, please share the screenshot of the networking part of the container app.

Ensure there are no NSG rules blocking traffic. Check that the inbound rules allow traffic between the two subnets. You might want to allow all traffic briefly to test if it resolves the issue.

Your containers subnet is delegated to Microsoft.App/environments. Please ensure it is configured correctly and that no additional restrictions are applied.

Please ensure the private endpoint for PostgreSQL is properly configured and associated with the dev-db subnet. Additionally, the private DNS zone should be linked to the virtual network for accurate name resolution.

You mentioned attempting to ping from your Container App to the PostgreSQL server. If ping is unsuccessful, try using tcping to check specific ports (such as the default PostgreSQL port 5432) to determine if the service is reachable.

If routes are attached on the subnets pointing to any firewall, make sure that firewall rules are created to allow this traffic from source to destination subnets.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Kenneth Webb Vargas 0 Reputation points

2025-05-13T18:13:21.9433333+00:00

Hello,

Here is the information requested:

No VMs exists on the subnets.

PsPing is not available in the Container App shell:

This is the ingress configuration of the container app:

No NSG exists:

The containers subnet configuration doesn't have any additional restrictions:

Private endpoint configuration is mapped to the db-dev subnet and configured to communicate with PostgreSQL:

Private DNS zone linked to the virtual network:

Tcping doesn't exist in the Container App:

No route tables exists:

No Firewalls are configured:
Praveen Bandaru 5,215 Reputation points Microsoft External Staff Moderator

2025-05-13T19:27:07.8366667+00:00

Hello Kenneth Webb Vargas

Thank you for your response.

For testing purposes, please deploy a test VM and perform a nslookup. Share the resolution screenshot with me.

Also, install the psping tool in the VM, test it, and share the results with us.

Additionally, let me know PostgreSQL server are accessible publicly or not ?

Additionally, please check the private messages and share the necessary details in a private message.
Kenneth Webb Vargas 0 Reputation points

2025-05-13T21:56:02.9466667+00:00

Hi Praveen,

I needed to stop the VM creation since I can't connect the VM to the containers subnet:

PostgreSQL is accesible publicly:

Answer 1

Hello Kenneth Webb Vargas

I understand that you are experiencing an issue connecting the PostgreSQL DB (paas) it is connected via private endpoint from the container apps.

Both the container apps and the SQL DB are in the same VNET but different subnets. Connectivity and resolution work fine from the test VM, but in the container console, the DNS server IP is taking the loopback IP (127.0.0.11) during resolution. However, a forced nslookup resolves successfully.

Results:

/app # nslookup tes**..89os$g&&es.database.azure.com
Server:         127.0.0.11
Address:        127.0.0.11:53
Non-authoritative answer: tes.89os$g&&es.database.azure.com     canonical name = tes..89os$g&&es.privatelink.postgres.database.azure.com
Name:   tes.**.89os$g&&es.privatelink.postgres.database.azure.com

Address: 10.0.1.4

Non-authoritative answer: tes**.89os$g&&es.postgres.database.azure.com canonical name = tes.**.89os$g&&es..privatelink.postgres.database.azure.com

/app # nslookup tes**.***.89os$g&&es..postgres.database.azure.com 168.63.129.16 Server: 168.63.129.16 Address: 168.63.129.16:53

Non-authoritative answer: tes**..89os$g&&es..postgres.database.azure.com canonical name = tes..89os$g&&es.privatelink.postgres.database.azure.com Name: tes.***.89os$g&&es.privatelink.postgres.database.azure.com Address: 10.0.1.4

Non-authoritative answer: tes**.***.89os$g&&es.postgres.database.azure.com canonical name = testmeka-db-dev.privatelink.postgres.database.azure.com

From VM to Postgres sql DB nslookup and psping results

Nslookup:

C:\Users\kwebb>nslookup testmeka-db-dev.postgres.database.azure.com Server: UnKnown Address: 168.63.129.16

Non-authoritative answer: Name: tes**.***.89os$g&&es.v.privatelink.postgres.database.azure.com Address: 10.0.1.4 Aliases: testmeka-db-dev.postgres.database.azure.com

As we determined the issue is within Container App, you have created a new question for this issue here https://learn.microsoft.com/en-us/answers/questions/2275965/communication-from-container-apps-subnet-to-postgr and it is being worked upon by the container app team. After the resolution is achieved, we will add an answer here for community benefit.

Hope the above answer helps! Please let us know do you have any further queries.

Please do consider to “up-vote” wherever the information provided helps you, this can be beneficial to other community members.

Share via

Communication between subnets in the same virtual network is not working

1 answer

Your answer