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

This article shows you how to create a VNet with a Point-to-Site connection in the Resource Manager deployment model using PowerShell. This configuration uses certificates for authentication. In this configuration, the Azure VPN gateway performs validation of the certificate, rather than a RADIUS server. You can also create this configuration using a different deployment tool or deployment model by selecting a different option from the following list:

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

Connecting clients can use the following authentication methods:

  • RADIUS server - Currently in Preview
  • VPN Gateway native Azure certificate authentication

This article helps you configure a P2S configuration with authentication using the native Azure certificate authentication. If you want to use RADIUS to authenticate connecting users, see P2S using RADIUS authentication.

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

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.

  • SSTP is an SSL-based VPN tunnel that is supported only on Windows client platforms. It can penetrate firewalls, which makes it an ideal option to connect to Azure from anywhere. 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.

  • IKEv2 VPN, a standards-based IPsec VPN solution. IKEv2 VPN can be used to connect from Mac devices (OSX versions 10.11 and above). IKEv2 is currently in Preview.

Note

IKEv2 for P2S is currently in Preview.

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

  • A RouteBased VPN gateway.
  • The public key (.cer file) for a root certificate, which is uploaded to Azure. Once the certificate is uploaded, it is considered a trusted certificate and is used for authentication.
  • A client certificate that is generated from the root certificate and installed on each client computer that will connect to the VNet. This certificate is used for client authentication.
  • A VPN client configuration. The VPN client configuration 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.

For more information about Point-to-Site connections, see About Point-to-Site connections.

Before you begin

Example values

You can use the example values to create a test environment, or refer to these values to better understand the examples in this article. We set the variables in section 1 of the article. You can either use the steps as a walk-through and use the values without changing them, or change them to reflect your environment.

  • Name: VNet1
  • Address space: 192.168.0.0/16 and 10.254.0.0/16
    For this example, we use more than one address space to illustrate that this configuration works with multiple address spaces. However, multiple address spaces are not required for this configuration.
  • Subnet name: FrontEnd
    • Subnet address range: 192.168.1.0/24
  • Subnet name: BackEnd
    • Subnet address range: 10.254.1.0/24
  • Subnet name: GatewaySubnet
    The Subnet name GatewaySubnet is mandatory for the VPN gateway to work.
    • GatewaySubnet address range: 192.168.200.0/24
  • VPN 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 VPN client address pool.
  • Subscription: If you have more than one subscription, verify that you are using the correct one.
  • Resource Group: TestRG
  • Location: East US
  • DNS Server: IP address of the DNS server that you want to use for name resolution. (optional)
  • GW Name: Vnet1GW
  • Public IP name: VNet1GWPIP
  • VpnType: RouteBased

1. Log in and set variables

In this section, you log in and declare the values used for this configuration. The declared values are used in the sample scripts. Change the values to reflect your own environment. Or, you can use the declared values and go through the steps as an exercise.

  1. Open your PowerShell console with elevated privileges, and log in to your Azure account. This cmdlet prompts you for the login credentials. After logging in, it downloads your account settings so that they are available to Azure PowerShell.

    Login-AzureRmAccount
    
  2. Get a list of your Azure subscriptions.

    Get-AzureRmSubscription
    
  3. Specify the subscription that you want to use.

    Select-AzureRmSubscription -SubscriptionName "Name of subscription"
    
  4. Declare the variables that you want to use. Use the following sample, substituting the values for your own when necessary.

    $VNetName  = "VNet1"
    $FESubName = "FrontEnd"
    $BESubName = "Backend"
    $GWSubName = "GatewaySubnet"
    $VNetPrefix1 = "192.168.0.0/16"
    $VNetPrefix2 = "10.254.0.0/16"
    $FESubPrefix = "192.168.1.0/24"
    $BESubPrefix = "10.254.1.0/24"
    $GWSubPrefix = "192.168.200.0/26"
    $VPNClientAddressPool = "172.16.201.0/24"
    $RG = "TestRG"
    $Location = "East US"
    $GWName = "VNet1GW"
    $GWIPName = "VNet1GWPIP"
    $GWIPconfName = "gwipconf"
    

