Creating and Configuring Virtual Network Gateway (Point-to-Site) Using Azure Certification Authentication

Ensuring secure connectivity to database resource is an important requirement and consideration for customers running an in cloud environment. Today customers want to connect to their Azure Database for PostgreSQL from both inside/outside of Azure, and based on the security and compliance requirements, organizations can choose one of the options provided by Azure Database for PostgreSQL. In this section, we will outline detailed steps on how to connect securely from an On-Premise to Azure Database for PostgreSQL using Point-to-Site Gateway.

A Point-to-Site (P2S) VPN gateway connection lets us create a secure connection to our virtual network from an individual client computer. A P2S connection is established by starting it from the client’s computer. This solution is useful for telecommuters who want to connect to Azure VNETs from a remote location, such as from home or a conference.

Point-to-site native Azure certificate authentication connections use the following items, which we configure in this exercise:

*A route-based 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 is generated from the root certificate. The client certificate is installed on each client computer that will connect to the VNet. This certificate is used for client authentication.

*VPN client configuration. The VPN client is configured using VPN client configuration files. These 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.

The virtual network gateway uses a specific subnet called the gateway subnet. The gateway subnet is part of the virtual network IP address range that we specify when configuring our virtual network. It contains the IP addresses that the virtual network gateway resources and services use.

When we create the gateway subnet, we specify the number of IP addresses that the subnet contains. The number of IP addresses needed depends on the VPN gateway configuration that we want to create. Some configurations require more IP addresses than others. Microsoft recommends that we create a gateway subnet that uses a /27 or /28.

1. In Search resources, services, and docs (G+/) type virtual network gateway. Locate Virtual network gateway in the Marketplace search results and select it to open the Create virtual network gateway page.

2. On the Basics tab, fill in the values for Project details and Instance details.

3. Specify the values for Public IP address. These settings specify the public IP address object that gets associated to the VPN gateway. The public IP address is dynamically assigned to this object 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 our VPN gateway.

4. Select Review + create to run validation.

5. Once validation passes, select Create to deploy the VPN gateway.

6. Generate and export certificates for Point-to-site using Powershell.

a) Generate a Self-signed root certificate.

i) From a computer running Windows 10 or Windows Server 2016, open a Windows PowerShell console with elevated privileges.

ii) Use the following script to create the self-signed root certificate. The following script creates a self-signed root certificate named ‘P2SRootCert’ that is automatically installed in ‘Certificates-Current User\Personal\Certificates’. You can view the certificate by opening certmgr.msc, or Manage User Certificates.

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature `

-Subject “CN=P2SRootCert” -KeyExportPolicy Exportable `

-HashAlgorithm sha256 -KeyLength 2048 `

-CertStoreLocation “Cert:\CurrentUser\My” -KeyUsageProperty Sign -KeyUsage CertSign

iii) Leave the PowerShell console open and proceed with the next steps to generate a client certificate.

b) Generate a Client certificate.

i) Use the following command if PowerShell console is not closed after creating the self-signed root certificate. The client certificate that we generate is automatically installed in ‘Certificates — Current User\Personal\Certificates’ on your computer.

New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature `

-Subject “CN=P2SChildCert” -KeyExportPolicy Exportable `

-HashAlgorithm sha256 -KeyLength 2048 `

