Configure a Point-to-Site connection to a VNet using certificate authentication: Azure portal

This article shows you how to create a VNet with a Point-to-Site connection in the Resource Manager deployment model using the Azure portal. This configuration uses certificates to authenticate the connecting client. You can also create this configuration using a different deployment tool or deployment model by selecting a different option from the following list:

A Point-to-Site (P2S) VPN gateway lets you create a secure connection to your virtual network from an individual client computer. Point-to-Site VPN connections are useful when you want to connect to your VNet from a remote location, such when you are telecommuting from home or a conference. A P2S VPN is also a useful solution to use instead of a Site-to-Site VPN when you have only a few clients that need to connect to a VNet.

P2S uses the Secure Socket Tunneling Protocol (SSTP), which is an SSL-based VPN protocol. A P2S VPN connection is established by starting it from the client computer.

Point-to-Site-diagram

Point-to-Site certificate authentication connections require the following:

  • A RouteBased VPN gateway.
  • The public key (.cer file) for a root certificate, which is uploaded to Azure. Once the certificate is uploaded, it is considered a trusted certificate and is used for authentication.
  • A client certificate that is generated from the root certificate and installed on each client computer that will connect to the VNet. This certificate is used for client authentication.
  • A VPN client configuration package. The VPN client configuration package contains the necessary information for the client to connect to the VNet. The package configures the existing VPN client that is native to the Windows operating system. Each client that connects must be configured using the configuration package.

Point-to-Site connections do not require a VPN device or an on-premises public-facing IP address. The VPN connection is created over SSTP (Secure Socket Tunneling Protocol). On the server side, we support SSTP versions 1.0, 1.1, and 1.2. The client decides which version to use. For Windows 8.1 and above, SSTP uses 1.2 by default.

For more information about Point-to-Site connections, see the Point-to-Site FAQ at the end of this article.

Example values

You can use the following values to create a test environment, or refer to these values to better understand the examples in this article:

  • VNet Name: VNet1
  • Address space: 192.168.0.0/16
    For this example, we use only one address space. You can have more than one address space for your VNet.
  • Subnet name: FrontEnd
  • Subnet address range: 192.168.1.0/24
  • Subscription: If you have more than one subscription, verify that you are using the correct one.
  • Resource Group: TestRG
  • Location: East US
  • GatewaySubnet: 192.168.200.0/24
  • DNS Server: (optional) IP address of the DNS server that you want to use for name resolution.
  • Virtual network gateway name: VNet1GW
  • Gateway type: VPN
  • VPN type: Route-based
  • Public IP address name: VNet1GWpip
  • Connection type: Point-to-site
  • Client address pool: 172.16.201.0/24
    VPN clients that connect to the VNet using this Point-to-Site connection receive an IP address from the client address pool.

1. Create a virtual network

Before beginning, verify that you have an Azure subscription. If you don't already have an Azure subscription, you can activate your MSDN subscriber benefits or sign up for a free account.

To create a VNet in the Resource Manager deployment model by using the Azure portal, follow the steps below. The screenshots are provided as examples. Be sure to replace the values with your own. For more information about working with virtual networks, see the Virtual Network Overview.

  1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
  2. Click +. In the Search the marketplace field, type "Virtual Network". Locate Virtual Network from the returned list and click to open the Virtual Network page.

    Locate Virtual Network resource page

  3. Near the bottom of the Virtual Network page, from the Select a deployment model list, select Resource Manager, and then click Create.

    Select Resource Manager

  4. On the Create virtual network page, configure the VNet settings. When you fill in the fields, the red exclamation mark becomes a green check mark when the characters entered in the field are valid. There may be values that are auto-filled. If so, replace the values with your own. The Create virtual network page looks similar to the following example:

    Field validation

  5. Name: Enter the name for your Virtual Network.
  6. Address space: Enter the address space. If you have multiple address spaces to add, add your first address space. You can add additional address spaces later, after creating the VNet.
  7. Subnet name: Add the subnet name and subnet address range. You can add additional subnets later, after creating the VNet.
  8. Subscription: Verify that the Subscription listed is the correct one. You can change subscriptions by using the drop-down.
  9. Resource group: Select an existing resource group, or create a new one by typing a name for your new resource group. If you are creating a new group, name the resource group according to your planned configuration values. For more information about resource groups, visit Azure Resource Manager Overview.
  10. Location: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will reside.
  11. Select Pin to dashboard if you want to be able to find your VNet easily on the dashboard, and then click Create.

    Pin to dashboard

  12. After clicking Create, you will see a tile on your dashboard that will reflect the progress of your VNet. The tile changes as the VNet is being created.

    Creating virtual network tile