2. Configure a VNet

  1. Create a resource group.

    New-AzureRmResourceGroup -Name $RG -Location $Location
    
  2. Create the subnet configurations for the virtual network, naming them FrontEnd, BackEnd, and GatewaySubnet. These prefixes must be part of the VNet address space that you declared.

    $fesub = New-AzureRmVirtualNetworkSubnetConfig -Name $FESubName -AddressPrefix $FESubPrefix
    $besub = New-AzureRmVirtualNetworkSubnetConfig -Name $BESubName -AddressPrefix $BESubPrefix
    $gwsub = New-AzureRmVirtualNetworkSubnetConfig -Name $GWSubName -AddressPrefix $GWSubPrefix
    
  3. Create the virtual network.

    In this example, the -DnsServer server parameter is optional. 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 from your VNet. For this example, we used a private IP address, but it is likely that this is not the IP address of your DNS server. Be sure to use your own values. The value you specify is used by the resources that you deploy to the VNet, not by the P2S connection or the VPN client.

    New-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG -Location $Location -AddressPrefix $VNetPrefix1,$VNetPrefix2 -Subnet $fesub, $besub, $gwsub -DnsServer 10.2.1.3
    
  4. Specify the variables for the virtual network you created.

    $vnet = Get-AzureRmVirtualNetwork -Name $VNetName -ResourceGroupName $RG
    $subnet = Get-AzureRmVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet
    
  5. A VPN gateway must have a Public IP address. You first request the IP address resource, and then refer to it when creating your virtual network gateway. The IP address is dynamically assigned to the resource when the VPN gateway is created. VPN Gateway currently only supports Dynamic Public IP address allocation. You cannot request a Static Public IP address assignment. However, it doesn't mean that the IP address changes after it has been assigned to your VPN gateway. The only time the Public IP address changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.

    Request a dynamically assigned public IP address.

    $pip = New-AzureRmPublicIpAddress -Name $GWIPName -ResourceGroupName $RG -Location $Location -AllocationMethod Dynamic
    $ipconf = New-AzureRmVirtualNetworkGatewayIpConfig -Name $GWIPconfName -Subnet $subnet -PublicIpAddress $pip
    

3. Create the VPN gateway

Configure and create the virtual network gateway for your VNet.

  • The -GatewayType must be Vpn and the -VpnType must be RouteBased.
  • The -VpnClientProtocols is used to specify the types of tunnels that you would like to enable. The two tunnel options are SSTP and IKEv2. You can choose to enable one of them or both. If you want to enable both, then specify both the names separated by a comma. The Strongswan client on Android and Linux and the native IKEv2 VPN client on iOS and OSX will use only IKEv2 tunnel to connect. Windows clients try IKEv2 first and if that doesn’t connect, they fall back to SSTP.
  • A VPN gateway can take up to 45 minutes to complete, depending on the gateway sku you select. In this example, we use IKEv2, which is currently available in Preview.
New-AzureRmVirtualNetworkGateway -Name $GWName -ResourceGroupName $RG `
-Location $Location -IpConfigurations $ipconf -GatewayType Vpn `
-VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw1 -VpnClientProtocols "IKEv2"

4. Add the VPN client address pool

After the VPN gateway finishes creating, you can add the VPN client address pool. The VPN client address pool is the range from which the VPN clients receive an IP address when connecting. Use a private IP address range that does not overlap with the on-premises location that you connect from, or with the VNet that you want to connect to. In this example, the VPN client address pool is declared as a variable in Step 1.

$Gateway = Get-AzureRmVirtualNetworkGateway -ResourceGroupName $RG -Name $GWName
Set-AzureRmVirtualNetworkGateway -VirtualNetworkGateway $Gateway -VpnClientAddressPool $VPNClientAddressPool

5. Generate certificates

Certificates are used by Azure 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 certificate store. The certificate is used to authenticate the client when it initiates a connection to the VNet.

If you use self-signed certificates, they must be created using specific parameters. You can create a self-signed certificate using the instructions for PowerShell and Windows 10, or, if you don't have Windows 10, you can use MakeCert. It's important that you follow the steps in the instructions when generating self-signed root certificates and client certificates. Otherwise, the certificates you generate will not be compatible with P2S connections and you receive a connection error.

1. Obtain the .cer file for the root certificate

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

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

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

2. Generate a client certificate

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

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

You can generate client certificates using the following methods:

  • Enterprise certificate:

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

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

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

6. Upload the root certificate public key information

