Azure-docs: VNet Integration preview - Peering support

[Stereo89]

Is it possible to associate an App Service to a different VNet of the target VNet (enabling peering between the two VNet to permit communication from the App Service to the resources hosted on the other VNet?)

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a7a98803-1438-b1b5-f543-7dd88bc4294e
• Version Independent ID: 37ff1d0f-ed8e-5e4d-1f4c-1b9f6cffb938
• Content: Integrate an app with an Azure Virtual Network
• Content Source: articles/app-service/web-sites-integrate-with-vnet.md
• Service: app-service
• GitHub Login: @ccompy
• Microsoft Alias: ccompy

[BryanTrach-MSFT]

@Stereo89 Yes, you should be able to integrate VNET peering as long as you are not using or calling a service on either end that contains an Internal Load Balancer (ILB).

Please see the below diagram for how this can be accomplished when trying to have your web app call a VM in a different VNET as the web app.

Web App ---Point-to-site---> VNET1 ----> VNET peering ----> VNET2 ----> web service in VM

We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.

[Stereo89]

Hi @BryanTrach-MSFT,
many thanks for your detailed answer.
However, my case is more complicated so I will try to explain it with a picture:

(All involved resources are in the same region/subscription).

Is it possible to allow the web app to communicate with the VM hosted on the MilkyWay (VNET) using the new VNet Integration feature (that doesn't require a Gateway) without affecting ExpressRoute routes?

[kanephil]

Has there been any traction on this? I have the same thing.

I have subscription 1 with VNET 1 that I have configured VNET Integration (Preview) that has VNET peering to VNET 2 in subscription 2. VNET 2 in subscription 2 has ExpressRoute private peering enabled. I have configured the WEBSITE_DNS_SERVER on the web app and want to be able to route traffic to an OnPrem server.

Any information would be greatly appreciated. Thanks.

[tonito787]

Hi!

Any updates on this issue? I have the same problem.

VNET Integrated PaaS ---(Peering)---> VNET with VM in the same subscription.

I can get this to work in 1 VNET 2 different subnets, but not 2 separate VNETS that are peered.

[j0h]

@BryanTrach-MSFT would you be able to describe what the process would be if you were using the Azure Functions Premium plan (preview)? It claims to support private network connectivity using the new VNet integration but my function is timing out when trying to connect to the other VNET. I have followed the instructions in your screenshot but as others in this issue has already commented, would be good to know what the process would be if you don't have a gateway.

Function (ip?) -> VNET_1 <--(peer)--> VNET_2 -> VM (10.0.0.1) - Error: connect EACCES 10.0.0.1:5432

[BryanTrach-MSFT]

@Stereo89, @kanephil, @tonito787, and @j0h The scenario of peering a "New VNet integration" VNet with another VNet that contains an ExpressRoute is supported. (Note Global Peering is not supported so all networking resources should be in the same region.)

There are two known reasons why it might not work.

• Networks involved use non-RFC 1918 addresses
• IPs involved are in the 10.0.0.0/17 address block. (This will be fixed in an upcoming patch)

If you are using the first scenario, this is likely going to be a hard limation. If you are in the second scenario, a patch will be coming to fix this in the near future.

If you are not in either of the two above scenarios, please reach out to me at [email protected] with your subscription ID and the URL of this post so we can investigate further.

[j0h]

Thanks for the response @BryanTrach-MSFT. I'm trying to peer between two regions so using VNET integration to connect my functions to VMs is not going to work as it seems. I'll try and find another workaround, hopefully it'll be possible is the future as I was pretty excited to jump on the Premium Plan with its VNET capabilities.

[amccool]

@BryanTrach-MSFT shoudnt the ip addresses routed to vnet in your initial diagram be:
10.88.0.0 to 10.88.255.255
rather than:
10.88.0.0 to 255.255.0.0
?

When I used the style you had diagramed... my 0.0.0.0 (public inet) routes got mangled.