Configure server settings for P2S VPN Gateway certificate authentication - PowerShell

This article helps you configure a point-to-site (P2S) VPN to securely connect individual clients running Windows, Linux, or macOS to an Azure virtual network (VNet) using Azure PowerShell. This article contains basic PowerShell configuration steps. For more comprehensive information about creating this type of P2S VPN, see the Azure portal article Configure a point-to-site VPN using the Azure portal.

P2S VPN connections are useful when you want to connect to your VNet from a remote location, such when you're telecommuting from home or a conference. You can also use P2S instead of a Site-to-Site VPN when you have only a few clients that need to connect to a VNet. P2S connections don't require a VPN device or a public-facing IP address. P2S creates the VPN connection over either SSTP (Secure Socket Tunneling Protocol), or IKEv2.

For more information about P2S VPN, see About P2S VPN.

P2S Azure certificate authentication connections use the following items, which you'll configure in this exercise:

• A route-based VPN gateway (not policy-based). For more information about VPN type, see VPN Gateway settings.
• The public key (.cer file) for a root certificate, which is uploaded to Azure. Once the certificate is uploaded, it's considered a trusted certificate and is used for authentication.
• A client certificate that is generated from the root certificate. The client certificate installed on each client computer that will connect to the VNet. This certificate is used for client authentication.
• VPN client configuration files. The VPN client is configured using VPN client configuration files. These files contain the necessary information for the client to connect to the VNet. Each client that connects must be configured using the settings in the configuration files.

Prerequisites

Verify that you have an Azure subscription. If you don't already have an Azure subscription, you can sign up for a trial account.

Azure PowerShell

You can install and run the Azure PowerShell cmdlets locally on your computer. PowerShell cmdlets are updated frequently. If you haven't installed the latest version, the values specified in the instructions may fail. To find the versions of Azure PowerShell installed on your computer, use the Get-Module -ListAvailable Az cmdlet. To install or update, see Install the Azure PowerShell module.

Sign in

Open the PowerShell console with elevated privileges and connect to your Azure account. The Connect-AzAccount -Environment AzureChinaCloud cmdlet prompts you for credentials. After you authenticate, it downloads your account settings so that they're available to Azure PowerShell. You can change subscription by using Get-AzSubscription and Select-AzSubscription -SubscriptionName "Name of subscription".

Create a VNet

1. Create a resource group using New-AzResourceGroup.

   New-AzResourceGroup -Name "TestRG1" -Location "ChinaEast2"
   

2. Create the virtual network using New-AzVirtualNetwork.

   $vnet = New-AzVirtualNetwork `
   -ResourceGroupName "TestRG1" `
   -Location "ChinaEast2" `
   -Name "VNet1" `
   -AddressPrefix 10.1.0.0/16
   

3. Create subnets using New-AzVirtualNetworkSubnetConfig with the following names: FrontEnd and GatewaySubnet (a gateway subnet must be named GatewaySubnet).

   $subnetConfigFrontend = Add-AzVirtualNetworkSubnetConfig `
     -Name Frontend `
     -AddressPrefix 10.1.0.0/24 `
     -VirtualNetwork $vnet
   
   $subnetConfigGW = Add-AzVirtualNetworkSubnetConfig `
     -Name GatewaySubnet `
     -AddressPrefix 10.1.255.0/27 `
     -VirtualNetwork $vnet
   

4. Write the subnet configurations to the virtual network with Set-AzVirtualNetwork, which creates the subnets in the virtual network:

   $vnet | Set-AzVirtualNetwork
   

Create the VPN gateway

Request a public IP address

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 statically assigned to the resource when the VPN gateway is created. The only time the Public IP address changes is when the gateway is deleted and re-created. It doesn't change across resizing, resetting, or other internal maintenance/upgrades of your VPN gateway.

1. Request a public IP address for your VPN gateway using New-AzPublicIpAddress.

   $gwpip = New-AzPublicIpAddress -Name "GatewayIP" -ResourceGroupName "TestRG1" -Location "ChinaEast2" -AllocationMethod Static -Sku Standard
   

2. Create the gateway IP address configuration using New-AzVirtualNetworkGatewayIpConfig. This configuration is referenced when you create the VPN gateway.

   $vnet = Get-AzVirtualNetwork -Name "VNet1" -ResourceGroupName "TestRG1"
   $gwsubnet = Get-AzVirtualNetworkSubnetConfig -Name 'GatewaySubnet' -VirtualNetwork $vnet
   $gwipconfig = New-AzVirtualNetworkGatewayIpConfig -Name gwipconfig1 -SubnetId $gwsubnet.Id -PublicIpAddressId $gwpip.Id
   

Create the VPN gateway

In this step, you configure and create the virtual network gateway for your VNet. For more complete information about authentication and tunnel type, see Specify tunnel and authentication type in the Azure portal version of this article.

