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

This article helps you securely connect individual clients running Windows, Linux, or macOS to an Azure VNet. 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. You can also use P2S instead of a Site-to-Site VPN when you have only a few clients that need to connect to a VNet. Point-to-Site connections do not require a VPN device or a public-facing IP address. P2S creates the VPN connection over either SSTP (Secure Socket Tunneling Protocol), or IKEv2. For more information about Point-to-Site VPN, see About Point-to-Site VPN.

Connect from a computer to an Azure VNet - point-to-site connection diagram.

For more information about point-to-site VPN, see About point-to-site VPN. To create this configuration using the Azure PowerShell, see Configure a point-to-site VPN using Azure PowerShell.

Point-to-site native Azure certificate authentication connections use the following items, which you configure in this exercise:

  • 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. The client certificate installed on each client computer that will connect to the VNet. This certificate is used for client authentication.
  • VPN client configuration. The VPN client is configured using VPN client configuration files. These files contain the necessary information for the client to connect to the VNet. The files configure the existing VPN client that is native to the operating system. Each client that connects must be configured using the settings in the configuration files.

Prerequisites

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.

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

  • VNet Name: VNet1
  • Address space: 10.1.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: 10.1.0.0/24
  • Subscription: If you have more than one subscription, verify that you are using the correct one.
  • Resource Group: TestRG1
  • Location: East US

Virtual network gateway

  • Virtual network gateway name: VNet1GW
  • Gateway type: VPN
  • VPN type: Route-based
  • SKU: VpnGw2
  • Generation: Generation2
  • Gateway subnet address range: 10.1.255.0/27
  • Public IP address name: VNet1GWpip

Connection type and client address pool

  • 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.

Create a VNet

In this section, you create a virtual network.

Note

When using a virtual network as part of a cross-premises architecture, be sure to coordinate with your on-premises network administrator to carve out an IP address range that you can use specifically for this virtual network. If a duplicate address range exists on both sides of the VPN connection, traffic will route in an unexpected way. Additionally, if you want to connect this virtual network to another virtual network, the address space cannot overlap with the other virtual network. Plan your network configuration accordingly.

  1. Sign in to the Azure portal.

  2. In Search resources, service, and docs (G+/), type virtual network.

    Screenshot shows the Azure portal Search bar.

  3. Select Virtual Network from the Marketplace results.

    Screenshot shows the Azure portal Search bar results and selecting Virtual Network from Marketplace.

  4. On the Virtual Network page, select Create.

    Screenshot shows Virtual Network page and selecting the Create button.

  5. Once you select Create, the Create virtual network page opens.

  6. On the Basics tab, configure Project details and Instance details VNet settings.

    Screenshot shows the Basics tab.

    When you fill in the fields, you see a green check mark when the characters you enter in the field are validated. Some values are autofilled, which you can replace with your own values:

    • Subscription: Verify that the subscription listed is the correct one. You can change subscriptions by using the drop-down.
    • Resource group: Select an existing resource group, or click Create new to create a new one. For more information about resource groups, see Azure Resource Manager overview.
    • Name: Enter the name for your virtual network.
    • Region: Select the location for your VNet. The location determines where the resources that you deploy to this VNet will live.
  7. On the IP Addresses tab, configure the values. The values shown in the examples below are for demonstration purposes. Adjust these values according to the settings that you require.

    Screenshot shows the IP Addresses tab.

    • IPv4 address space: By default, an address space is automatically created. You can click the address space to adjust it to reflect your own values. You can also add additional address spaces.
    • Subnet: If you use the default address space, a default subnet is created automatically. If you change the address space, you need to add a subnet. Select + Add subnet to open the Add subnet window. Configure the following settings and then select Add to add the values:
      • Subnet name: In this example, we named the subnet "FrontEnd".
      • Subnet address range: The address range for this subnet.
  8. On the Security tab, at this time, leave the default values:

    • DDos protection: Disabled
    • Firewall: Disabled
  9. Select Review + create to validate the virtual network settings.

  10. After the settings have been validated, select Create.

