We have a Web App which connects to a Neo4j database running on a VM. All resources are ARM in the same location and same resource group. To establish connectivity between Web App and VM we have followed this guide and used the V2VnetAllinOne.ps1 script as a reference. After creating the VNET gateway and opening the firewall port 7474 and creating the NSG rule to allow VNET traffic on this port, we find that there is no connection between the Web App and the VM. We have found 3 separate, but related issues with our set-up.
1) The script appears to have a bug. Line 286 sets the vnetResourceId in the propertiesObject. It uses $vnetName which is out of context in this part of the script. It is null. It should be $vnet.Name. At this point it tells me that this script is unsuitable for attaching to existing VNETs as it would create an invalid url.
2) After fixing up the script and running it against our existing VNET containing 1 VM. Address space 10.1.0.0/16, subnet 10.1.1.0/24. We create a gateway subnet 10.1.2.0/24 and create the VPN gateway with PointToSiteAddressSpace 172.16.0.0/24 and wait for an hour to create everything.
After completion we view the Web App > settings > networking in the ARM portal. It shows connected to VNET.
We then view App Service plan > networking > VNET Integration. It shown 1 VNET configured. Clicking into the configuration we see VNETs integrated 1 of 5. It shows Gateway Status Online, Certificate Status - Certificates in sync.
We return to the Web App > Tools > Console and we perform tcpping 10.1.1.4:7474. It returns: Connection attempt failed: An attempt was made to access a socket in a way forbidden by its access permissions 10.1.1.4:7474
Then we go back to the App Service plan > networking > VNET Integration. Click the VNET. Then click 'Sync Network'.
Finally we go back to Web App > Tools > Console and repeat the tcpping 10.1.1.4:7474. This time it returns: Connected to 10.1.1.4:7474, time taken: 830ms.
From this point all is good. After repeating this many times we come to the same conclusion. The VNET integration doesn't work until you click 'Sync Network' in the App Service plan networking.
3) We have multiple identical environments, mostly used for testing during business hours. Outside of business hours we need to turn everything off. For this we switch off the VM, delete the Web App and delete the App Service plan. Before this we remove
the VNET integration using option 3 in the script. The problem here is that when we build up the same resources the following day (create App Service plan, create Web App, attach VNET integration) we see the same problem as above. We need to 'Sync Network'
before traffic is resumed. However in this case we have a further problem. Some VNET gateway resource is being duplicated as shown
here.
So now in the App service plan > networking we see duplicates of the VNET name. If we continue with detach VNET, delete Web App, delete App service plan, shutdown VM, then create and restart and re-attach we see another duplicate VNET like this. And this continues. We have an example which shows 12 of 5 VNETs.
Even worse is that if you delete all resource groups and completely empty the subscription, on creation of a new environment all these duplicate resources return.
Our implementation is close to completion. In the short-term my first question is: can we perform a 'Sync Network' from PowerShell or a REST call? It is vital the VNET integration works from our automated provisioning scripts. We don't have the luxury of viewing the portal to click this link in a production setting.
Next I would ask that the V2VnetAllinOne script is reviewed, particularly for attaching to existing VNETs. When we attach to a VNET we create 2 resources, one of type "Microsoft.Web/sites/virtualNetworkConnections" and the other of type "Microsoft.Web/sites/virtualNetworkConnections/gateways" but when we detach from a VNET we remove only the resource of type "Microsoft.Web/sites/virtualNetworkConnections". Could this be the reason for the resource duplication?
Finally I would ask the whole VNET integration article to be re-written to provide more information about the resources being created. Most people, including ourselves, would not use this script as-is. We really need proper Cmdlets which abstract away these processes. If any changes are made to the VNET integration then these scripts would become obsolete and we would have no clue why.
Appreciate your help in this matter.