I've been trying to set up an App Service which communicates with a server in our on-premises environment. I've set up everything regarding VNET, Local network gateway, Virtual network gateway, Point-to-Site and so on. I've also set up a Linux VM to enable testing, the VM can communicate with on-prem and on-prem reaches our VM.
I also connected the app service to the VNET and it is able to tcpping the VM. But I can't get the app service to communicate with the on-prem service.
In the App Service Plan everything looks normal, I can see all the subnets, site-to-site, point-to-site and that the certificates are in sync.
But when I look at the Networking for the App Service it does not show as connected and Azure says that the certificates are not in sync. Could this be one of the reasons why the App Service and the on-prem can't communicate? Do I have to add routes for the Point-to-Site to the on-prem network?
If the Networking for the App Service is working well it should show as connected and the certificates are in sync. One or more of the possible actions you could try:
Avoid picking IP address space that overlaps with other networks.
When the Site to Site VPN is first set up then the scripts used to configure it should set up routes including your Point-to-Site VPN. If you add the Point-to-Site VPN after you create your Site to Site VPN, then you need to update the routes manually.
If those certificates or network information is changed, then you need to click Sync Network to forcibly sync the certificate to ensure the security of the connection. NOTE: When you click Sync Network then you cause a brief outage in connectivity between your app and your VNet. While your app is not restarted, the loss of connectivity could cause your site to not function properly.
You can get more details from the VNet Integrations.
Update
If your VNet hosted VM can reach your on-premises system but your app can't then the reason is likely one of the following:
your routes are not configured with your point to site IP ranges in your on-premises gateway
your network security groups are blocking access for your Point-to-Site IP range
your on-premises firewalls are blocking traffic from your Point-to-Site IP range
you have a User Defined Route(UDR) in your VNet that prevents your Point-to-Site based traffic from reaching your on-premises network
Related
I have two VNets: A and B.
VNet B has a VPN gateway and connected to an on-premise network. VNet A is peered with VNet B with transit gateway enabled. This works perfectly for virtual machines. I deploy VMs to VNet A and can access on-premise resources from there VMs.
Now I want to deploy a Web App and connect it to VNet A, so the web app will have access to on-premise resources. But to do so, I need to add a VPN gateway into the network A, which is impossible when the network is peered with another network with Use remote gateway option on. But I need this option to be on to have access to on-premise resources.
What should I do? How I can give access from Web App to on-premise resources without using App Service Environment? Is it possible?
Basically, I need the combination of these two schemes
In this case, you should integrate with VNet B from the Azure web app. Also, It will be integrated with a point-to-site VPN enabled VNet. There is a new version of the VNet Integration feature that is in preview. It doesn't depend on point-to-site VPN. From your scenario, the web app is working like " VPN clients" in a P2S connection on the second picture.
Here are some things to keep in mind before connecting your web app to a virtual network:
A target virtual network must have point-to-site VPN enabled with a
route-based gateway before it can be connected to app. The VNet must
be in the same subscription as your App Service Plan(ASP). The apps
that integrate with a VNet use the DNS that is specified for that
VNet.
Ref: https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet
We need a configuration set up exactly like the one described by the diagram in this support document. However, we already have the bottom right 2/3 configured, and it is not clear to me how the Point-to-site VPN should be configured:
Our Azure VMs and our on-premises machines share a VNet, connected via a site-to-site route-based VPN tunnel. We want to add our App Services to that VNet so they can also communicate privately with the VMs, but the documentation for configuring a Point to Site connection assumes you are starting from scratch, rather than adding to an existing VNet, and it does not cover Point-to-site connections to App Services.
It seems like a Point-to-site configuration needs to be added to the existing gateway, but I am unclear on several issues not covered by the documentation: How are certificates handled? What tunnel type is supported/preferred in App Services. Should the address pool of the Point-to-site config match the VNet's Gateway subnet range?
Update: After adding an address pool value for the Point-to-side configuration in the existing VNet gateway, the VNet could be added to our App Service. But even though The App Service VNet config reports that certs are in sync and that the gateway status is online, the App Service does not seem to be able to communicate with a VM, and nothing is listed under Allocated IP addresses in the Point-to-side configuration.
I am not sure if additional configuration is needed or if this implies a problem with the VNet addressing. The VNet default subnet is 10.1.0.0/24, the VNet gateway subnet is 10.1.1.0/24, and the Point-to-site pool is 10.1.2.0/24.
How are certificates handled?
You don't need to create certificates for the Point-to-Site configuration. Certificates are automatically created when you connect your WebApp to the VNet using the portal.
What tunnel type is supported/preferred in App Services?
This is a reference to the P2S VPN features, you can take a look at this link. P2S supports the protocols such as Secure Sockets Tunneling Protocol (SSTP) and IPsec.
Should the address pool of the Point-to-site config match the VNet's
Gateway subnet range?
You should not match the address pool of P2S with VNet's Gateway subnet. They are two address pools with different network.
I have a VM running a WebAPI service that I want to hit from an Azure web app using a vnet-to-vnet conneciton. As such, I have the VPNs configured as follows:
Virtual Machine - VMVnet
Address Space: 10.1.0.0/16
Subnet: 10.1.0.0/24
Gateway Subnet: 10.1.1.0/27
Private IP: 10.1.0.4
I also opened the target port up in Windows Firewall.
Web App - AppVnet
Address Space: 10.2.0.0/16
Subnet: 10.2.0.0/24
Gateway Subnet: 10.2.1.0/27
I also have Virtual Network Gateways configured for both, each with a connection going to the other.
Now, after I connect the app to AppVnet and sync the routes from the app service plan's networking section, I should be able to hit the VM using its private IP from the app code. When I try, I get the following error:
An attempt was made to access a socket in a way forbidden by its access permissions
I also tried setting up Virtual Network Peering between the networks, but that didn't work either.
Is what I'm trying to do even possible with Azure web apps? I saw this question, which seemed like what I was looking for but the information in it is a bit lacking.
If not, I have tried this with a point-to-site configuration with the app connected to the VM's vnet, and it worked fine. Would it be preferable to set up a second nic on the VM using the AppVnet and connect all apps through that?
I'm just wondering why neither the vnet-to-vnet nor vnet peering works
with the web app
First of all, you need to know to Integrate your app with an Azure Virtual Network.
Here are some things to keep in mind before connecting your web app to
a virtual network:
If your target virtual network already exists, it must have point-to-site VPN enabled with a Dynamic routing gateway before it can
be connected to an app.
If your gateway already exists with point-to-site enabled, and it is not in the basic SKU, IKEV2 must be disabled in your point-to-site
configuration.
That is to say, you already have a P2S connection that you can connect to AppVnet from your App. If you want to connect to VMVnet through the AppVnet from your app, you can achieve it by gateway transit for virtual network peering in hub-and-spoke network architecture.
In the diagram, gateway transit allows the peered virtual networks to use the Azure VPN gateway in Hub-RM. In this case, your AppVnet is the Hub-RM. Your web app is the VPN client in a P2S VPN connection.
I am not sure that you real configuration in your side, but I guess your creating Vnet to Vnet connection is just like Hub-RM to Spoke-RM connection in the diagram, so it does not work. Setting up Vnet peering and gateway transit enabled, it should work. For more details about Configure VPN gateway transit for virtual network peering.
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:
mounting a drive
AD integration
NetBios
private site access
Please note the last one - private site access - this is your on-premises.
I am running a few machines and we services in Windows azure that I would like to lock off to the rest of the world because of the confidential data that is on there. I have a few small things that make it harder to get at, but I would like to setup a VPN to lock it down. If I set up a VPN service on one of the VM's would I then be able to latch onto the virtual network I have setup there? What is the process in setting this up?
If your cloud service is in a VNET you can create a VPN gateway and connect to it using either a Site-to-Site VPN or a Point-to-Site VPN. The former is IT focused, requiring VPN router configuration - the latter is developer focused, and requires minimal configuration. When using either form of VPN it is possible to take your cloud service completely off the internet for inbound traffic - outbound traffic can go out regardless of what endpoints you define for your VM.