Public Container App cannot communicate with On-premise resources via VPN

Question

Public Container App cannot communicate with On-premise resources via VPN

CreatiXx 25

Hi all,

I'm running into an issue and i cant seem to find the right documentation. I'm trying to setup a Container App that needs to be publicly available but also needs to be able to get feedback from on-premise resources through a VPN.

I've done the following :

Made 2 resource groups
1. 1 for networking
2. 1 for everything regarding the application/container app
In my RG for networking i made :
1. Virtual Network
2. Address space
3. Multiple subnets
Public IP address
VPN Gateway (which works)
Local network gateway
Connection
Routing Table (connected to subnet allocated for container app)
1. Made a route that sends on-prem traffic to the VPN gateway
Network security group (connect to subnet allocated for container app)
1. inbound & outbound rules that allow trafic to and from the on-premise subnets
For my container RG i did the following :
1. Made a container app environment thats connected to my vnet and dedicated subnet
2. Made a container app with an image from github (works)

This is where i am stuck, i think i did everything correct and the VPN seems to work (says connected on both sides) but i dont see any traffic. The app is approachable but now i need it to be able to communicate with on-premise resources as well.

Does anyone know what i can/need to do now?

Thanks in advance!

Rupesh Asati 1,020 Reputation points Microsoft External Staff Moderator

2025-10-07T15:52:18.6633333+00:00

Hello CreatiXx

Please provide the details in private message for us to investigate further.

Thanks
Jeevan Shanigarapu 3,355 Reputation points Microsoft External Staff Moderator

2025-10-07T18:10:34.1366667+00:00
Hello @CreatiXx,

Welcome to Microsoft Q&A Platform. Thank you for reaching out & hope you are doing well.

I understand your question about Public Container App cannot communicate with On-premises resources via VPN. Thank you for providing all the details. It appears that most of the environment has been set up correctly. The VPN connection is working, but the traffic issue is probably caused by some configuration gaps that can occur with hybrid setups like this.

Your setup appears to be correct, but traffic issues could be caused by a few typical factors:

Incorrect or missing DNS settings.

The route table may not be directing on-premises traffic to the VPN gateway.

NSG rules might be blocking inbound or outbound traffic.

Ingress could be set to public-only, which would prevent private routing through the VPN.

Need to verify the following steps:

Verify VNet Integration__:__ Ensure that your Container App Environment is configured with the appropriate subnet in the VNet, and check that the route table for that subnet directs on-premises traffic to the VPN gateway.

Check the NSG rules: Ensure that both inbound and outbound traffic are permitted for your on-premises IP ranges and verify that there are no deny rules that might override these permissions.

Activate internal access: If the container app only requires outbound connections to on-premises resources, it should function properly as long as routing and NSGs are configured correctly. If on-premises systems also need to connect inbound to the app, set up internal ingress or create a private endpoint, since public ingress will not route through the VPN.

Verify DNS resolution: If the app accesses on-premises resources using hostnames, you will need a custom DNS solution, such as Azure Private DNS or forwarding your on-premises DNS through the VPN.

Conduct testing and confirm results: From the container app, use curl or similar tools to test connectivity to on-premises IP addresses.

In the Azure Portal, check Network Watcher → Effective Routes to verify that your subnet routes are configured correctly.

References:

Steps to provide a virtual network to an Azure Container Apps environment:

Integrate a virtual network with an Azure Container Apps environment | Microsoft Learn

Azure VPN gateway: About Azure VPN Gateway | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.
CreatiXx 25 Reputation points

2025-10-08T08:03:50.96+00:00
@Rupesh Asati - done

@Jeevan Shanigarapu

checking this atm but everything seems to be IP based instead of DNS (DNS is set zo Azure Provided in the vnet)

Route Table has 1 rule at

Address prefix : on-premise ip range

Next hop type : Virtual network gateway

Next hop IP address : empty

NSG has 3 default outbound and 3 default inbound rules with 1 custom inbound rule and 1 custom outbound rule where i do a temporary allow any in both directions

Inbound Rule - Allow

Port : Any

Protocol : TCP

Source : on-premise IP range

Destination : Subnet dedicated to Container Apps

Outbound rule - Allow

Port : Any

Protocol : TCP

Source : Any

Destination : on-premise IP range