2. Add a gateway subnet

Before connecting your virtual network to a gateway, you first need to create the gateway subnet for the virtual network to which you want to connect. The gateway services use the IP addresses specified in the gateway subnet. If possible, create a gateway subnet using a CIDR block of /28 or /27 to provide enough IP addresses to accommodate additional future configuration requirements.

  1. In the portal, navigate to the Resource Manager virtual network for which you want to create a virtual network gateway.
  2. In the Settings section of your VNet page, click Subnets to expand the Subnets page.
  3. On the Subnets page, click +Gateway subnet to open the Add subnet page.

    Add the gateway subnet

  4. The Name for your subnet is automatically filled in with the value 'GatewaySubnet'. This value is required in order for Azure to recognize the subnet as the gateway subnet. Adjust the auto-filled Address range values to match your configuration requirements, then click OK at the bottom of the page to create the subnet.

    Adding the subnet

3. Specify a DNS server (optional)

After you create your virtual network, you can add the IP address of a DNS server to handle name resolution. The DNS server is optional for this configuration, but required if you want name resolution. Specifying a value does not create a new DNS server. The DNS server IP address that you specify should be a DNS server that can resolve the names for the resources you are connecting to. For this example, we used a private IP address, but it is likely that this is not the IP address of your DNS server. Be sure to use your own values.

  1. On the Settings page for your virtual network, navigate to DNS Servers and click to open the DNS servers blade.

    Add DNS server

    • DNS Servers: Select select Custom.
    • Add DNS server: Enter the IP address of the DNS server that you want to use for name resolution.
  2. When you are done adding DNS servers, click Save at the top of the blade.

4. Create a virtual network gateway

  1. In the portal, on the left side, click + and type 'Virtual Network Gateway' in search. Locate Virtual network gateway in the search return and click the entry. On the Virtual network gateway page, click Create at the bottom of the page to open the Create virtual network gateway page.
  2. On the Create virtual network gateway page, fill in the values for your virtual network gateway.

    Create virtual network gateway page fields

  3. Name: Name your gateway. Naming a gateway is not the same as naming a gateway subnet. It's the name of the gateway object you are creating.
  4. Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
  5. VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-based VPN type.
  6. SKU: Select the gateway SKU from the dropdown. The SKUs listed in the dropdown depend on the VPN type you select.
  7. Location: Adjust the Location field to point to the location where your virtual network is located. If the location is not pointing to the region where your virtual network resides, the virtual network doesn't appear in the 'Choose a virtual network' dropdown.
  8. Choose the virtual network to which you want to add a gateway. Click Virtual network to open the Choose a virtual network page. Select the VNet. If you don't see your VNet, make sure the Location field is pointing to the region in which your virtual network is located.
  9. Public IP address: Create a public IP address object to which a public IP address will be dynamically assigned. Click Public IP address to open the Choose public IP address page. Click +Create New to open the Create public IP address page. Input a name for your public IP address. Click OK to save your changes. The IP address is dynamically assigned when the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. However, it doesn't mean that the IP address changes after it has been assigned to your VPN gateway. The only time the Public IP address changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.
  10. Subscription: Verify that the correct subscription is selected.
  11. Resource group: This setting is determined by the Virtual Network that you select.
  12. Don't adjust the Location after you've specified the previous settings.
  13. Verify the settings. If you want your gateway to appear on the dashboard, you can select Pin to dashboard at the bottom of the page.
  14. Click Create to begin creating the gateway. The settings are validated and the gateway deploys. Creating a gateway can take up to 45 minutes.