Create the VPN gateway

In this step, you create the virtual network gateway for your VNet. Creating a gateway can often take 45 minutes or more, depending on the selected gateway SKU.

Note

The Basic gateway SKU does not support IKEv2 or RADIUS authentication. If you plan on having Mac clients connect to your virtual network, do not use the Basic SKU.

The virtual network gateway uses specific subnet called the gateway subnet. The gateway subnet is part of the virtual network IP address range that you specify when configuring your virtual network. It contains the IP addresses that the virtual network gateway resources and services use.

When you create the gateway subnet, you specify the number of IP addresses that the subnet contains. The number of IP addresses needed depends on the VPN gateway configuration that you want to create. Some configurations require more IP addresses than others. We recommend that you create a gateway subnet that uses a /27 or /28.

If you see an error that specifies that the address space overlaps with a subnet, or that the subnet is not contained within the address space for your virtual network, check your VNet address range. You may not have enough IP addresses available in the address range you created for your virtual network. For example, if your default subnet encompasses the entire address range, there are no IP addresses left to create additional subnets. You can either adjust your subnets within the existing address space to free up IP addresses, or specify an additional address range and create the gateway subnet there.

  1. In Search resources, services, and docs (G+/) type virtual network gateway. Locate Virtual network gateway in the search results and select it.

    Screenshot of Search field.

  2. On the Virtual network gateways page, select + Create. This opens the Create virtual network gateway page.

    Screenshot of virtual network gateways page with Create highlighted.

  3. On the Basics tab, fill in the values for Project details and Instance details.

    Screenshot of Instance fields.

    • Subscription: Select the subscription you want to use from the dropdown.
    • Resource Group: This setting is autofilled when you select your virtual network on this page.
    • Name: Name your gateway. Naming your gateway not the same as naming a gateway subnet. It's the name of the gateway object you are creating.
    • Region: Select the region in which you want to create this resource. The region for the gateway must be the same as the virtual network.
    • Gateway type: Select VPN. VPN gateways use the virtual network gateway type VPN.
    • VPN type: Select the VPN type that is specified for your configuration. Most configurations require a Route-based VPN type.
    • SKU: Select the gateway SKU you want to use from the dropdown. The SKUs listed in the dropdown depend on the VPN type you select. Make sure to select a SKU that supports the features you want to use. For more information about gateway SKUs, see Gateway SKUs.
    • Generation: Select the generation you want to use. For more information, see Gateway SKUs.
    • Virtual network: From the dropdown, select the virtual network to which you want to add this gateway.
    • Gateway subnet address range: This field only appears if your VNet doesn't have a gateway subnet. It's best to specify /27 or larger (/26,/25 etc.). This allows enough IP addresses for future changes, such as adding an ExpressRoute gateway. We don't recommend creating a range any smaller than /28. If you already have a gateway subnet, you can view GatewaySubnet details by navigating to your virtual network. Click Subnets to view the range. If you want to change the range, you can delete and recreate the GatewaySubnet.
  1. Specify in the values for Public IP address. These settings specify the public IP address object that gets associated to the VPN gateway. The public IP address is dynamically assigned to this object when the VPN gateway is created. 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.

    Screenshot of public IP address field.

    • Public IP address: Leave Create new selected.
    • Public IP address name: In the text box, type a name for your public IP address instance.
    • Assignment: VPN gateway supports only Dynamic.
    • Enable active-active mode: Only select Enable active-active mode if you are creating an active-active gateway configuration. Otherwise, leave this setting Disabled.
    • Leave Configure BGP as Disabled, unless your configuration specifically requires this setting. If you do require this setting, the default ASN is 65515, although this can be changed.
  2. Select Review + create to run validation.

  3. Once validation passes, select Create to deploy the VPN gateway.