Ingress is currently set up to public and this is also what trips me. To my knowledge it has to be set to public so it can be reached from the outside (which it needs to be) but just as you said, it prevents privating routing what it also needs so what should be done in this situation? Also just to be sure, we're talking about Ingress of the container app right? I've provided my POV
Jeevan Shanigarapu 3,355 Reputation points Microsoft External Staff Moderator

2025-10-08T20:26:58.5766667+00:00
Hello @CreatiXx,
Good day.

Thank you for providing detailed follow-up and configuration details. From your description, it appears that your VPN, routing, and NSG rules are set up correctly. The main issue seems to be related to how Azure Container Apps manages ingress and routing. The problem is likely due to the Ingress configuration, which determines how traffic reaches your app.

Azure Container Apps supports two types of ingress:

Public Ingress: Allows access from the internet but does not support private traffic.

Internal Ingress: Limits access to your VNet and allows private communication, including via VPN connections.

Since your app is currently using Public Ingress, it is accessible from the internet but not through the private VPN connection.

To support both public access and private (VPN) communication, you have two design options:

Set up or update the Container App Environment to include Internal Ingress for on-premises communication.

You can maintain Public Ingress for external access and utilize a Private Endpoint or Application Gateway to securely connect both access types.

3. Maintain public ingress for external users and use VNet integration along with internal ingress or a private endpoint for traffic routed through VPN.

Check the routing in Network Watcher → Effective Routes to ensure that the subnet is directing on-premises traffic to the VPN gateway.

Connectivity Testing: From your container app, you can use tools such as curl or ping (if available) to check direct IP communication with on-premises resources.

For more information on Ingress in Azure, please refer the below link: Ingress in Azure Container Apps | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.
CreatiXx 25 Reputation points

2025-10-09T10:02:27.7066667+00:00

Hi @Jeevan Shanigarapu

How do i do your first option because it does confuse me quite a lot?

Set up or update the Container App Environment to include Internal Ingress for on-premises communication.

I've tried looking it my CAE but i dont understand what including internal ingress means and how it fits in my situation.
Jeevan Shanigarapu 3,355 Reputation points Microsoft External Staff Moderator

2025-10-09T19:38:14.2033333+00:00
Hello @CreatiXx,

Thank you for your follow-up and for checking your Container App Environment (CAE). I understand the confusion around “internal ingress.” I have provided the troubleshooting steps below, please run those steps to fix the issue.

Resolving Outbound Connectivity Issues to On-Prem:

Based on your information, the VPN, routing, and NSGs appear to be set up correctly. The issue is likely due to incomplete VNet integration or route propagation between the Container App Environment and the VPN gateway.

Here is the process to check and resolve the issue:

1. Verify VNet Integration:

Go to Azure portal, navigate to Container Apps Environment → Networking

Confirm:

o   The Virtual Network is your networking RG’s VNet.

o   The Subnet is a dedicated /27+ with delegation to Microsoft.App/environments.

o   Outbound type is set to VNet integration.

If these don’t match, you may need to edit or recreate the CAE to use the correct subnet.

2. Verify Effective Routes:

Go to Network Watcher (for your region) → Connection Troubleshoot.

Source: A VM in the same subnet as your CAE.

Destination: an on-prem IP address.

Run the test and review Effective Routes.

Ensure the on-prem IP range routes to the Virtual Network Gateway.

If not, associate the route table with your CAE subnet under Route tables → Associated subnets → Add.

3. Outbound Test from the Container App:

You can run an outbound test directly:

az containerapp exec --name <app-name> --resource-group <rg> --command "/bin/sh"

curl <on-prem-ip>:<port>

(Use ping if ICMP is allowed.) If it fails, check Log Stream in the portal under Container App → Monitoring → Log Stream for outbound errors.

4. NSG / UDR Review:

NSG: Ensure outbound traffic from your CAE subnet to the on-prem range is allowed (both TCP and UDP if needed).

UDR: Confirm no default route (0.0.0.0/0) is overriding the VPN route.

Once the above checks are in place, your Container App should be able to reach on-prem resources over the VPN while still being publicly accessible for external users.

Kindly let us know if the above helps or you need further assistance on this issue.
CreatiXx 25 Reputation points

2025-10-10T08:28:06.0266667+00:00
Hi @Jeevan Shanigarapu

Thanks a lot for the continued support, i really appreciate it!

So to answer all of your points in order :