After the gateway is created, you can view the IP address that has been assigned to it by viewing the virtual network. The gateway appears as a connected device. You can click the connected device (your virtual network gateway) to view more information.

5. Generate certificates

Certificates are used by Azure to authenticate clients connecting to a VNet over a Point-to-Site VPN connection. Once you obtain a root certificate, you upload the public key information to Azure. The root certificate is then considered 'trusted' by Azure for connection over P2S to the virtual network. You also generate client certificates from the trusted root certificate, and then install them on each client computer. The client certificate is used to authenticate the client when it initiates a connection to the VNet.

1. Obtain the .cer file for the root certificate

You can use either a root certificate that was generated using an enterprise solution (recommended), or you can generate a self-signed certificate. After creating the root certificate, export the public certificate data (not the private key) as a Base-64 encoded X.509 .cer file and upload the public certificate data to Azure.

  • Enterprise certificate: If you are using an enterprise solution, you can use your existing certificate chain. Obtain the .cer file for the root certificate that you want to use.
  • Self-signed root certificate: If you aren't using an enterprise certificate solution, you need to create a self-signed root certificate. It's important that you follow the steps in one of the P2S certificate articles below. Otherwise, the certificates you create won't be compatible with P2S connections and clients receive a connection error when trying to connect. The steps in either of the following articles generate a compatible certificate:

    • Windows 10 PowerShell instructions: These instructions require Windows 10 and PowerShell to generate certificates. Client certificates that are generated from the root certificate can be installed on any supported P2S client.
    • MakeCert instructions: Use MakeCert if you don't have access to a Windows 10 computer to use to generate certificates. MakeCert deprecated, but you can still use MakeCert to generate certificates. Client certificates that are generated from the root certificate can be installed on any supported P2S client.

2. Generate a client certificate

Each client computer that connects to a VNet using Point-to-Site must have a client certificate installed. The client certificate is generated from the root certificate and installed on each client computer. If a valid client certificate is not installed and the client tries to connect to the VNet, authentication fails.

You can either generate a unique certificate for each client, or you can use the same certificate for multiple clients. The advantage to generating unique client certificates is the ability to revoke a single certificate. Otherwise, if multiple clients are using the same client certificate and you need to revoke it, you have to generate and install new certificates for all the clients that use that certificate to authenticate.

You can generate client certificates using the following methods:

  • Enterprise certificate:

    • If you are using an enterprise certificate solution, generate a client certificate with the common name value format 'name@yourdomain.com', rather than the 'domain name\username' format.
    • Make sure the client certificate is based on the 'User' certificate template that has 'Client Authentication' as the first item in the use list, rather than Smart Card Logon, etc. You can check the certificate by double-clicking the client certificate and viewing Details > Enhanced Key Usage.
  • Self-signed root certificate: It's important that you follow the steps in one of the P2S certificate articles below. Otherwise, the client certificates you create won't be compatible with P2S connections and clients receive an error when trying to connect. The steps in either of the following articles generate a compatible client certificate:

    • Windows 10 PowerShell instructions: These instructions require Windows 10 and PowerShell to generate certificates. The certificates that are generated can be installed on any supported P2S client.
    • MakeCert instructions: Use MakeCert if you don't have access to a Windows 10 computer to use to generate certificates. MakeCert deprecated, but you can still use MakeCert to generate certificates. The certificates that are generated can be installed on any supported P2S client.

    When you generate a client certificate from a self-signed root certificate using the preceding instructions, it's automatically installed on the computer that you used to generate it. If you want to install a client certificate on another client computer, you need to export it as a .pfx, along with the entire certificate chain. This creates a .pfx file that contains the root certificate information that is required for the client to successfully authenticate. For steps to export a certificate, see Certificates - export a client certificate.

6. Add the client address pool