• The -GatewayType must be Vpn and the -VpnType must be RouteBased.
• The -VpnClientProtocol is used to specify the types of tunnels that you would like to enable. The tunnel options are OpenVPN, SSTP, and IKEv2. You can choose to enable one of them or any supported combination. If you want to enable multiple types, then specify the names separated by a comma. OpenVPN and SSTP can't be enabled together. The strongSwan client on Android and Linux and the native IKEv2 VPN client on macOS will use only the IKEv2 tunnel to connect. Windows clients try IKEv2 first and if that doesn’t connect, they fall back to SSTP. You can use the OpenVPN client to connect to OpenVPN tunnel type.
• The virtual network gateway 'Basic' SKU doesn't support IKEv2, OpenVPN, or RADIUS authentication. If you're planning on having Mac clients connect to your virtual network, don't use the Basic SKU.
• A VPN gateway can take 45 minutes or more to build, depending on the Gateway SKU you select.

1. Create the virtual network gateway with the gateway type "Vpn" using New-AzVirtualNetworkGateway.

   In this example, we use the VpnGw2, Generation 2 SKU. If you see ValidateSet errors regarding the GatewaySKU value and are running these commands locally, verify that you have installed the latest version of the PowerShell cmdlets. The latest version contains the new validated values for the latest Gateway SKUs.

   New-AzVirtualNetworkGateway -Name "VNet1GW" -ResourceGroupName "TestRG1" `
   -Location "ChinaEast2" -IpConfigurations $gwipconfig -GatewayType Vpn `
   -VpnType RouteBased -EnableBgp $false -GatewaySku VpnGw2 -VpnGatewayGeneration "Generation2" -VpnClientProtocol IkeV2,OpenVPN
   

2. Once your gateway is created, you can view it using the following example.

   Get-AzVirtualNetworkGateway -Name VNet1GW -ResourceGroup TestRG1
   

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 doesn't overlap with the on-premises location that you connect from, or with the VNet that you want to connect to.

1. Declare the following variables:

   $VNetName  = "VNet1"
   $VPNClientAddressPool = "172.16.201.0/24"
   $RG = "TestRG1"
   $Location = "ChinaEast2"
   $GWName = "VNet1GW"
   

2. Add the VPN client address pool:

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

Generate certificates

Certificates are used by Azure to authenticate VPN clients for P2S 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 for Windows computers running Windows 10 or later. If you aren't running Windows 10 or later, use MakeCert instead.

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 won't be compatible with P2S connections and you receive a connection error.

Root certificate

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

   • Enterprise certificate: If you're using an enterprise solution, you can use your existing certificate chain. Acquire the .cer file for the root certificate that you want to use.

   • Self-signed root certificate: If you aren't using an enterprise certificate solution, create a self-signed root certificate. Otherwise, the certificates you create won't be compatible with your P2S connections and clients receive a connection error when they try to connect. You can use Azure PowerShell, MakeCert, or OpenSSL. The steps in the following articles describe how to generate a compatible self-signed root certificate:

     • PowerShell instructions for Windows 10 or later: These instructions require PowerShell on a computer running Windows 10 or later. Client certificates that are generated from the root certificate can be installed on any supported P2S client.
     • MakeCert instructions: Use MakeCert to generate certificates if you don't have access to a computer running Windows 10 or later. Although MakeCert is deprecated, you can still use it to generate certificates. Client certificates that you generate from the root certificate can be installed on any supported P2S client.
     • Linux - OpenSSL instructions
     • Linux - strongSwan instructions

2. After you create the root certificate, export the public certificate data (not the private key) as a Base64 encoded X.509 .cer file.

Client certificate

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

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

   You can generate client certificates by using the following methods:

   • Enterprise certificate:

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

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

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

     When you generate a client certificate from a self-signed root certificate, it's automatically installed on the computer that you used to generate it. If you want to install a client certificate on another client computer, export it as a .pfx file, along with the entire certificate chain. Doing so will create a .pfx file that contains the root certificate information required for the client to authenticate.

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

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

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

     • Linux: See strongSwan or OpenSSL instructions.

2. After you create client certificate, export it. Each client computer requires a client certificate in order to connect and authenticate.

Upload 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)
   

3. Upload the public key information to Azure. Once the certificate information is uploaded, Azure considers it to be a trusted root certificate. When uploading, make sure you're running PowerShell locally on your computer, or instead, you can use the Azure portal steps. When the upload is complete, you'll see a PowerShell return showing PublicCertData. It takes about 10 minutes for the certificate upload process to complete.

   Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG1" -PublicCertData $CertBase64
   

Install an exported client certificate

The following steps help you install on a Windows client. For additional clients and more information, see Install a client certificate.

1. Once the client certificate is exported, locate and copy the .pfx file to the client computer.
2. On the client computer, double-click the .pfx file to install. Leave the Store Location as Current User, and then select Next.
3. On the File to import page, don't make any changes. Select Next.
4. On the Private key protection page, input the password for the certificate, or verify that the security principal is correct, then select Next.
5. On the Certificate Store page, leave the default location, and then select Next.
6. Select Finish. On the Security Warning for the certificate installation, select Yes. You can comfortably select 'Yes' for this security warning because you generated the certificate.
7. The certificate is now successfully imported.

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.

Generate and download the VPN client profile configuration package

