The documentation says:
"You cannot set routes on the traffic coming from your app into your VNet"
Does this mean traffic is not subject to any UDRs associated with that subnet? I have a virtual network appliance in a peered network and need to route traffic through it to reach ExpressRoute.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@Glenlake Thanks for the feedback! We are currently investigating and will update you shortly.
@Glenlake Thanks again for the feedback! As this feature is in preview there are some limitations for this, and You are not allowed set routes on the traffic coming from your app into your VNet.
Thanks for your response, but it does not clarify things for me. You say "you are not allowed set routes on the traffic from your app into you VNet". Note that For Gateway Required VNet integration, there is an option called "Add Routes". That is not the capability i am talking about here... i'm specifically asking if UDRs applied to the VNet subnet are ignored, and only system routes are considered. If the latter is this case does that include system routes added via peering, VPN, or BGP.
@Glenlake Thanks for your response on this! I have assigned the issue to content author to get more clarity on this and update the document as appropriate.
It would be handy to get clarity on this as we have the exact same scenario as the OP.
This article posted from the original announcement about new peering suggests routes are not possible:
https://azure.github.io/AppService/2018/10/17/New-App-Service-VNet-Integration-feature.html
Initially there are some things that will not work initially against the subnet used for VNet Integration. They include peering, network security groups, and route tables.
This seems to suggest UDRs are not supported but the reference to UDRs is not specifically used in the article.
OP chiming back. I forged ahead and did some experimentation. I can tell you that I was able to peer the VNet with another VNet, and also it would appear that UDRs are being applied to traffic sent by the integrated Azure Web App. We we are using that setup to force traffic through a virtual network appliance (firewall). It seems to be working for us at the moment anyway. The article suggests that route tables, peering, and DNS support would be added while the feature is in preview.. i suspect that has happened. I also did an experiment with a peering without UDRs and that also worked. DNS resolution also used the resolver as configured for the Vnet. I did not test application of outbound NSG rules to the subnet.
Thankyou for the confirmation @Glenlake - makes life much easier.
Thanks @Glenlake - same situation and same question here.
Is the sentence "You cannot set routes on the traffic coming from your app into your VNet" in the docs no longer applicable or meant to describe some different aspect?
This limitation was during the preview, since Feb 27th it's GA for Windows worker, no more UDR or NSG limitation.
Most helpful comment
OP chiming back. I forged ahead and did some experimentation. I can tell you that I was able to peer the VNet with another VNet, and also it would appear that UDRs are being applied to traffic sent by the integrated Azure Web App. We we are using that setup to force traffic through a virtual network appliance (firewall). It seems to be working for us at the moment anyway. The article suggests that route tables, peering, and DNS support would be added while the feature is in preview.. i suspect that has happened. I also did an experiment with a peering without UDRs and that also worked. DNS resolution also used the resolver as configured for the Vnet. I did not test application of outbound NSG rules to the subnet.