Select Page
Connect a computer to a virtual network using P2S: certificate authentication: Azure portal classic


Get Your Nord VPN account NOW ! claim the discount

  • Article
  • 05/26/2022
  • 23 minutes to read

In this article

Note

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

Important

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-diagram

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: 10.11.255.0/27
  • 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.
  • GatewaySubnet Address range (CIDR block): 192.168.200.0/24

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 may 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 does not 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 will not work.
    • Gateway subnet: This field is already autofilled. You cannot change the name. If you try to change the name using PowerShell or any other means, the gateway will not work properly.
    • Address range (CIDR block): While it is 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 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.

  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 UserPersonalCertificates 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 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 or later PowerShell instructions: These instructions require Windows 10 or later 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 or later 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:

  • 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 nameusername 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 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 may 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

Note

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

  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 AuthoritiesCertificates. 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………………..: 192.168.130.2(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 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.

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.

VPN
Gateway
Generation		 SKU S2S/VNet-to-VNet
Tunnels		 P2S
SSTP Connections		 P2S
IKEv2/OpenVPN Connections		 Aggregate
Throughput Benchmark		 BGP Zone-redundant
Generation1 Basic Max. 10 Max. 128 Not Supported 100 Mbps Not Supported No
Generation1 VpnGw1 Max. 30 Max. 128 Max. 250 650 Mbps Supported No
Generation1 VpnGw2 Max. 30 Max. 128 Max. 500 1 Gbps Supported No
Generation1 VpnGw3 Max. 30 Max. 128 Max. 1000 1.25 Gbps Supported No
Generation1 VpnGw1AZ Max. 30 Max. 128 Max. 250 650 Mbps Supported Yes
Generation1 VpnGw2AZ Max. 30 Max. 128 Max. 500 1 Gbps Supported Yes
Generation1 VpnGw3AZ Max. 30 Max. 128 Max. 1000 1.25 Gbps Supported Yes
Generation2 VpnGw2 Max. 30 Max. 128 Max. 500 1.25 Gbps Supported No
Generation2 VpnGw3 Max. 30 Max. 128 Max. 1000 2.5 Gbps Supported No
Generation2 VpnGw4 Max. 100* Max. 128 Max. 5000 5 Gbps Supported No
Generation2 VpnGw5 Max. 100* Max. 128 Max. 10000 10 Gbps Supported No
Generation2 VpnGw2AZ Max. 30 Max. 128 Max. 500 1.25 Gbps Supported Yes
Generation2 VpnGw3AZ Max. 30 Max. 128 Max. 1000 2.5 Gbps Supported Yes
Generation2 VpnGw4AZ Max. 100* Max. 128 Max. 5000 5 Gbps Supported Yes
Generation2 VpnGw5AZ Max. 100* Max. 128 Max. 10000 10 Gbps Supported Yes

(*) Use Virtual WAN if you need more than 100 S2S VPN tunnels.

  • The resizing of VpnGw SKUs is allowed within the same generation, except resizing of the Basic SKU. The Basic SKU is a legacy SKU and has feature limitations. In order to move from Basic to another SKU, you must delete the Basic SKU VPN gateway and create a new gateway with the desired Generation and SKU size combination. (see Working with Legacy SKUs).

  • These connection limits are separate. For example, you can have 128 SSTP connections and also 250 IKEv2 connections on a VpnGw1 SKU.

  • Pricing information can be found on the Pricing page.

  • SLA (Service Level Agreement) information can be found on the SLA page.

  • If you have a lot of P2S connections, it can negatively impact your S2S connections. The Aggregate Throughput Benchmarks were tested by maximizing a combination of S2S and P2S connections. A single P2S or S2S connection can have a much lower throughput.

  • Note that all benchmarks aren’t guaranteed due to Internet traffic conditions and your application behaviors

To help our customers understand the relative performance of SKUs using different algorithms, we used publicly available iPerf and CTSTraffic tools to measure performances for site-to-site connections. The table below lists the results of performance tests for VpnGw SKUs. As you can see, the best performance is obtained when we used GCMAES256 algorithm for both IPsec Encryption and Integrity. We got average performance when using AES256 for IPsec Encryption and SHA256 for Integrity. When we used DES3 for IPsec Encryption and SHA256 for Integrity we got lowest performance.

A VPN tunnel connects to a VPN gateway instance. Each instance throughput is mentioned in the above throughput table and is available aggregated across all tunnels connecting to that instance.

The table below shows the observed bandwidth and packets per second throughput per tunnel for the different gateway SKUs. All testing was performed between gateways (endpoints) within Azure across different regions with 100 connections and under standard load conditions.

Generation SKU Algorithms
used		 Throughput
observed per tunnel		 Packets per second per tunnel
observed
Generation1 VpnGw1 GCMAES256
AES256 & SHA256
DES3 & SHA256		 650 Mbps
500 Mbps
130 Mbps		 62,000
47,000
12,000
Generation1 VpnGw2 GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.2 Gbps
650 Mbps
140 Mbps		 100,000
61,000
13,000
Generation1 VpnGw3 GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.25 Gbps
700 Mbps
140 Mbps		 120,000
66,000
13,000
Generation1 VpnGw1AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 650 Mbps
500 Mbps
130 Mbps		 62,000
47,000
12,000
Generation1 VpnGw2AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.2 Gbps
650 Mbps
140 Mbps		 110,000
61,000
13,000
Generation1 VpnGw3AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.25 Gbps
700 Mbps
140 Mbps		 120,000
66,000
13,000
Generation2 VpnGw2 GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.25 Gbps
550 Mbps
130 Mbps		 120,000
52,000
12,000
Generation2 VpnGw3 GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.5 Gbps
700 Mbps
140 Mbps		 140,000
66,000
13,000
Generation2 VpnGw4 GCMAES256
AES256 & SHA256
DES3 & SHA256		 2.3 Gbps
700 Mbps
140 Mbps		 220,000
66,000
13,000
Generation2 VpnGw5 GCMAES256
AES256 & SHA256
DES3 & SHA256		 2.3 Gbps
700 Mbps
140 Mbps		 220,000
66,000
13,000
Generation2 VpnGw2AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.25 Gbps
550 Mbps
130 Mbps		 120,000
52,000
12,000
Generation2 VpnGw3AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 1.5 Gbps
700 Mbps
140 Mbps		 140,000
66,000
13,000
Generation2 VpnGw4AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 2.3 Gbps
700 Mbps
140 Mbps		 220,000
66,000
13,000
Generation2 VpnGw5AZ GCMAES256
AES256 & SHA256
DES3 & SHA256		 2.3 Gbps
700 Mbps
140 Mbps		 220,000
66,000
13,000

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

Know more about this !

Try Our Hosting Partners Hostinger.com Today!

Contact Us Now!

You are a:

1 + 7 =