Each VPN client is configured using the files in a VPN client profile configuration package that you generate and download. The configuration package contains settings that are specific to the VPN gateway that you created. If you make changes to the gateway, such as changing a tunnel type, certificate, or authentication type, you must generate another VPN client profile configuration package and install it on each client. Otherwise, your VPN clients may not be able to connect.

When you generate VPN client configuration files, the value for '-AuthenticationMethod' is 'EapTls'. Generate the VPN client configuration files using the following command:

$profile=New-AzVpnClientConfiguration -ResourceGroupName "TestRG" -Name "VNet1GW" -AuthenticationMethod "EapTls"

$profile.VPNProfileSASUrl

Copy the URL to your browser to download the zip file.

Configure VPN clients and connect to Azure

For steps to configure your VPN clients and connect to Azure, see the following articles:

Authentication	Tunnel type	Client OS	VPN client
Certificate
	IKEv2, SSTP	Windows	Native VPN client
	IKEv2	macOS	Native VPN client
	IKEv2	Linux	strongSwan
	OpenVPN	Windows	Azure VPN client OpenVPN client
	OpenVPN	macOS	OpenVPN client
	OpenVPN	Linux	Azure VPN Client OpenVPN client
Microsoft Entra ID
	OpenVPN	Windows	Azure VPN client

To verify a 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 P2S 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.13(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's deployed to your virtual network 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're 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 VM in the Azure portal. View the properties for the VM. The private IP address is listed.

   • PowerShell: Use the example to view a list of VMs and private IP addresses from your resource groups. You don't need to modify this example before using it.

     $VMs = Get-AzVM
     $Nics = Get-AzNetworkInterface | Where-Object 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're connected to your virtual network.

3. Open Remote Desktop Connection by entering RDP or Remote Desktop Connection in the search box on the taskbar. Then select Remote Desktop Connection. You can also open Remote Desktop Connection by using the mstsc command in PowerShell.

4. In Remote Desktop Connection, enter the private IP address of the VM. You can select Show Options to adjust other settings and then connect.

If you're having trouble connecting to a VM over your VPN connection, check the following points:

• Verify that your VPN connection is successful.
• Verify that you're connecting to the private IP address for the VM.
• If you can connect to the VM by using the private IP address but not the computer name, verify that you've configured DNS properly. For more information about how name resolution works for VMs, see Name resolution for VMs.

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

• Verify that the VPN client configuration package was generated after the DNS server IP addresses were specified for the VNet. If you updated the DNS server IP addresses, generate and install a new VPN client configuration package.

• Use 'ipconfig' to check the IPv4 address assigned to the Ethernet adapter on the computer from which you're connecting. If the IP address is within the address range of the VNet that you're connecting to, or within the address range of your VPNClientAddressPool, this is referred to as an overlapping address space. When your address space overlaps in this way, the network traffic doesn't reach Azure, it stays on the local network.

To add or remove 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. These steps require Azure PowerShell cmdlets installed locally on your computer. You can also use the Azure portal to add root certificates.

To add:

You can add up to 20 root certificate .cer files to Azure. The following steps help you add 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)
   

2. Upload the file. You can only upload one file at a time.

   Add-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName -VirtualNetworkGatewayname "VNet1GW" -ResourceGroupName "TestRG1" -PublicCertData $CertBase64_3
   

3. To verify that the certificate file uploaded:

   Get-AzVpnClientRootCertificate -ResourceGroupName "TestRG1" `
   -VirtualNetworkGatewayName "VNet1GW"
   

To remove:

1. Declare the variables. Modify the variables in the example to match the certificate that you want to remove.

   $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-AzVpnClientRootCertificate -VpnClientRootCertificateName $P2SRootCertName2 -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -PublicCertData $MyP2SCertPubKeyBase64_2
   

3. Use the following example to verify that the certificate was removed successfully.

   Get-AzVpnClientRootCertificate -ResourceGroupName "TestRG1" `
   -VirtualNetworkGatewayName "VNet1GW"
   

To revoke or reinstate a client certificate

You can revoke client certificates. The certificate revocation list allows you to selectively deny P2S 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.

To revoke:

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's 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-AzVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `
   -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG `
   -Thumbprint $RevokedThumbprint1
   

5. Verify that the thumbprint was added to the certificate revocation list.

   Get-AzVpnClientRevokedCertificate -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:

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-AzVpnClientRevokedCertificate -VpnClientRevokedCertificateName $RevokedClientCert1 `
   -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG -Thumbprint $RevokedThumbprint1
   

3. Check if the thumbprint is removed from the revoked list.

   Get-AzVpnClientRevokedCertificate -VirtualNetworkGatewayName $GWName -ResourceGroupName $RG
   

P2S FAQ

For additional P2S information, see the VPN Gateway P2S FAQ

Next steps

Once your connection is complete, you can add virtual machines to your virtual networks. For more information, see Virtual Machines. To understand more about networking and virtual machines, see Azure and Linux VM network overview.

For P2S troubleshooting information, Troubleshooting: Azure P2S connection problems.