In this post, I’ll walkthrough how you test this configuration. Therefore are few moving parts so I take this a step at a time checking each connection.

Build a Test “On Premise” endpoint in Azure

To have a working example you need to have a “on premise” network at which you can point your Site to Site VPN. You don’t need a physical on-premise network – you can simulate it. I have done this both in Amazon AWS and in Azure.

To do this in Azure you repeat the steps for creating a virtual network, adding a VPN gateway and then configuring the Site to Site VPN. To avoid going completely mad use separate and appropriately named resource groups. When setting up the cloud side of the Site to Site VPN you point it at the public IP of the simulated on-premise VPN endpoint and do the opposite when configuring the cloud side VPN endpoint. Remember to use the same shared secret.

There are two extra steps you must remember which are required to ensure traffic can get back to the Point to Site clients, e.g., your web application. They are easily forgotten and the solution won’t work without them.

  • On the Local Gateway as well as adding the address space of Cloud VNET also add the Address range for your Point to Site Clients.
  • Add a route table so node son the “On Premise” network know what to do with traffic destine for the Point to Site clients. The next hop should be the Virtual Network gateway on the “on premise” side”

You’ll also need to add a VM to the simulated “on premise” network in order to provide an endpoint to hit.

Deploy a test app to App Service

These are the instructions to deploy an application using Visual Studio 2017.

  • Clone the following repo.
  • Open this in Visual Studio
  • In Solution Explorer right click “Client” then select “Publish”
  • On the next screen ensure “Microsoft Azure App Service” is selected and select the option to “Select Existing”. [This assumes you created the web app described in a previous post.
  • Then click “Publish”
  • In the next screen select the appropriate subscription and Web App and click “OK”
  • This should return you to Visual Studio where the client is built and then deployed to the correct Web App.
  • Once this is completes a browser windows opens the web site you have just deployed. You see a screen as shown below. This error is there because we haven’t deployed the server yet, nor have we configured the client to connect to the correct server.


Deploy a Test app to VMs

These steps assume that you have a VM connected to the same Azure Virtual network that contains the VPN Gateway running your Point to Site VPN that is connecting to your Azure Web App.

  • Ensure that your VM has IIS setup and configured to running a .NET based Web Application
    • Install Web Server (IIS) Server Role
    • Add the Asp.NET 4.6 Feature
  • Disable IE Enhanced Security Configuration for Administrator
  • Build the Server project from the ConnectivityTest solution
  • Zip up the Server folder and copy onto the VM
  • Unzip the contents of the zip to C:\inetpub\wwwroot
  • Test the API is working by browsing to


Note that the response contains an IP address of ::1 for the caller. This is due to how the following code reports the IP of localhost. This reports the correct IP when the caller is not on the same machine as that hosting the API.

private string GetClientIp(HttpRequestMessage request = null)
    request = request ?? Request;

    if (request.Properties.ContainsKey("MS_HttpContext"))
        return ((HttpContextWrapper)request.Properties["MS_HttpContext"]).Request.UserHostAddress;
    else if (HttpContext.Current != null)
        return HttpContext.Current.Request.UserHostAddress;
        return null;

Repeat these steps for the VM deployed to the simulated On-premise network

Verify Connectivity from the Web App to VM Service

In order for the Web App to talk to the VM in your Azure VPN you need to updates it configuration so it directs traffic to the private IP address of the VM.  Locate your Web App in the Azure portal and in its Application setting blade create an App Setting called BaseApiUrl. This overwrites the web.config application setting of the same name. You can also override the Name app setting in the same way.


Now when you load your Web App you should see a web page like this. This proves the Web Application is routing traffic from the Web App, through your VNET and onto the VM by way of the Point to Site VPN.


Referring back to the network diagram helps understand the significance of the IP addresses.


The first IP in my example is the IP address of the caller which in this case represents the Web App. Remember you have no access to the infrastructure that Microsoft is using to host this so this isn’t the IP address of the server running the web app itself. So, what is this IP address? When you configured the Point to Site VPN you configured an address range such as  When Azure did its magic, it created a client that is used in the Point to Site VPN. So, the IP address,, is the address of the client and it is allocated from the client address range. Will it always be, maybe, maybe not. Will it always be an address from the range, yes it will. In fact, I have noticed that the IP of the client can change either side of a Web App restart.

The second IP address is the IP address of the server hosting the API. In this case it is the IP address of the VM sitting in the Azure VNET’s backend subnet. The address comes from the address range of the backend subnet that we use when setting up the subnet.

Verify Connectivity from the Web App to On premise

This step acts as the reveal. Over a number of point we have setup a bit a networking and two VPN connections. Whilst we have had to get our hands a bit dirty with a bit of network we haven’t had to get too intimate with network and routing details. And now if we go back to the Web App Application Settings and change the URL to the reflect the IP address of your on premise network the screen will change to show the IP address on the simulated on premise app server.

At this point you show now have an end to end working system.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s