How an Azure Web App Reaches On-Premises Through a VPN

The Web App's outbound request leaves a worker you never see, from a source you did not choose, and the office firewall has to accept it. That is the whole problem in one sentence. Regional VNet integration gives the request a path into a virtual network, and the site-to-site VPN carries it from there. Everything that goes wrong afterwards is about which source range and which route the packet actually used.

What the worker actually sends

App Service runs your code on workers that sit outside your subscription's network view. With regional integration enabled, outbound traffic is handed to a delegated subnet in a VNet in the same region, and the packet appears there before it continues. The integration does not move the app into the VNet and does not change its inbound address. It only gives outbound flows a different first hop.

By default only private address space takes that path, so ordinary internet destinations still leave directly from the worker. Routing everything through the VNet is a separate setting and a separate decision, because it also sends your public dependencies across the tunnel.

Configuration traffic, such as a container image pull at startup, follows its own routing rules and can fail while your API calls succeed.

The integration subnet is the source you must allow

The office sees the integration subnet's address range, or whatever your appliance translates it to, not the app's public outbound addresses. Put that range into the site VPN's traffic selectors and into the on-premises firewall rule. If the tunnel is policy-based, selectors that omit it drop the packet even when a route exists.

Do not allow a single worker address you happened to observe. Instances change with scaling and platform maintenance, and a rule pinned to one address breaks at the worst moment.

Keep the destination side narrow: one service, one port, one direction, with the return path allowed explicitly.

Peering and gateway transit are explicit

If the VPN gateway sits in a hub VNet and the integration subnet in a spoke, the path needs gateway transit allowed on the hub peering and remote gateway use enabled on the spoke peering. Peering by itself carries traffic between the two VNets and nothing more. The effective routes on the integration subnet are where you confirm the gateway next hop is really there.

A hub-and-spoke design whose route table sends 0.0.0.0/0 to a firewall is a common variant, and that firewall then needs its own rule for the on-premises prefix.

Draw the path on paper before opening a ticket with the network team, because it saves a day of guessing. Include the return direction in the drawing, since that is the half people forget.

Inbound private endpoint is the other direction

A private endpoint makes the app reachable from inside a VNet. It does nothing for the app's outbound call to the office, and teams regularly configure one while the actual requirement was the reverse.

Older documentation describes gateway-required integration built on point-to-site VPN, a different feature with its own requirements. Microsoft schedules that feature's retirement for March 31, 2027, and recommends regional integration instead.

Do not copy a legacy point-to-site configuration just because an old example used it.

Verify with the app's own context

Test from the deployed app, not from your laptop and not from a VM in the same VNet. Log the resolved address, the connection result and the application-level response separately, because a DNS failure, a TCP timeout and an authentication rejection point at three different owners. If name resolution fails, fix private DNS for the VNet before touching the tunnel.

A green tunnel status only proves the gateway is up. It says nothing about selectors, firewall rules or DNS.

When the request finally works, write the source range, the destination port and the DNS zone into the app's runbook. The next person to debug this will start from your note instead of from the gateway's status page.