The client address pool is a range of private IP addresses that you specify. The clients that connect over a Point-to-Site VPN receive an IP address from this range. Use a private IP address range that does not overlap with the on-premises location that you connect from, or the VNet that you want to connect to.

  1. Once the virtual network gateway has been created, navigate to the Settings section of the virtual network gateway page. In the Settings section, click Point-to-site configuration to open the Point-to-Site-Configuration page.

    Point-to-Site page

  2. On the Point-to-Site-Configuration page, you can delete the auto-filled range, then add the private IP address range that you want to use. Click Save to validate and save the setting.

    Client address pool

7. Upload the root certificate public certificate data

After the gateway has been created, you upload the public key information for the root certificate to Azure. Once the public certificate data is uploaded, Azure can use it to authenticate clients that have installed a client certificate generated from the trusted root certificate. You can upload additional trusted root certificates- up to a total of 20.

  1. Certificates are added on the Point-to-site configuration page in the Root certificate section.
  2. Make sure that you exported the root certificate as a Base-64 encoded X.509 (.cer) file. You need to export the certificate in this format so you can open the certificate with text editor.
  3. Open the certificate with a text editor, such as Notepad. When copying the certificate data, make sure that you copy the text as one continuous line without carriage returns or line feeds. You may need to modify your view in the text editor to 'Show Symbol/Show all characters' to see the carriage returns and line feeds. Copy only the following section as one continuous line:

    Certificate data

  4. Paste the certificate data into the Public Certificate Data field. Name the certificate, and then click Save. You can add up to 20 trusted root certificates.

    Certificate upload

8. Generate and install the VPN client configuration package

To connect to a VNet using a Point-to-Site VPN, each client must install a client configuration package that configures the native VPN client with the settings and files that are necessary to connect to the virtual network. The VPN client configuration package configures the native Windows VPN client, it doesn't install a new or different VPN client.

You can use the same VPN client configuration package on each client computer, as long as the version matches the architecture for the client. For the list of client operating systems that are supported, see the Point-to-Site connections FAQ at the end of this article.

Step 1 - Generate and download the client configuration package

  1. On the Point-to-site configuration page, click Download VPN client to open the Download VPN client page. It takes a minute or two for the package to generate.

    VPN client download 1

  2. Select the correct package for your client, and then click Download. Save the configuration package file. You install the VPN client configuration package on each client computer that connects to the virtual network.

    VPN client download 2

Step 2 - Install the client configuration package

  1. Copy the configuration file locally to the computer that you want to connect to your virtual network.
  2. Double-click the .exe file to install the package on the client computer. Because you created the configuration package, it is not signed and you may see a warning. If you get a Windows SmartScreen popup, click More info (on the left), then Run anyway to install the package.
  3. Install the package on the client computer. If you get a Windows SmartScreen popup, click More info (on the left), then Run anyway to install the package.
  4. On the client computer, navigate to Network Settings and click VPN. The VPN connection shows the name of the virtual network that it connects to.

9. Install an exported client certificate

If you want to create a P2S connection from a client computer other than the one you used to generate the client certificates, you need to install a client certificate. When installing a client certificate, you need the password that was created when the client certificate was exported. Typically, it is just a matter of double-clicking the certificate and installing it.

Make sure the client certificate was exported as a .pfx along with the entire certificate chain (which is the default). Otherwise, the root certificate information isn't present on the client computer and the client won't be able to authenticate properly. For more information, see Install an exported client certificate.

10. Connect to Azure

  1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may appear that refers to using the certificate. Click Continue to use elevated privileges.

  2. On the Connection status page, click Connect to start the connection. If you see a Select Certificate screen, verify that the client certificate showing is the one that you want to use to connect. If it is not, use the drop-down arrow to select the correct certificate, and then click OK.

    VPN client connects to Azure

  3. Your connection is established.

    Connection established

