In the first part of this series, we looked at creating virtual networks (VNets) in Azure using the GUI or PowerShell. Now, we’ll continue the investigation into networking by seeing how you can connect virtual networks in Azure to your on-premises networks using point-to-site VPN networks, site-to-site VPN networks, or the new service called ExpressRoute. In this article, we’ll look at point-to-site; I’ll cover site-to-site and ExpressRoute in Part 3.

Planning Azure point-to-site VPN

Like everything to do with networking, a little planning and understanding of the limitations of each technology goes a long way, particularly as there are some settings that can’t be changed after the initial configuration. Point-to-site is the easiest to set up and lets you connect individual computers (up to 128 of them) to your VNet in Azure. Behind the scenes, it’s actually a Secure Sockets Tunneling Protocol (SSTP) connection with certificate-based authentication. The beauty of SSTP is that it’s supported on all modern versions of Windows (7+, 2008 R2+) and, because it uses port 443, it should work from any public network.

Point-to-site and site-to-site connectivity can be combined for the same VNet, but point-to-site can’t be used together with ExpressRoute (a secure, direct connection from on-premises to Azure that doesn’t go over the public Internet). As we saw in the first part of the series, you can use Azure’s own built-in DNS for basic name resolution; however, if you want VMs in Azure to be able to connect to servers on premises or to join your AD domain, you have to supply your own DNS servers, either as VM(s) in the VNet or on premises.

Connect to Azure via point-to-site

To set up a network for point-to-site, select Networks and then Custom Create. Give your new virtual network a name, select the region that’ll host it (this can’t be changed after the fact), and go to the next page.

Select Configure a point-to-site VPN

Select Configure a point-to-site VPN.

On this page, select “Configure a point-to-site VPN” and, optionally, add DNS server(s). On the next page, define an address space for VPN clients. On the final page, define the address space for your VNet, including a gateway subnet used for the VPN server in Azure.

Make sure your VPN client IP address range doesn’t overlap with your on-premises or VNet address ranges

Make sure your VPN client IP address range doesn’t overlap with your on-premises or VNet address ranges.

When completed, navigate to Networks, highlight your new VNet, go to the dashboard, and, at the bottom, select Create Gateway. This can take up to 15 minutes. Next, you’ll need to create a self-signed root certificate, upload this to the Management portal, create and export a client certificate, and then install this certificate on the client(s). In the code examples below, you can change the names of the certificates to match your environment.

One way to create the root cert is to use Makecert.exe, which you get as part of the free Visual Studio. Open the command prompt in Visual Studio tools as an administrator and run:

makecert -sky exchange -r -n "CN=RootCertName" -pe -a sha1 -len 2048 -ss My "RootCertName.cer"

This will create the cert in the current folder. Go back to the console and select the Certificates tab (next to Dashboard and Configure), click “Upload a root certificate,” and select the file you just created. Next, you’ll need to create a client certificate by running the following from the same folder where you created the root cert:

makecert.exe -n "CN=ClientCertificateName" -pe -sky exchange -m 96 -ss My -in "RootCertName" -is my -a sha1

This certificate will be installed in the Personal store for your user account on the PC where you ran the command. The recommended approach is to create a separate certificate for each client computer; then, you’ll need to open certmgr.msc, expand Personal – Certificates, right-click a client certificate, and export the certificate as a PFX file with the private key. On the computer where you need to install the certificate, simply double-click the PFX file.

Exporting client certificates so they can be imported on different computers is done in the Certificate Management MMC

Exporting client certificates so they can be imported on different computers is done in the Certificate Management MMC.

Installing the client for point-to-site VPN

Finally, it’s time to install the VPN client, which is available for download from the console on the Dashboard tab, in the lower right corner, in both the 32- and 64-bit versions. Right-click the downloaded file, select Properties and Unblock the file, and then run the file as an administrator and allow the installation to complete.

Simply click Connect to start the point-to-site VPN

Simply click Connect to start the point-to-site VPN.

The connection will appear in your list of VPN connections. The first time you connect, you’ll be asked to give a Custom Action permission for CMRoute.dll to update your routing table.

This message should only appear once, the first time you connect.

This message should only appear once, the first time you connect.

One way to check that the connection completed as expected is in the Azure console where the number of connected point-to-site clients are listed. You should also ping the IP of a VM that’s running in your VNet, as well as ping hostnames to test your DNS configuration.

If you’re keen to break down the structure of the point-to-site setup and figure out how to use it as an ordinary SSTP connection to Azure or start the VPN connection from the command line, see here.


Configuring point-to-site is the easiest way to connect to an Azure VNet, but it lacks the flexibility required to truly make Azure part of your company’s infrastructure. In the next part, we’ll look at how site-to-site can achieve this.

  1. Avatar
    Onaka 8 years ago


    In your example you have a VNET (Azure) with both point-to-site and site-to-site connections.  I have a similar setup and have a question.  Clients that connect via the point to site VPN can’t hit the other VNET over the site to site.   I’m sure it’s a routing issue. I added static routes the my Client computers so that a packet to the other VNET goes over the point to site Gateway, but still nothing.   Any idea?


  2. Avatar Author

    Hi Onaka,

    Thanks for your question. I’m not sure I understand it though. How many Vnets do you have in Azure? Which Vnet is it that your P2S clients can’t see? You mention the “other Vnet”, which one is that? Back to on-premises?

    Let me know and I’ll see if I can help,

    Paul Schnackenburg

    • Avatar
      Onaka 8 years ago


      I’ll make it simple and clear.  Lets say I have two VNets, A & B and they are connected via Site-to-Site VPN.  Next I connect a clinet PC to VNet A via Point-to-Site VPN.  Now, I want to reach resources in VNet B, but I can’t.  I added a route to the client PC so that a packet to VNet B is sent over P2S, but once it gets to VNet A it can’t route to VNet B.  I can RDP to a VM in VNet A and it can reach resources in VNet B so I know the VPNs are properly setup.  It’s just that a P2S VPN client can’t reach VNet B.

      I tried adding a user defined table to the P2S Gateway with an entry for VNet B with next hop via VPNGateway, but it won’t let me do that….but that is where this route entry be.   I’ve created similar network topography in several on-premises and it’s pretty straighforward.  I just need to know how to accomplish same thing in Azure.


  3. Avatar
    Shawn 8 years ago

    Hello. After I click connect, I got this error:

    A certificate could not be found that can be used with this Extensible Authentication Protocol. (Error 798)

    but I do import the cert to my local machine already. Why?

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account