VNet Integration

Virtual network : VNeT_OurSetup (Networking_RG)

Subnet : a subnet dedicated for containers (/24 and within Networking_RG)

Virtual IP : External

Infrastructure resource group : Networking_RG

Public Network Access : Enable : Allows incoming traffic from the public internet

I cannot seem to find Outbound type within the portal?

Effective Routes

You say : "A VM in the same subnet as your CAE" but all documentation and resources confirm that you cannot have a VM in the same subnet as Container Apps because a Container App Environment needs its own dedicated subnet which is why i created a /24 subnet dedicated to containers.

Since i also have no VM's in place because the only thing we wish to run is a single container app i cannot do this testing.

When i go to my Route Table that i made which is within "Networking_RG" AND has the subnet dedicated to containers and i go to Help -> Effective routes, i see nothing. Presumably because there are no network interfaces.

NSG/UDR

Regarding these 2, they're pretty straight forward. NSG has 2 custom rules, 1 inbound and 1 outbound.

Inbound : "Allow-OnPrem-To-CAE" -> Port : Any -> Protocol : TCP -> Source : On-Premise IP range -> Destination : ContainerDedicatedSubnet -> Action : Allow

Outbound : "Allow-To-OnPrem" -> Port : Any -> Protocol : TCP -> Source : Any -> Destination : On-Premise IP range -> Action : Allow

UDR has 1 route : "On-Premise ip-range" -> Next Hop type : VirtualNetworkGateway

I am only working with one resource in my environment and that is 1 CAE with 1 Container App, no VM's or servers or whatsoever. I seem to have everything in place to make this work :

Networking

Local Network Gateway

Network Security Group

Public IP Address (for the VPN)

Route Table

Storage account (for some logs but there is no current network traffic)

Virtual Network (with 3 subnets, 1 dedicated to containers, 1 reserve and 1 for GatewaySubnet)

Virtual Network Gateway

Connection

Application

1 Container App Environment with VNeT integration

1 Container App

1 Log Analytics Workspace

I seem to be missing something small but i just cant pin point what exactly.

Answer accepted by question author

0 additional answers

Your answer

Rupesh Asati 1,020 Reputation points Microsoft External Staff Moderator

2025-10-07T15:52:18.6633333+00:00

Hello CreatiXx

Please provide the details in private message for us to investigate further.

Thanks
CreatiXx 25 Reputation points

2025-10-08T08:03:50.96+00:00

@Rupesh Asati - done

@Jeevan Shanigarapu

checking this atm but everything seems to be IP based instead of DNS (DNS is set zo Azure Provided in the vnet)

Route Table has 1 rule at

Address prefix : on-premise ip range

Next hop type : Virtual network gateway

Next hop IP address : empty

NSG has 3 default outbound and 3 default inbound rules with 1 custom inbound rule and 1 custom outbound rule where i do a temporary allow any in both directions

Inbound Rule - Allow

Port : Any

Protocol : TCP

Source : on-premise IP range

Destination : Subnet dedicated to Container Apps

Outbound rule - Allow

Port : Any

Protocol : TCP

Source : Any

Destination : on-premise IP range

Ingress is currently set up to public and this is also what trips me. To my knowledge it has to be set to public so it can be reached from the outside (which it needs to be) but just as you said, it prevents privating routing what it also needs so what should be done in this situation? Also just to be sure, we're talking about Ingress of the container app right? I've provided my POV
Jeevan Shanigarapu 3,355 Reputation points Microsoft External Staff Moderator

2025-10-08T20:26:58.5766667+00:00

Hello @CreatiXx,
Good day.

Thank you for providing detailed follow-up and configuration details. From your description, it appears that your VPN, routing, and NSG rules are set up correctly. The main issue seems to be related to how Azure Container Apps manages ingress and routing. The problem is likely due to the Ingress configuration, which determines how traffic reaches your app.

Azure Container Apps supports two types of ingress:

Public Ingress: Allows access from the internet but does not support private traffic.

Internal Ingress: Limits access to your VNet and allows private communication, including via VPN connections.

Since your app is currently using Public Ingress, it is accessible from the internet but not through the private VPN connection.

To support both public access and private (VPN) communication, you have two design options:

Set up or update the Container App Environment to include Internal Ingress for on-premises communication.

You can maintain Public Ingress for external access and utilize a Private Endpoint or Application Gateway to securely connect both access types.