If you are having trouble connecting, check the following items:

  • If you exported a client certificate, make sure that you exported it as a .pfx file using the default value 'Include all certificates in the certification path if possible'. When you export it using this value, the root certificate information is also exported. When the certificate is installed on the client computer, the root certificate which is contained in the .pfx file is then also installed on the client computer. The client computer must have the root certificate information installed. To check, go to Manage user certificates and navigate to Trusted Root Certification Authorities\Certificates. Verify that the root certificate is listed. The root certificate must be present in order for authentication to work.

  • If you are using a certificate that was issued using an Enterprise CA solution and are having trouble authenticating, check the authentication order on the client certificate. You can check the authentication list order by double-clicking the client certificate, and going to Details > Enhanced Key Usage. Make sure the list shows 'Client Authentication' as the first item. If not, you need to issue a client certificate based on the User template that has Client Authentication as the first item in the list.

11. Verify your connection

  1. To verify that your VPN connection is active, open an elevated command prompt, and run ipconfig/all.
  2. View the results. Notice that the IP address you received is one of the addresses within the Point-to-Site VPN Client Address Pool that you specified in your configuration. The results are similar to this example:

    PPP adapter VNet1:
       Connection-specific DNS Suffix .:
       Description.....................: VNet1
       Physical Address................:
       DHCP Enabled....................: No
       Autoconfiguration Enabled.......: Yes
       IPv4 Address....................: 172.16.201.3(Preferred)
       Subnet Mask.....................: 255.255.255.255
       Default Gateway.................:
       NetBIOS over Tcpip..............: Enabled
    

Connect to a virtual machine

You can connect to a VM that is deployed to your VNet by creating a Remote Desktop Connection to your VM. The best way to initially verify that you can connect to your VM is to connect by using its private IP address, rather than computer name. That way, you are testing to see if you can connect, not whether name resolution is configured properly.

  1. Locate the private IP address. You can find the private IP address of a VM by either looking at the properties for the VM in the Azure portal, or by using PowerShell.

    • Azure portal - Locate your virtual machine in the Azure portal. View the properties for the VM. The private IP address is listed.

    • PowerShell - Use the example to view a list of VMs and private IP addresses from your resource groups. You don't need to modify this example before using it.

      $VMs = Get-AzureRmVM
      $Nics = Get-AzureRmNetworkInterface | Where VirtualMachine -ne $null
      
      foreach($Nic in $Nics)
      {
       $VM = $VMs | Where-Object -Property Id -eq $Nic.VirtualMachine.Id
       $Prv = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAddress
       $Alloc = $Nic.IpConfigurations | Select-Object -ExpandProperty PrivateIpAllocationMethod
       Write-Output "$($VM.Name): $Prv,$Alloc"
      }
      
  2. Verify that you are connected to your VNet using the Point-to-Site VPN connection.

  3. Open Remote Desktop Connection by typing "RDP" or "Remote Desktop Connection" in the search box on the taskbar, then select Remote Desktop Connection. You can also open Remote Desktop Connection using the 'mstsc' command in PowerShell.
  4. In Remote Desktop Connection, enter the private IP address of the VM. You can click "Show Options" to adjust additional settings, then connect.

To troubleshoot an RDP connection to a VM

If you are having trouble connecting to a virtual machine over your VPN connection, check the following:

  • Verify that your VPN connection is successful.
  • Verify that you are connecting to the private IP address for the VM.
  • Use 'ipconfig' to check the IPv4 address assigned to the Ethernet adapter on the computer from which you are connecting. If the IP address is within the address range of the VNet that you are connecting to, or within the address range of your VPNClientAddressPool, this is referred to as an overlapping address space. When your address space overlaps in this way, the network traffic doesn't reach Azure, it stays on the local network.
  • If you can connect to the VM using the private IP address, but not the computer name, verify that you have configured DNS properly. For more information about how name resolution works for VMs, see Name Resolution for VMs.
  • Verify that the VPN client configuration package was generated after the DNS server IP addresses were specified for the VNet. If you updated the DNS server IP addresses, generate and install a new VPN client configuration package.
  • For more information about RDP connections, see Troubleshoot Remote Desktop connections to a VM.

Add or remove trusted root certificates