Verify that your VPN gateway has finished creating. Once it has completed, you can upload the .cer file (which contains the public key information) for a trusted root certificate to Azure. Once a.cer file is uploaded, Azure can use it to authenticate clients that have installed a client certificate generated from the trusted root certificate. You can upload additional trusted root certificate files - up to a total of 20 - later, if needed.

  1. Declare the variable for your certificate name, replacing the value with your own.

    $P2SRootCertName = "P2SRootCert.cer"
    
  2. Replace the file path with your own, and then run the cmdlets.

    $filePathForCert = "C:\cert\P2SRootCert.cer"
    $cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2($filePathForCert)
    $CertBase64 = [system.convert]::ToBase64String($cert.RawData)
    $p2srootcert = New-AzureRmVpnClientRootCertificate -Name $P2SRootCertName -PublicCertData $CertBase64
    
  3. Upload the public key information to Azure. Once the certificate information is uploaded, Azure considers this to be a trusted root certificate.

    Add-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG" -PublicCertData $CertBase64
    

7. Install an exported client certificate

If you want to create a P2S connection from a client computer other than the one you used to generate the client certificates, you need to install a client certificate. When installing a client certificate, you need the password that was created when the client certificate was exported.

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.

8. Configure the native VPN client

The VPN client configuration files contain settings to configure devices to connect to a VNet over a P2S connection. For instructions to generate and install VPN client configuration files, see Create and install VPN client configuration files for native Azure certificate authentication P2S configurations.

9. Connect to Azure

To connect from a Windows VPN client

  1. To connect to your VNet, on the client computer, navigate to VPN connections and locate the VPN connection that you created. It is named the same name as your virtual network. Click Connect. A pop-up message may appear that refers to using the certificate. Click Continue to use elevated privileges.
  2. On the Connection status page, click Connect to start the connection. If you see a Select Certificate screen, verify that the client certificate showing is the one that you want to use to connect. If it is not, use the drop-down arrow to select the correct certificate, and then click OK.

    VPN client connects to Azure

  3. Your connection is established.

    Connection established

Troubleshooting Windows client P2S connections

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

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

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

  • 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, then click Connect.

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

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

To troubleshoot an RDP connection to a VM

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

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

To add or remove a root certificate

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

To add a trusted root certificate

You can add up to 20 root certificate .cer files to Azure. The following steps help you add a root certificate:

Method 1

This is the most efficient method to upload a root certificate.

  1. Prepare the .cer file to upload:

    $filePathForCert = "C:\cert\P2SRootCert3.cer"
    $cert = new-object System.Security.Cryptography.X509Certificates.X509Certificate2($filePathForCert)
    $CertBase64_3 = [system.convert]::ToBase64String($cert.RawData)
    $p2srootcert = New-AzureRmVpnClientRootCertificate -Name $P2SRootCertName -PublicCertData $CertBase64_3
    
  2. Upload the file. You can only upload one file at a time.

    Add-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG" -PublicCertData $CertBase64_3
    
  3. To verify that the certificate file uploaded:

    Get-AzureRmVpnClientRootCertificate -ResourceGroupName "TestRG" `
    -VirtualNetworkGatewayName "VNet1GW"
    

Method 2

This method is has more steps than Method 1, but has the same result. It is included in case you need to view the certificate data.

  1. Create and prepare the new root certificate to add to Azure. Export the public key as a Base-64 encoded X.509 (.CER) and open it with a text editor. Copy the values, as shown in the following example:

    certificate

    Note

    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.

  2. Specify the certificate name and key information as a variable. Replace the information with your own, as shown in the following example:

    $P2SRootCertName2 = "ARMP2SRootCert2.cer"
    $MyP2SCertPubKeyBase64_2 = "MIIC/zCCAeugAwIBAgIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDU15UDJTUm9vdENlcnQwHhcNMTUxMjE5MDI1MTIxWhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw1NeVAyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjIXoWy8xE/GF1OSIvUaA0bxBjZ1PJfcXkMWsHPzvhWc2esOKrVQtgFgDz4ggAnOUFEkFaszjiHdnXv3mjzE2SpmAVIZPf2/yPWqkoHwkmrp6BpOvNVOpKxaGPOuK8+dql1xcL0eCkt69g4lxy0FGRFkBcSIgVTViS9wjuuS7LPo5+OXgyFkAY3pSDiMzQCkRGNFgw5WGMHRDAiruDQF1ciLNojAQCsDdLnI3pDYsvRW73HZEhmOqRRnJQe6VekvBYKLvnKaxUTKhFIYwuymHBB96nMFdRUKCZIiWRIy8Hc8+sQEsAML2EItAjQv4+fqgYiFdSWqnQCPf/7IZbotgQIDAQABo00wSzBJBgNVHQEEQjBAgBAkuVrWvFsCJAdK5pb/eoCNoRowGDEWMBQGA1UEAxMNTXlQMlNSb290Q2VydIIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAA4IBAQA223veAZEIar9N12ubNH2+HwZASNzDVNqspkPKD97TXfKHlPlIcS43TaYkTz38eVrwI6E0yDk4jAuPaKnPuPYFRj9w540SvY6PdOUwDoEqpIcAVp+b4VYwxPL6oyEQ8wnOYuoAK1hhh20lCbo8h9mMy9ofU+RP6HJ7lTqupLfXdID/XevI8tW6Dm+C/wCeV3EmIlO9KUoblD/e24zlo3YzOtbyXwTIh34T0fO/zQvUuBqZMcIPfM1cDvqcqiEFLWvWKoAnxbzckye2uk1gHO52d8AVL3mGiX8wBJkjc/pMdxrEvvCzJkltBmqxTM6XjDJALuVh16qFlqgTWCIcb7ju"
    
  3. Add the new root certificate. You can only add one certificate at a time.

    Add-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG" -PublicCertData $MyP2SCertPubKeyBase64_2
    
  4. You can verify that the new certificate was added correctly by using the following example:

    Get-AzureRmVpnClientRootCertificate -ResourceGroupName "TestRG" `
    -VirtualNetworkGatewayName "VNet1GW"
    

