Configure a Point-to-Site connection by using certificate authentication (classic)

This article shows you how to create a VNet with a Point-to-Site connection using the classic (legacy) deployment model. This configuration uses certificates to authenticate the connecting client, either self-signed or CA issued. These instructions are for the classic deployment model. You can no longer create a gateway using the classic deployment model. See the Resource Manager version of this article instead.

You use a Point-to-Site (P2S) VPN gateway to 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. When you have only a few clients that need to connect to a VNet, a P2S VPN is a useful solution to use instead of a Site-to-Site VPN. A P2S VPN connection is established by starting it from the client computer.

Settings and requirements

Requirements

Point-to-Site certificate authentication connections require the following items. There are steps in this article that will help you create them.

• A Dynamic VPN gateway.
• The public key (.cer file) for a root certificate, which is uploaded to Azure. This key is considered a trusted certificate and is used for authentication.
• A client certificate generated from the root certificate, and installed on each client computer that will connect. This certificate is used for client authentication.
• A VPN client configuration package must be generated and installed on every client computer that connects. The client configuration package configures the native VPN client that's already on the operating system with the necessary information to connect to the VNet.

Point-to-Site connections don't 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, see About Point-to-Site connections and the FAQ.

Example settings

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

• Resource Group: TestRG
• 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
• GatewaySubnet: 192.168.200.0/24
• Region: (US) East US
• Client address space: 172.16.201.0/24
  VPN clients that connect to the VNet by using this Point-to-Site connection receive an IP address from the specified pool.
• Connection type: Select Point-to-site.

Before you begin, 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.

Create a virtual network

If you already have a VNet, verify that the settings are compatible with your VPN gateway design. Pay particular attention to any subnets that might overlap with other networks.

1. From a browser, navigate to the Azure portal and, if necessary, sign in with your Azure account.
2. Select +Create a resource. In the Search the marketplace field, type 'Virtual Network'. Locate Virtual Network from the returned list and select it to open the Virtual Network page.
3. On the Virtual Network page, under the Create button, you see "Deploy with Resource Manager (change to Classic)". Resource Manager is the default for creating a VNet. You don't want to create a Resource Manager VNet. Select (change to Classic) to create a Classic VNet. Then, select the Overview tab and select Create.
4. On the Create virtual network(classic) page, on the Basics tab, configure the VNet settings with the example values.
5. Select Review + create to validate your VNet.
6. Validation runs. After the VNet is validated, select Create.

DNS settings are not a required part of this configuration, but DNS is necessary if you want name resolution between your VMs. 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.

After you create your virtual network, you can add the IP address of a DNS server to handle name resolution. Open the settings for your virtual network, select DNS servers, and add the IP address of the DNS server that you want to use for name resolution.

1. Locate the virtual network in the portal.
2. On the page for your virtual network, under the Settings section, select DNS servers.
3. Add a DNS server.
4. To save your settings, select Save at the top of the page.

Create a VPN gateway

1. Navigate to the VNet that you created.

2. On the VNet page, under Settings, select Gateway. On the Gateway page, you can view the gateway for your virtual network. This virtual network doesn't yet have a gateway. Click the note that says Click here to add a connection and a gateway.

3. On the Configure a VPN connection and gateway page, select the following settings:

   • Connection type: Point-to-site
   • Client address space: Add the IP address range from which the VPN clients receive an IP address when connecting. Use a private IP address range that doesn't overlap with the on-premises location that you connect from, or with the VNet that you connect to.

4. Leave the checkbox for Do not configure a gateway at this time unselected. We will create a gateway.

5. At the bottom of the page, select Next: Gateway >.

6. On the Gateway tab, select the following values:

   • Size: The size is the gateway SKU for your virtual network gateway. In the Azure portal, the default SKU is Default. For more information about gateway SKUs, see About VPN gateway settings.
   • Routing Type: You must select Dynamic for a point-to-site configuration. Static routing won't work.
   • Gateway subnet: This field is already autofilled. You can't change the name. If you try to change the name using PowerShell or any other means, the gateway won't work properly.
   • Address range (CIDR block): While it's possible to create a gateway subnet as small as /29, we recommend that you create a larger subnet that includes more addresses by selecting at least /28 or /27. Doing so will allow for enough addresses to accommodate possible additional configurations that you might want in the future. When working with gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet might cause your VPN gateway to not function as expected.