-CertStoreLocation “Cert:\CurrentUser\My” `

Signer $cert -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.2”)

c) Export the root certificate public key (.cer)

After creating a self-signed root certificate, export the root certificate public key .cer file (not the private key). We will later upload this file to Azure. The following steps helps to export the .cer file for our self-signed root certificate:

i) To obtain a .cer file from the certificate, open Manage user certificates. Locate the self-signed root certificate, typically in ‘Certificates — Current User\Personal\Certificates’, and right-click. Click All Tasks, and then click Export. This opens the Certificate Export Wizard. If we can’t find the certificate under Current User\Personal\Certificates, we may have accidentally opened “Certificates — Local Computer”, rather than “Certificates — Current User”). If we want to open Certificate Manager in current user scope using PowerShell, we type certmgr in the console window.

ii) In the Wizard, click Next.

iii) Select No, do not export the private key, and then click Next.

iv) On the Export File Format page, select Base-64 encoded X.509 (.CER)., and then click Next.

v) On the File to Export screen, browse to the location to which we want to export the certificate. For File name, name the certificate file. Then, click Next.

vi) Click Finish to export the certificate.

vii) Your certificate is successfully exported.

viii) The exported certificate looks similar to this:

ix) If we open the exported certificate using Notepad, we see something similar to this example. The section in blue contains the information that is uploaded to Azure. If we open our certificate with Notepad and it does not look similar to this, typically this means we did not export it using the Base-64 encoded X.509(.CER) format. Additionally, if we want to use a different text editor, understand that some editors can introduce unintended formatting in the background. This can create problems when uploaded the text from this certificate to Azure.

d) Export the Client certificate.

When we generate a client certificate, it’s automatically installed on the computer that we used to generate it. If we want to install the client certificate on another client computer, we need to export the client certificate that we generated.

i) To export a client certificate, open Manage user certificates. The client certificates that we generated are, by default, located in ‘Certificates — Current User\Personal\Certificates’. Right-click the client certificate that we want to export, click all tasks, and then click Export to open the Certificate Export Wizard.

ii) In the Certificate Export Wizard, click Next to continue.

iii) Select Yes, export the private key, and then click Next.

iv) On the Export File Format page, leave the defaults selected. Make sure that Include all certificates in the certification path if possible is selected. This setting additionally exports the root certificate information that is required for successful client authentication. Without it, client authentication fails because the client doesn’t have the trusted root certificate. Then, click Next.

v) On the Security page, we must protect the private key. If we select to use a password, make sure to record or remember the password that we set for this certificate. Then, click Next.

vi) On the File to Export, Browse to the location to which we want to export the certificate. For File name, name the certificate file. Then, click Next.

vii) Click Finish to export the certificate.

7. Add the VPN Client address pool.

The client address pool is a range of private IP addresses that we specify. The clients that connect over a Point-to-Site VPN dynamically receive an IP address from this range. Use a private IP address range that does not overlap with the on-premises location that we connect from, or the VNet that we want to connect to. If we configure multiple protocols and SSTP is one of the protocols, then the configured address pool is split between the configured protocols equally.

i) Once the virtual network gateway has been created, navigate to the Settings section of the virtual network gateway page. In Settings, select Point-to-site configuration. Select Configure now to open the configuration page.

ii) On the Point-to-site configuration page, in the Address pool box, add the private IP address range that we want to use. VPN clients dynamically receive an IP address from the range that we specify. The minimum subnet mask is 29 bit for active/passive and 28 bit for active/active configuration.

iii) Continue to the next section to configure authentication and tunnel types.

8. Specify Tunnel type and Authentication type.

In this section, we specify the tunnel type and the authentication type. If we don’t see tunnel type or authentication type on the Point-to-site configuration page, our gateway is using the Basic SKU. The Basic SKU does not support IKEv2 or RADIUS authentication. If we want to use these settings, we need to delete and recreate the gateway using a different gateway SKU.

a) Tunnel type.

On the Point-to-site configuration page, select the Tunnel type. When selecting the tunnel type, note the following:

i) The strongSwan client on Android and Linux and the native IKEv2 VPN client on iOS and macOS will use only the IKEv2 tunnel type to connect.

ii) Windows clients will try IKEv2 first and if that doesn’t connect, they fall back to SSTP.

iii) We can use the OpenVPN client to connect to the OpenVPN tunnel type.

b) Authentication type.

For Authentication type, select Azure certificate.

9. Upload root certificate public key information

In this section, we upload public root certificate data to Azure. Once the public certificate data is uploaded, Azure can use it to authenticate clients that have installed a client certificate generated from the trusted root certificate.

i) Navigate to our Virtual network gateway -> Point-to-site configuration page in the Root certificate section. This section is only visible if we have selected Azure certificate for the authentication type.

ii) Open the certificate with a text editor, such as Notepad. When copying the certificate data, make sure that we copy the text as one continuous line without carriage returns or line feeds. We may need to modify our view in the text editor to ‘Show Symbol/Show all characters’ to see the carriage returns and line feeds. Copy only the following section as one continuous line:

iii) In the Root certificate section, we can add up to 20 trusted root certificates.

iv) Paste the certificate data into the Public certificate data field.

v) Name the certificate.

vi) Select Save at the top of the page to save all of the configuration settings.

10. Generate and install VPN client profile configuration files for certificate authentication.

When we connect to an Azure VNet using Point-to-Site and certificate authentication, we use the VPN client that is natively installed on the operating system from which we’re connecting. All of the necessary configuration settings for the VPN clients are contained in a VPN client configuration zip file. The settings in the zip file help you easily configure the VPN clients for Windows, Mac IKEv2 VPN, or Linux.

The VPN client configuration files that we generate are specific to the P2S VPN gateway configuration for the virtual network. If there are any changes to the Point-to-Site VPN configuration after we generate the files, such as changes to the VPN protocol type or authentication type, we need to generate new VPN client configuration files and apply the new configuration to all of the VPN clients that we want to connect.

a) Generate files using Azure Portal.

i) In the Azure portal, navigate to the virtual network gateway for the virtual network that we want to connect to.

ii) On the virtual network gateway page, select Point-to-site configuration to open the Point-to-site configuration page.

iii) At the top of the Point-to-site configuration page, select Download VPN client. This doesn’t download VPN client software, it generates the configuration package used to configure VPN clients. It takes a few minutes for the client configuration package to generate. During this time, we may not see any indications until the packet has generated.

iv) Once the configuration package has been generated, our browser indicates that a client configuration zip file is available. It’s named the same name as our gateway. Unzip the file to view the folders.

b) Install the configuration files.

i) Select the VPN client configuration files that correspond to the architecture of the Windows computer. For a 64-bit processor architecture, choose the ‘VpnClientSetupAmd64’ installer package. For a 32-bit processor architecture, choose the ‘VpnClientSetupX86’ installer package.

ii) Double-click the package to install it. If we see a SmartScreen popup, click More info, then Run anyway.

11. Test the connection

i) To connect to our VNet, on the client computer, navigate to VPN settings and locate the VPN connection that we created. It’s named the same name as our virtual network. Select Connect. A pop-up message may appear that refers to using the certificate. Select Continue to use elevated privileges.

ii) On the Connection status page, select Connect to start the connection. If we see a Select Certificate screen, verify that the client certificate showing is the one that we want to use to connect. If it is not, use the drop-down arrow to select the correct certificate, and then select OK.

iii) Your connection is established.

This is part two of a four-part series that can be viewed below:

Part 1 — Creating Virtual Network and PostgreSQL
Part 3 — Installing ODBC driver for remote connection to PostgreSQL DB
Part 4 — Configuring a Data Gateway in Power BI

If you found this interesting or have any feedback, please let me know in the comments section.

About the Author:
Raghavendra BN is a DevOps Engineer, currently working in Version 1’s Foundation’s team. Follow Version 1 and Raghavendra BN for more blogs around Microsoft Azure and Azure DevOps.