To remove a root certificate

  1. Declare the variables.

    $GWName = "Name_of_virtual_network_gateway"
    $RG = "Name_of_resource_group"
    $P2SRootCertName2 = "ARMP2SRootCert2.cer"
    $MyP2SCertPubKeyBase64_2 = "MIIC/zCCAeugAwIBAgIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAMBgxFjAUBgNVBAMTDU15UDJTUm9vdENlcnQwHhcNMTUxMjE5MDI1MTIxWhcNMzkxMjMxMjM1OTU5WjAYMRYwFAYDVQQDEw1NeVAyU1Jvb3RDZXJ0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyjIXoWy8xE/GF1OSIvUaA0bxBjZ1PJfcXkMWsHPzvhWc2esOKrVQtgFgDz4ggAnOUFEkFaszjiHdnXv3mjzE2SpmAVIZPf2/yPWqkoHwkmrp6BpOvNVOpKxaGPOuK8+dql1xcL0eCkt69g4lxy0FGRFkBcSIgVTViS9wjuuS7LPo5+OXgyFkAY3pSDiMzQCkRGNFgw5WGMHRDAiruDQF1ciLNojAQCsDdLnI3pDYsvRW73HZEhmOqRRnJQe6VekvBYKLvnKaxUTKhFIYwuymHBB96nMFdRUKCZIiWRIy8Hc8+sQEsAML2EItAjQv4+fqgYiFdSWqnQCPf/7IZbotgQIDAQABo00wSzBJBgNVHQEEQjBAgBAkuVrWvFsCJAdK5pb/eoCNoRowGDEWMBQGA1UEAxMNTXlQMlNSb290Q2VydIIQKazxzFjMkp9JRiX+tkTfSzAJBgUrDgMCHQUAA4IBAQA223veAZEIar9N12ubNH2+HwZASNzDVNqspkPKD97TXfKHlPlIcS43TaYkTz38eVrwI6E0yDk4jAuPaKnPuPYFRj9w540SvY6PdOUwDoEqpIcAVp+b4VYwxPL6oyEQ8wnOYuoAK1hhh20lCbo8h9mMy9ofU+RP6HJ7lTqupLfXdID/XevI8tW6Dm+C/wCeV3EmIlO9KUoblD/e24zlo3YzOtbyXwTIh34T0fO/zQvUuBqZMcIPfM1cDvqcqiEFLWvWKoAnxbzckye2uk1gHO52d8AVL3mGiX8wBJkjc/pMdxrEvvCzJkltBmqxTM6XjDJALuVh16qFlqgTWCIcb7ju"
    
  2. Remove the certificate.

    Remove-AzureRmVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -PublicCertData $MyP2SCertPubKeyBase64_2
    
  3. Use the following example to verify that the certificate was removed successfully.

    Get-AzureRmVpnClientRootCertificate -ResourceGroupName "TestRG" `
    -VirtualNetworkGatewayName "VNet1GW"
    

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.

Revoke a client certificate

  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. This string is declared as a variable in the next step.
  3. Declare the variables. Make sure to declare the thumbprint you retrieved in the previous step.

    $RevokedClientCert1 = "NameofCertificate"
    $RevokedThumbprint1 = "‎51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
    $GWName = "Name_of_virtual_network_gateway"
    $RG = "Name_of_resource_group"
    
  4. Add the thumbprint to the list of revoked certificates. You see "Succeeded" when the thumbprint has been added.

    Add-AzureRmVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `
    -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG `
    -Thumbprint $RevokedThumbprint1
    
  5. Verify that the thumbprint was added to the certificate revocation list.

    Get-AzureRmVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
    
  6. After the thumbprint has been added, 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.

To reinstate a client certificate

You can reinstate a client certificate by removing the thumbprint from the list of revoked client certificates.

  1. Declare the variables. Make sure you declare the correct thumbprint for the certificate that you want to reinstate.

    $RevokedClientCert1 = "NameofCertificate"
    $RevokedThumbprint1 = "‎51ab1edd8da4cfed77e20061c5eb6d2ef2f778c7"
    $GWName = "Name_of_virtual_network_gateway"
    $RG = "Name_of_resource_group"
    
  2. Remove the certificate thumbprint from the certificate revocation list.

    Remove-AzureRmVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `
    -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -Thumbprint $RevokedThumbprint1
    
  3. Check if the thumbprint is removed from the revoked list.

    Get-AzureRmVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
    

