We have an Azure WebJob running on an App Service connected to a vNET via Point-to-Site connection.
That same vNET is then connected to the on-premise network via a Site-to-Site VPN connection.
Routing is set up so to the Site-to-Site conn so that that the IP range of the Azure vNET (172.27.0.0/24) is sent from OnPrem > Azure. This can be tested by logging in to a VM inside of the vNET to query on premise resources - this works fine, and as expected.
If the same request (to a REST API) is sent from the WebJob, things do not work.
The IP range of the Point-to-Site (172.27.1.144/28) does not intersect with that of the vNET, so i am wondering if we need to also route this range "back across" the Site-to-Site connection also?
Another alternative is that a routing table within Azure needs to have a manual entry, somehow?
Any tips on how to troubleshoot / get this working would be much appreciated.
The IP range of the Point-to-Site (172.27.1.144/28) does not intersect with that of the vNET, so i am wondering if we need to also route this range "back across" the Site-to-Site connection also?
You need to do that, indeed. Not only that, you need to configure this network range (172.27.1.144/28) on your on-premises router too - so it recognises and accepts the traffic.
But in order to make the routing from the Point-to-Site (Azure app service) to the on-premise over the Site-to-Site VPN Connection, you will need to use a Virtual Appliance which is capable of forwarding the traffic.
For sake of simplicity and cost savings, you could just use Azure Hybrid Connections to connect Azure Web App / Web Job to on-premise Resource.
You can also refer to the documentation here, which lists the limitations of connecting App Service Plan to a Virtual Network, namely:
There are some things that VNET Integration does not support including:
Please note the last one - private site access - this is your on-premises.