You can add and remove trusted root certificates from Azure. When you remove a root certificate, clients that have a certificate generated from that root won't be able to authenticate, and thus will not be able to connect. If you want a client to authenticate and connect, you need to install a new client certificate generated from a root certificate that is trusted (uploaded) to Azure.

To add a trusted root certificate

You can add up to 20 trusted root certificate .cer files to Azure. For instructions, see the section Upload a trusted root certificate in this article.

To remove a trusted root certificate

  1. To remove a trusted root certificate, navigate to the Point-to-site configuration page for your virtual network gateway.
  2. In the Root certificate section of the page, locate the certificate that you want to remove.
  3. Click the ellipsis next to the certificate, and then click 'Remove'.

Revoke a client certificate

You can revoke client certificates. The certificate revocation list allows you to selectively deny Point-to-Site connectivity based on individual client certificates. This is different than removing a trusted root certificate. If you remove a trusted root certificate .cer from Azure, it revokes the access for all client certificates generated/signed by the revoked root certificate. Revoking a client certificate, rather than the root certificate, allows the other certificates that were generated from the root certificate to continue to be used for authentication.

The common practice is to use the root certificate to manage access at team or organization levels, while using revoked client certificates for fine-grained access control on individual users.

To revoke a client certificate

You can revoke a client certificate by adding the thumbprint to the revocation list.

  1. Retrieve the client certificate thumbprint. For more information, see How to retrieve the Thumbprint of a Certificate.
  2. Copy the information to a text editor and remove all spaces so that it is a continuous string.
  3. Navigate to the virtual network gateway Point-to-site-configuration page. This is the same page that you used to upload a trusted root certificate.
  4. In the Revoked certificates section, input a friendly name for the certificate (it doesn't have to be the certificate CN).
  5. Copy and paste the thumbprint string to the Thumbprint field.
  6. The thumbprint validates and is automatically added to the revocation list. A message appears on the screen that the list is updating.
  7. After updating has completed, the certificate can no longer be used to connect. Clients that try to connect using this certificate receive a message saying that the certificate is no longer valid.

Point-to-Site FAQ

What client operating systems can I use with Point-to-Site?

The following client operating systems are supported:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8 (32-bit and 64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows 10

Can I use any software VPN client for Point-to-Site that supports SSTP?

No. Support is limited only to the Windows operating system versions listed above.

How many VPN client endpoints can I have in my Point-to-Site configuration?

We support up to 128 VPN clients to be able to connect to a virtual network at the same time.

Can I use my own internal PKI root CA for Point-to-Site connectivity?

Yes. Previously, only self-signed root certificates could be used. You can still upload 20 root certificates.

Can I traverse proxies and firewalls using Point-to-Site capability?

Yes. We use SSTP (Secure Socket Tunneling Protocol) to tunnel through firewalls. This tunnel will appear as an HTTPs connection.

If I restart a client computer configured for Point-to-Site, will the VPN automatically reconnect?

By default, the client computer will not reestablish the VPN connection automatically.

Does Point-to-Site support auto-reconnect and DDNS on the VPN clients?

Auto-reconnect and DDNS are currently not supported in Point-to-Site VPNs.

Can I have Site-to-Site and Point-to-Site configurations coexist for the same virtual network?

Yes. Both these solutions will work if you have a RouteBased VPN type for your gateway. For the classic deployment model, you need a dynamic gateway. We do not support Point-to-Site for static routing VPN gateways or gateways using the -VpnType PolicyBased cmdlet.

Can I configure a Point-to-Site client to connect to multiple virtual networks at the same time?

Yes, it is possible. But the virtual networks cannot have overlapping IP prefixes and the Point-to-Site address spaces must not overlap between the virtual networks.

How much throughput can I expect through Site-to-Site or Point-to-Site connections?

It's difficult to maintain the exact throughput of the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the Internet.

Next steps

Once your connection is complete, you can add virtual machines to your virtual networks. For more information, see Virtual Machines. To understand more about networking and virtual machines, see Azure and Linux VM network overview.