Point-to-Site FAQ

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

The following client operating systems are supported:

  • Windows 7 (32-bit and 64-bit)
  • Windows Server 2008 R2 (64-bit only)
  • Windows 8 (32-bit and 64-bit)
  • Windows 8.1 (32-bit and 64-bit)
  • Windows Server 2012 (64-bit only)
  • Windows Server 2012 R2 (64-bit only)
  • Windows 10
  • OSX version 10.11 for Mac (El Capitan)
  • macOS version 10.12 for Mac (Sierra)

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

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

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

Azure supports two types of Point-to-site VPN options:

  • Secure Socket Tunneling Protocol (SSTP). SSTP is a Microsoft proprietary SSL-based solution that can penetrate firewalls since most firewalls open the TCP port that 443 SSL uses.

  • IKEv2 VPN. IKEv2 VPN is a standards-based IPsec VPN solution that uses UDP port 500 and 4500 and IP protocol no. 50. Firewalls do not always open these ports, so there is a possibility of IKEv2 VPN not being able to traverse proxies and firewalls.

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

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

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

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

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

Yes. For the Resource Manager deployment model, you must have a RouteBased VPN type for your gateway. For the classic deployment model, you need a dynamic gateway. We do not support Point-to-Site for static routing VPN gateways or PolicyBased VPN gateways.

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

No. A Point-to-Site client can only connect to resources in the VNet in which the virtual network gateway resides.

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. For a VPN Gateway with only IKEv2 Point-to-Site VPN connections, the total throughput that you can expect depends on the Gateway SKU. For more information on throughput, see Gateway SKUs.

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

No. You can only use the native VPN client on Windows for SSTP, and the native VPN client on Mac for IKEv2. Refer to the list of supported client operating systems.

Does Azure support IKEv2 VPN with Windows?

Users can connect to Azure using the built-in Windows VPN client, which does support IKEv2. But, IKEv2 connections from a Windows device won't work in the following scenario:

When the user's device contains a large number of trusted root certificates, the message payload size during IKE exchange is large and causes IP layer fragmentation. The fragments are rejected at the Azure end, which results in the connection failing. The exact certificate count at which this problem occurs is difficult to estimate. As a result, IKEv2 connections from Windows devices are not guaranteed to work. When you configure both SSTP and IKEv2 in a mixed environment (consisting of Windows and Mac devices), the Windows VPN profile always tries IKEv2 tunnel first. If it fails due to the issue described here, it falls back to SSTP.

Other than Windows and Mac, which other platforms does Azure support for P2S VPN?

Azure supports only Windows and Mac for P2S VPN.

I already have an Azure VPN Gateway deployed. Can I enabled RADIUS and/or IKEv2 VPN on it?

Yes, you can enable these new features on already deployed gateways, both through Powershell and the Azure portal.

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

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

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.