Configure a Point-to-Site connection by using certificate authentication (classic)
This article is written for the classic deployment model. If you're new to Azure, we recommend that you use the Resource Manager deployment model instead. The Resource Manager deployment model is the most current deployment model and offers more options and feature compatibility than the classic deployment model. For more information about the deployment models, see Understanding deployment models.
For the Resource Manager version of this article, select it from the drop-down list below, or from the table of contents on the left.
This article shows you how to create a VNet with a Point-to-Site connection. You create this Vnet with the classic deployment model by using the Azure portal. This configuration uses certificates to authenticate the connecting client, either self-signed or CA issued. You can also create this configuration with a different deployment tool or model by using options that are described in the following articles:
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.
The classic deployment model supports Windows VPN clients only and uses the Secure Socket Tunneling Protocol (SSTP), an SSL-based VPN protocol. To support non-Windows VPN clients, you must create your VNet with the Resource Manager deployment model. The Resource Manager deployment model supports IKEv2 VPN in addition to SSTP. For more information, see About P2S connections.
Point-to-Site certificate authentication connections require the following prerequisites:
- 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 about Point-to-Site connections, see Point-to-Site FAQ.
Use the following values to create a test environment, or refer to these values to better understand the examples in this article:
Create virtual network (classic) settings
Name: Enter VNet1.
Address space: Enter 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, as shown in the diagram.
Subnet name: Enter FrontEnd.
Subnet address range: Enter 192.168.1.0/24.
Subscription: Select a subscription from the list of available subscriptions.
Resource group: Enter TestRG. Select Create new, if the resource group doesn't exist.
Location: Select East US from the list.
VPN connection settings
- Connection type: Select Point-to-site.
- Client Address Space: Enter 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.
Gateway configuration subnet settings
- Name: Autofilled with GatewaySubnet.
- Address range: Enter 192.168.200.0/24.
Gateway configuration settings:
- Size: Select the gateway SKU that you want to use.
- Routing Type: Select Dynamic.
Create a virtual network and a VPN gateway
Part 1: Create a virtual network
If you don't already have a virtual network (VNet), create one. Screenshots are provided as examples. Be sure to replace the values with your own. To create a VNet by using the Azure portal, use the following steps:
Sign in to the Azure portal and select Create a resource. The New page opens.
In the Search the marketplace field, enter virtual network and select Virtual network from the returned list. The Virtual network page opens.
From the Select a deployment model list, select Classic, and then select Create. The Create virtual network page opens.
On the Create virtual network page, configure the VNet settings. On this page, you add your first address space and a single subnet address range. After you finish creating the VNet, you can go back and add additional subnets and address spaces.
Select the Subscription you want to use from the drop-down list.
Select an existing Resource Group. Or, create a new resource group by selecting Create new and entering a name. If you're creating a new resource group, name the resource group according to your planned configuration values. For more information about resource groups, see Azure Resource Manager overview.
Select a Location for your VNet. This setting determines the geographical location of the resources that you deploy to this VNet.
Select Create to create the VNet. From the Notifications page, you'll see a Deployment in progress message.
After your virtual network has been created, the message on the Notifications page changes to Deployment succeeded. Select Pin to dashboard if you want to easily find your VNet on the dashboard.
Add a DNS server (optional). After you create your virtual network, you can add the IP address of a DNS server for name resolution. The DNS server IP address that you specify should be the address of a DNS server that can resolve the names for the resources in your VNet.
To add a DNS server, select DNS servers from your VNet page. Then, enter the IP address of the DNS server that you want to use and select Save.
Part 2: Create a gateway subnet and a dynamic routing gateway
In this step, you create a gateway subnet and a dynamic routing gateway. In the Azure portal for the classic deployment model, you create the gateway subnet and the gateway through the same configuration pages. Use the gateway subnet for the gateway services only. Never deploy anything directly to the gateway subnet (such as VMs or other services).
In the Azure portal, navigate to the virtual network for which you want to create a gateway.
On the page for your virtual network, select Overview, and in the VPN connections section, select Gateway.
On the New VPN Connection page, select Point-to-site.
For 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. You can overwrite the autofilled range with the private IP address range that you want to use. This example shows the autofilled range.
Select Create gateway immediately, and then select Optional gateway configuration to open the Gateway configuration page.
From the Gateway configuration page, select Subnet to add the gateway subnet. It's possible to create a gateway subnet as small as /29. However, 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 may 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 may cause your VPN gateway to not function as expected. Select OK to save this setting.
Select the gateway 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.
Select the Routing Type for your gateway. P2S configurations require a Dynamic routing type. Select OK when you've finished configuring this page.
On the New VPN Connection page, select OK at the bottom of the page to begin creating your virtual network gateway. A VPN gateway can take up to 45 minutes to complete, depending on the gateway SKU that you select.
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 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
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. Then, upload the public certificate data to the Azure server.
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 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:
- If you're using an enterprise certificate solution, generate a client certificate with the common name value format email@example.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. The steps in these articles generate a compatible client certificate:
- 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
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.
To export the certificate
For steps to export a certificate, see Generate and export certificates for Point-to-Site using PowerShell.
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.
On the VPN connections section of the page for your VNet, select the clients graphic to open the Point-to-site VPN connection page.
On the Point-to-site VPN connection page, select Manage certificate to open the Certificates page.
On the Certificates page, select Upload to open the Upload certificate page.
Select the folder graphic to browse for the .cer file. Select the file, then select OK. The uploaded certificate appears on the Certificates page.
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 the Point-to-Site connections FAQ.
Generate and install a VPN client configuration package
In the Azure portal, in the Overview page for your VNet, in VPN connections, select the client graphic to open the Point-to-site VPN connection page.
From the Point-to-site VPN connection page, select the download package that corresponds to the client operating system where it's installed:
- For 64-bit clients, select VPN Client (64-bit).
- For 32-bit clients, select VPN Client (32-bit).
After the package generates, download it and then install it on your client computer. If you see a SmartScreen popup, select More info, then select Run anyway. You can also save the package to install on other client computers.
Install a client certificate
To create a P2S connection from a different client computer than the one used to generate the client certificates, install a client certificate. 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
You must have Administrator rights on the client computer from which you are connecting.
To connect to your VNet, on the client computer, navigate to VPN connections in the Azure portal and locate the VPN connection that you created. The VPN connection has the same name as your virtual network. Select Connect. If a pop-up message about the certificate appears, select Continue to use elevated privileges.
On the Connection status page, select Connect to start the connection. If you see the Select Certificate screen, verify that the displayed client certificate is the correct one. If not, select the correct certificate from the drop-down list, and then select OK.
If your connection succeeds, you'll see a Connected notification.
Troubleshooting P2S connections
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
Verify that your VPN connection is active. Open an elevated command prompt on your client computer, and run ipconfig/all.
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....................: 192.168.130.2(Preferred) Subnet Mask.....................: 255.255.255.255 Default Gateway.................: NetBIOS over Tcpip..............: Enabled
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.
- 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.
- Verify that you're connected to your VNet with the Point-to-Site VPN connection.
- 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.
- 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.
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.
To add a trusted root certificate
You can add up to 20 trusted root certificate .cer files to Azure. For instructions, see Upload the root certificate .cer file.
To remove a trusted root certificate
On the VPN connections section of the page for your VNet, select the clients graphic to open the Point-to-site VPN connection page.
On the Point-to-site VPN connection page, select Manage certificate to open the Certificates page.
On the Certificates page, select the ellipsis next to the certificate that you want to remove, then select Delete.
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.
To revoke a client certificate
You can revoke a client certificate by adding the thumbprint to the revocation list.
- Retrieve the client certificate thumbprint. For more information, see How to: Retrieve the Thumbprint of a Certificate.
- Copy the information to a text editor and remove its spaces so that it's a continuous string.
- Navigate to the classic virtual network. Select Point-to-site VPN connection, then select Manage certificate to open the Certificates page.
- Select Revocation list to open the Revocation list page.
- Select Add certificate to open the Add certificate to revocation list page.
- In Thumbprint, paste the certificate thumbprint as one continuous line of text, with no spaces. Select OK to finish.
After updating has completed, 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.
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
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?
Up to 128 VPN clients can 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 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.
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.