You can see the deployment status on the Overview page for your gateway. After the gateway is created, you can view the IP address that has been assigned to it by looking at the virtual network in the portal. The gateway appears as a connected device.

Important

When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your virtual network gateway (VPN and Express Route gateways) to stop functioning as expected. For more information about network security groups, see What is a network security group?.

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.

Generate a root certificate

Obtain the .cer file for the root certificate. You can use either a root certificate that was generated with an enterprise solution (recommended), or generate a self-signed certificate. After you create the root certificate, export the public certificate data (not the private key) as a Base64 encoded X.509 .cer file. You upload this file later to Azure.

  • Enterprise certificate: If you're using an enterprise solution, you can use your existing certificate chain. Acquire 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, create a self-signed root certificate. Otherwise, the certificates you create won't be compatible with your P2S connections and clients will receive a connection error when they try to connect. You can use Azure PowerShell, MakeCert, or OpenSSL. The steps in the following articles describe how to generate a compatible self-signed root 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. Although MakeCert is deprecated, you can still use it to generate certificates. Client certificates that you generate from the root certificate can be installed on any supported P2S client.
    • Linux instructions.

Generate client certificates

Each client computer that you connect to a VNet with a Point-to-Site connection must have a client certificate installed. You generate it from the root certificate and install it on each client computer. If you don't install a valid client certificate, authentication will fail when the client tries to connect to the VNet.

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 use the same client certificate to authenticate and you revoke it, you'll need to generate and install new certificates for every client that uses that certificate.

You can generate client certificates by using the following methods:

  • Enterprise certificate:

    • If you're using an enterprise certificate solution, generate a client certificate with the common name value format name@yourdomain.com. Use this format instead of the domain name\username format.

    • Make sure the client certificate is based on a user certificate template that has Client Authentication listed as the first item in the user list. Check the certificate by double-clicking it and viewing Enhanced Key Usage in the Details tab.

  • Self-signed root certificate: Follow the steps in one of the following P2S certificate articles so that the client certificates you create will be compatible with your P2S connections.

    When you generate a client certificate from a self-signed root certificate, 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, export it as a .pfx file, along with the entire certificate chain. Doing so will create a .pfx file that contains the root certificate information required for the client to authenticate.

    The steps in these articles generate a compatible client certificate, which you can then export and distribute.

    • Windows 10 PowerShell instructions: These instructions require Windows 10 and PowerShell to generate certificates. The generated certificates can be installed on any supported P2S client.

    • MakeCert instructions: Use MakeCert if you don't have access to a Windows 10 computer for generating certificates. Although MakeCert is deprecated, you can still use it to generate certificates. You can install the generated certificates on any supported P2S client.

    • Linux instructions.

Add the VPN 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 dynamically 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. If you configure multiple protocols and SSTP is one of the protocols, then the configured address pool is split between the configured protocols equally.

  1. Once the virtual network gateway has been created, navigate to the Settings section of the virtual network gateway page. In Settings, select Point-to-site configuration. Select Configure now to open the configuration page.

    Point-to-site configuration page.

  2. On the Point-to-site configuration page, in the Address pool box, add the private IP address range that you want to use. VPN clients dynamically receive an IP address from the range that you specify. The minimum subnet mask is 29 bit for active/passive and 28 bit for active/active configuration.

  3. Continue to the next section to configure authentication and tunnel types.

Specify tunnel type and authentication type

In this section, you specify the tunnel type and the authentication type. If you don't see tunnel type or authentication type on the Point-to-site configuration page, your gateway is using the Basic SKU. The Basic SKU does not support IKEv2 or RADIUS authentication. If you want to use these settings, you need to delete and recreate the gateway using a different gateway SKU.

Tunnel type