7. Select Review + create to validate your settings.

8. Once validation passes, select Create. A VPN gateway can take up to 45 minutes to complete, depending on the gateway SKU that you select.

Create certificates

Azure uses certificates to authenticate VPN clients for Point-to-Site VPNs. You upload the public key information of the root certificate to Azure. The public key is then considered trusted. Client certificates must be generated from the trusted root certificate, and then installed on each client computer in the Certificates-Current User\Personal\Certificates certificate store. The certificate is used to authenticate the client when it connects to the VNet.

If you use self-signed certificates, they must be created by using specific parameters. You can create a self-signed certificate by using the instructions for PowerShell and Windows 10 or later, or MakeCert. It's important to follow the steps in these instructions when you use self-signed root certificates and generate client certificates from the self-signed root certificate. Otherwise, the certificates you create won't be compatible with P2S connections and you'll receive a connection error.

Acquire the public key (.cer) for the 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 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:

  • PowerShell instructions for Windows 10 or later: These instructions require PowerShell on a computer running Windows 10 or later. Client certificates that are generated from the root certificate can be installed on any supported P2S client.
  • MakeCert instructions: Use MakeCert to generate certificates if you don't have access to a computer running Windows 10 or later. 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 - OpenSSL instructions
  • Linux - strongSwan instructions

Generate a client certificate

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 or later PowerShell instructions: These instructions require Windows 10 or later, 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 or later 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: See strongSwan or OpenSSL instructions.

Upload the root certificate .cer file

After the gateway has been created, upload the .cer file (which contains the public key information) for a trusted root certificate to the Azure server. Don't upload the private key for the root certificate. After you upload the certificate, Azure uses it to authenticate clients that have installed a client certificate generated from the trusted root certificate. You can later upload additional trusted root certificate files (up to 20), if needed.

1. Navigate to the virtual network you created.
2. Under Settings, select Point-to-site connections.
3. Select Manage certificate.
4. Select Upload.
5. On the Upload a certificate pane, select the folder icon and navigate to the certificate you want to upload.
6. Select Upload.
7. After the certificate has uploaded successfully, you can view it on the Manage certificate page. You might need to select Refresh to view the certificate you just uploaded.

Configure the client

To connect to a VNet by using a Point-to-Site VPN, each client must install a package to configure the native Windows VPN client. The configuration package configures the native Windows VPN client with the settings necessary to connect to the virtual network.

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 About Point-to-Site connections and the FAQ.

Generate and install a VPN client configuration package

1. Navigate to the Point-to-site connections settings for your VNet.

2. At the top of the page, select the download package that corresponds to the client operating system where it will be installed:

   • For 64-bit clients, select VPN client (64-bit).
   • For 32-bit clients, select VPN client (32-bit).

3. Azure generates a package with the specific settings that the client requires. Each time you make changes to the VNet or gateway, you need to download a new client configuration package and install them on your client computers.

4. After the package generates, select Download.

5. Install the client configuration package on your client computer. When installing, if you see a SmartScreen popup saying Windows protected your PC, select More info, then select Run anyway. You can also save the package to install on other client computers.

Install a client certificate

For this exercise, when you generated the client certificate, it was automatically installed on your computer. To create a P2S connection from a different client computer than the one used to generate the client certificates, you must install the generated client certificate on that computer.

When you install a client certificate, you need the password that was created when the client certificate was exported. Typically, you can install the certificate by just double-clicking it. For more information, see Install an exported client certificate.

Connect to your VNet

1. On the client computer, go to VPN settings.
2. Select the VPN that you created. If you used the example settings, the connection will be labeled Group TestRG VNet1.
3. Select Connect.
4. In the Windows Azure Virtual Network box, select Connect. If a pop-up message about the certificate appears, select Continue to use elevated privileges and Yes to accept configuration changes.
5. When your connection succeeds, you'll see a Connected notification.

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.