3. Maintain public ingress for external users and use VNet integration along with internal ingress or a private endpoint for traffic routed through VPN.

Check the routing in Network Watcher → Effective Routes to ensure that the subnet is directing on-premises traffic to the VPN gateway.

Connectivity Testing: From your container app, you can use tools such as curl or ping (if available) to check direct IP communication with on-premises resources.

For more information on Ingress in Azure, please refer the below link: Ingress in Azure Container Apps | Microsoft Learn

Kindly let us know if the above helps or you need further assistance on this issue.
CreatiXx 25 Reputation points

2025-10-09T10:02:27.7066667+00:00

Hi @Jeevan Shanigarapu

How do i do your first option because it does confuse me quite a lot?

Set up or update the Container App Environment to include Internal Ingress for on-premises communication.

I've tried looking it my CAE but i dont understand what including internal ingress means and how it fits in my situation.

Answer 1

Praveen Bandaru 9,245 Microsoft External Staff Moderator

Hello CreatiXx Thank you for your response.

Please check your VPN gateway configuration to ensure that all your on-premises IP address pools are properly whitelisted in the LNG.
Also, verify that all parameters are correctly configured on both sides, as missing configurations may cause issues. In the meantime, please try to check from the VM inside the azure connectivity working or not if inside the azure working at that time you can check from on-prem setup.
Run connectivity tests from your Container App to verify it can access the on-premises resources, using tools such as curl or ping.
Also, review the NSG rules to make sure they match your requirements. Confirm that both inbound and outbound traffic is permitted for the relevant IP ranges and that no deny rules are causing issues.

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

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

CreatiXx 25 Reputation points

2025-10-14T07:27:41.14+00:00

Hi Praveen,

As based on our conversation i found the culprit in my situation.

I make use of Basic VPN SKU (route-based) with IPsec IKEv2 and through testing i found out that our on-premise VPN was configured as "Initiator" meaning that on-prem resources had to start the VPN connection for it to work.

We found this out by hosting a test VM in Azure and trying to connect through it via VPN. This worked and as a consequence my container app worked as well which finally could reach on-prem resources. We're still playing with some configurations but this was basicly the issue we ran into.

Note : This whole time both Azure VPN Gateway & On-Premise VPN said that the connection was live, this is what made it confusing and why i skipped over it.
CreatiXx 25 Reputation points

2025-10-15T15:07:28.33+00:00
Extra feedback

Azure VPN Gateway route-based vs pfSense policy-based

My main VPN config/setup was the issue, as mentioned above & earlier we make use of Azure Virtual Network Gateway (Basic SKU) but we also use pfSense as our FW. The issue is that pfsense works (or atleast ours did) with policy-based ipsec.

Azure VPN Gateway uses route-based which creates the exact issue we were having, phase 2 ipsec could not communicate in the right manner.

Solution

Make a Phase 1 IPsec in pfSense as you'd know or from pfsense documentation

Preshared key

IKEv2

Remote Gateway : Azure Virtual Network Gateway Public IP

Correct Encryption

Make a Phase 2 - This is very important, according to pfSense documentation you need to come up with an unused /30 subnet. Unused by either on-premise or Azure! Come up with a /30 subnet thats within your on-premise address space that you use.

Description : readable name per your choosing

Mode : Routed (VTI)

Local Network : Address : the first address of your choosen /30 subnet

Remote Network : Address : the second address of your choosen /30 subnet

Encryption : everything else according to Microsoft's documentation

What happens at this point is :

Choosing Routed (VTI) as mode creates a new "available network port" under "Interfaces" -> "Assignments" with the name ipsecXXX something

Add that port and make an interface out of it and enable it.

Filling in that subnet will allocate those IP address to your interface after you add that available network port as an interface and enable it.

It also triggers the creation of a Gateway which is available under "System" -> "Routing"

Final thing to do is :

Add Static Route in pfSense : network : Your address space from your vnet from Azure

Gateway : Gateway created, VTI something something

Interface : the VTI you created earlier under the interfaces

Check

Go to "Status" -> "Interfaces", scroll all the way down and your VTI should have an IP address and a Gateway address

You're welcome.

pfSense documentation : https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/routed-vti.html

Share via

Public Container App cannot communicate with On-premise resources via VPN

0 additional answers

Your answer