On the Point-to-site configuration page, select the Tunnel type. When selecting the tunnel type, note the following:

  • The strongSwan client on Android and Linux and the native IKEv2 VPN client on iOS and macOS will use only the IKEv2 tunnel type to connect.
  • Windows clients will try IKEv2 first and if that doesn't connect, they fall back to SSTP.
  • You can use the OpenVPN client to connect to the OpenVPN tunnel type.

Authentication type

For Authentication type, select Azure certificate.

Screenshot of authentication type with Azure certificate selected.

Upload root certificate public key information

In this section, you upload public root certificate data 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.

  1. Navigate to your Virtual network gateway -> Point-to-site configuration page in the Root certificate section. This section is only visible if you have selected Azure certificate for the authentication type.

  2. Make sure that you exported the root certificate as a Base-64 encoded X.509 (.CER) file in the previous steps. You need to export the certificate in this format so you can open the certificate with text editor. You don't need to export the private key.

    Screenshot showing export as Base-64 encoded X.509.

  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:

    Screenshot showing root certificate information in Notepad.

  4. In the Root certificate section, you can add up to 20 trusted root certificates.

    • Paste the certificate data into the Public certificate data field.
    • Name the certificate.

    Screenshot of certificate data field.

  5. Select Save at the top of the page to save all of the configuration settings.

    Screenshot of P2S configuration with Save selected.

Install 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.

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 install steps, see Install a client certificate.

Configure settings for VPN clients

To connect to the virtual network gateway using P2S, each computer uses the VPN client that is natively installed as a part of the operating system. For example, when you go to VPN settings on your Windows computer, you can add VPN connections without installing a separate VPN client. You configure each VPN client by using a client configuration package. The client configuration package contains settings that are specific to the VPN gateway that you created.

For steps to generate and install VPN client configuration files, see Create and install VPN client configuration files for Azure certificate authentication P2S configurations.

Connect to Azure

To connect from a Windows VPN client

Note

You must have Administrator rights on the Windows client computer from which you are connecting.

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

  2. On the Connection status page, select 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 select OK.

    Connect from a Windows computer

  3. Your connection is established.

    Connect from a computer to an Azure VNet - Point-to-Site connection diagram

If you have trouble connecting, check the following items:

  • If you exported a client certificate with Certificate Export Wizard, make sure that you exported it as a .pfx file and selected Include all certificates in the certification path if possible. When you export it with this value, the root certificate information is also exported. After you install the certificate on the client computer, the root certificate in the .pfx file is also installed. To verify that the root certificate is installed, open Manage user certificates and select Trusted Root Certification Authorities\Certificates. Verify that the root certificate is listed, which must be present for authentication to work.

  • If you used a certificate that was issued by an Enterprise CA solution and you can't authenticate, verify the authentication order on the client certificate. Check the authentication list order by double-clicking the client certificate, selecting the Details tab, and then selecting Enhanced Key Usage. Make sure Client Authentication is the first item in the list. If it isn't, issue a client certificate based on the user template that has Client Authentication as the first item in the list.

  • For additional P2S troubleshooting information, see Troubleshoot P2S connections.

To connect from a Mac VPN client

From the Network dialog box, locate the client profile that you want to use, specify the settings from the VpnSettings.xml, and then select Connect.

Check Install - macOS for detailed instructions. If you are having trouble connecting, verify that the virtual network gateway is not using a Basic SKU. Basic SKU is not supported for Mac clients.

Mac VPN client connection.

To verify your connection

These instructions apply to Windows clients.

  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
    

To connect to a virtual machine

These instructions apply to Windows clients.

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-AzVM
      $Nics = Get-AzNetworkInterface | 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.

Troubleshoot a connection

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.

  • 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.

  • For more information about RDP connections, see Troubleshoot Remote Desktop connections to a VM.

  • 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.

  • 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.

To 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.

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

To remove a trusted root certificate:

  1. 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. Select the ellipsis next to the certificate, and then select Remove.

To 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.

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

For frequently asked questions, see the FAQ.

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.

For P2S troubleshooting information, Troubleshooting Azure point-to-site connections.