Verify the VPN connection

1. Verify that your VPN connection is active. Open an elevated command prompt on your client computer, 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 connectivity address range that you specified when you created your VNet. The results should be 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.11 (Preferred)
        Subnet Mask.....................: 255.255.255.255
        Default Gateway.................:
        NetBIOS over Tcpip..............: Enabled
   

To connect to a virtual machine

Create a Remote Desktop Connection to connect to a VM that's deployed to your VNet. The best way to verify you can connect to your VM is to connect with its private IP address, rather than its computer name. That way, you're testing to see if you can connect, not whether name resolution is configured properly.

1. Locate the private IP address for your VM. To find the private IP address of a VM, view the properties for the VM in the Azure portal or use PowerShell.
2. Verify that you're connected to your VNet with the Point-to-Site VPN connection.
3. To open Remote Desktop Connection, enter RDP or Remote Desktop Connection in the search box on the taskbar, then select Remote Desktop Connection. You can also open it by using the mstsc command in PowerShell.
4. In Remote Desktop Connection, enter the private IP address of the VM. If necessary, select Show Options to adjust additional settings, then connect.

To troubleshoot an RDP connection to a VM

If you're having trouble connecting to a virtual machine over your VPN connection, there are a few things you can check.

• Verify that your VPN connection is successful.
• Verify that you're connecting to the private IP address for the VM.
• Enter ipconfig to check the IPv4 address assigned to the Ethernet adapter on the computer from which you're connecting. An overlapping address space occurs when the IP address is within the address range of the VNet that you're connecting to, or within the address range of your VPNClientAddressPool. 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 by 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 is generated after you specify the DNS server IP addresses for the VNet. If you update the DNS server IP addresses, generate and install a new VPN client configuration package.

For more troubleshooting information, see Troubleshoot Remote Desktop connections to a VM.

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 can no longer authenticate and connect. For those clients to authenticate and connect again, you must install a new client certificate generated from a root certificate that's trusted by Azure.

Add a trusted root certificate

You can add up to 20 trusted root certificate .cer files to Azure by using the same process that you used to add the first trusted root certificate.

Remove a trusted root certificate

1. On the Point-to-site connections section of the page for your VNet, select Manage certificate.
2. Select the ellipsis next to the certificate that you want to remove, then select Delete.

To revoke a client certificate

If necessary, you can revoke a client certificate. The certificate revocation list allows you to selectively deny Point-to-Site connectivity based on individual client certificates. This method differs from 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 for the Point-to-Site connection.

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 its spaces so that it's a continuous string.
3. Navigate to Point-to-site VPN connection, then select Manage certificate.
4. Select Revocation list to open the Revocation list page.
5. In Thumbprint, paste the certificate thumbprint as one continuous line of text, with no spaces.
6. Select + Add to list to add the thumbprint to the certificate revocation list (CRL).

After updating completes, the certificate can no longer be used to connect. Clients that try to connect by using this certificate receive a message saying that the certificate is no longer valid.

FAQ

This FAQ applies to P2S connections that use the classic deployment model.

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
• Windows 11

Can I use any software VPN client that supports SSTP for point-to-site?

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

How many VPN client endpoints can exist in my point-to-site configuration?

The number of VPN client endpoints depends on your gateway sku and protocol.

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 up to 20 root certificates.

Can I traverse proxies and firewalls by using point-to-site?

Yes. We use Secure Socket Tunneling Protocol (SSTP) to tunnel through firewalls. This tunnel appears 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 won't reestablish the VPN connection automatically.

Does point-to-site support auto reconnect and DDNS on the VPN clients?

No. Auto reconnect and DDNS are currently not supported in point-to-site VPNs.

Can I have Site-to-Site and point-to-site configurations for the same virtual network?

Yes. Both solutions will work if you have a RouteBased VPN type for your gateway. For the classic deployment model, you need a dynamic gateway. We don't support point-to-site for static routing VPN gateways or gateways that use the -VpnType PolicyBased cmdlet.

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

Yes. However, the virtual networks can't 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

• After 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 Linux virtual machines, see Azure and Linux VM network overview.

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