0

I have this setup in Azure:

  • A vnet with address space: 172.16.0.0/16
    • A subnet with 172.16.1.0/24 named WebAppSubnet and delegated ot Microsoft.Web/serverFarms
    • A subnet with 172.16.255.0/24 named GatewaySubnet
  • A local gateway with address space 172.18.96.76/32
  • A public Ip associated with the gateway
  • A connection, configured with a custom config
    • IKE Phase 1 with AES256, SHA256 and DHG 1
    • IKE Phase 2 (IPSec) with AES256, SHA256 and No PF Group
    • IPsec SA lifetime in KiloBytes set to 102400000
    • IPsec SA lifetime in seconds set to 28800
    • disabled traffic selector
    • DPD timeout set to 45
    • BGP and Azure private IP is disabled
    • IKE protocol is IKEv2
  • A virtual gateway, provisioned into the GatewaySubnet, connected with the local gateway and the connection
    • No point to site enabled

All resources is located in West Europe and in the same resource group.

The connection is reporting "Connected", and the onprem IT guys can also see that it is connected.

I want to connect one webapp to the VNET so it can connect to the onprem SQL server located at 172.18.96.76. Therefore i check to see if the webapp is added correctly to the VNET:

Webapp connected to VNET

This is perfect. It works: the webapp is in the VNET. Now i want to point my connection string to onprem SQL. I use this connection string

Server=172.18.96.76;Database=AutodesktopMirror;User Id=myuser;Password=mypass;

but I get an error telling me:

Win32Exception: Access is denied.

Unknown location

SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

So, it doesn't locate the onprem SQL server, and this is where i gets a bit tricky, because:

  1. i can't ping the gateway
  2. i can't do tracert from the webapp

I haven't added WEBSITE_VNET_ROUTE_ALL to the webapp settings. I have tested with and without it, and it gives me the same results: Access Denied, Unknown location.

So basically i don't really know if my traffic gets routed properly. All i know is that all RFC1918 traffic gets routed to the VNET. My webapp is in the VNET, my gateway is in the VNET. What i can see is that no traffic hits the gateway, if i look at the network graphs:

Virtual gateway network ingress and egress

and I have set health probes up to ping the SQL server every two minutes + i have tried all sorts of calls. I have also tried to troubleshot the connectivity on the VPN gateway, and it tells me:

Azure connectivity troubleshooter

I have googled my a** of, and I have so confused by the mix of "classic VNETs/point-to-site vs no point-to-site". Someone here on serverfault even states that it should just work: https://serverfault.com/a/1046325/133202, because when my webapp is on the VNET with the gateway, it should be able to call through to the onprem database.

Am i missing something in my setup? I have no point to site, should I have? I am happy if i can just get confirmation on if my Azure setup is ok, with the VNET, gateway and IP ranges, because then i think i am going to look more into how the onprem is connected. Maybe they need to update something on their side.

I am not a network administrator, so i am a bit left in the dark when it comes to VPN setup.

All this is provisioned with ARM.

UPDATED

Drawing of setup VPN setup

Customer end VPN: Fortigate FortiOS 6.2

Solution

  1. you dont need site to site if the VNET and webapps is in same region. If the gateway is in the VNET, and the connection is working, all traffic is guided through this
  2. Remember that only all RFC1918 traffic is routed to the VNET pr default
  3. you need to setup the gateway as described here: https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-diagnose-on-premises-connectivity#scenario
  4. Check your firewall rules :) And then check them again
  5. this just works, if you set a VNET up, with a GatewaySubnet, and a WebAppSubnet and have the local gateway correctly mapped to the onprem address space configured in the onprem gateway. YOU DONT NEED: point-to-site on the gateway, or WEBSITE_VNET_ROUTE_ALL in the webapp config (if you follow the RFC1918 address spacing)

Massive thanks to Massimo, https://serverfault.com/users/6352/massimo!!

mslot
  • 105
  • 1
  • 6

1 Answers1

2

"A local gateway with address space 172.18.96.76/32" is completely wrong.

The Local Network Gateway describes your LAN to Azure; it should contain your full internal address space, not a single IP address.

You should change it to 172.18.96.0/24 or 172.18.0.0/16 or whatever your LAN address space is.

Massimo
  • 70,200
  • 57
  • 200
  • 323
  • Thank you. This was one of the things i wanted to address tomorrow when i have a meeting with the guys who sits onprem. As i understand this address space is what describe the onprem network, right? – mslot Feb 17 '21 at 18:19
  • Yes, that's exactly its purpose. – Massimo Feb 17 '21 at 18:36
  • I have updated the address space to match (it was 172.18.96.0/24), but still no luck. This is really annoying, because i am a bit unsure if my setup on the Azure side should work or not: that is, does it route the traffic correct from the webapp, through the VNET and into the gateway. I find the documentation on this lacking, and when googling about it, i get thrown even more of, because there is so many different and old ways of doing it. – mslot Feb 18 '21 at 08:03
  • I have added a VM to the VNET in its own subnet, so i can ping and traceroute. Should this VM be on a point-to-site? I can't ping or traceroute the onprem SQL ip – mslot Feb 18 '21 at 08:22
  • No, you don't need point-to-site. Point-to-site is only used when you need to connect *TO* your VNet from *outside* it (f.e. from your home). – Massimo Feb 18 '21 at 08:24
  • If your VM in the VNet can't connect to the on-pemises server, then something is wrong with your site-to-site VPN connection. You should ask your networking team how this has been setup on your side. – Massimo Feb 18 '21 at 08:26
  • We set up the address space as you said. Thanks for that. We have debugged all day. Even tried to follow this guide: github.com/Azure/Azure-vpn-config-samples/blob/master/Fortinet/…. It doesn't lead us any further. Even though i cant reach the other side, should i be able to see egress for the VPN gateway? I dont see any. I do see "Egress Packets Dropped due to Traffic Selector Mismatch (since last connected) : 287 Packets" when doing a debug on the VPN connection. I dont know if that shows that it tries to send packages, but fails, or it is irelevant. – mslot Feb 18 '21 at 14:10
  • How is the VPN connection set up on *your* side? It should match the address space of the VNet. – Massimo Feb 18 '21 at 16:16
  • I fixed that. Didn't help. Should i be able to just update this address space without reprovision the local gateway or connection? They have a fortigate in their end and i think we have some mismatch in config even though the Azure troubleshoot tells us nothing is wrong. That is the only thing i can see that is wrong. – mslot Feb 18 '21 at 18:22
  • I really don't know, there are lots of details which can go wrong. What I can tell for sure is that you need to fix your site-to-site VPN; when your Azure VM will be able to successfully connect to your on-premises servers, then the Web App connected to the VNet will work too. – Massimo Feb 18 '21 at 20:52
  • Here's another hint: on most firewalls, you not only need to establish the VPN connection, you also need to allow traffic through it. If the VPN is up but no traffic flows, check your firewall rules. – Massimo Feb 18 '21 at 20:54