OpenVPN Security Advisory: Dec 14, 2018
Action needed: Important update for OpenVPN Access Server

Microsoft Azure BYOL appliance quick start guide

Request More Information

Introduction

The Microsoft Azure BYOL instance is a 64-bit based VM that is based on Ubuntu LTS (Long Term Support) that you can quickly launch on your Microsoft Azure account in order to get your VPN server up and running. To make it more convenient for you to deploy your server in the region closest to you, we currently offer the instance in all of Azure’s publicly available regions.

Important notes about the BYOL licensing model

The BYOL (Bring Your Own License) licensing model is one that relies on you purchasing a software license key separately from our openvpn.net website and activating it on your Access Server installations. This locks the key to the current hardware/software configuration on the instance in question. Making changes to the instance – like imaging and relaunching it, or changing the instance type, or enabling autoscaling – will result in the license key becoming invalid, requiring you to contact us for support. See our troubleshooting page regarding BYOL type license keys for more information.

It’s also important to note here that when you launch the BYOL type instance with the instructions given below, then you do not actually need to provide a license key. If you do not provide a license key, the Access Server allows for two simultaneous VPN connections. To unlock more connections, you need to purchase and activate a license key on your Access Server installation.

Launching the VM

To get started, log on to the Microsoft Azure portal by going to https://portal.azure.com. After you are logged on, click the plus sign (+) on the left navbar, to Create a resource. Type “OpenVPN Access Server” in the search box as indicated below:

From the OpenVPN Access Server listing page, click the Create button to start the instance creation process:

The following dialogue should appear on your screen:

Subscription: Select a subscription you would like to use for your VPN server. This is for your Microsoft Azure subscription, different than a license for OpenVPN Access Server. For further assistance with this, please contact Microsoft directly for help.

Resource Group: Click on Create new if you are starting a VPN network from scratch. If you already have a local network on Azure you would like to interface with, select Use existing so you can position the VPN server accordingly on the network.

Virtual machine name: Enter the name of your VPN server for identification purposes. This is only used on the Azure portal.

Region: Select the appropriate region for your VPN server.

Availability options: Choose from the options provided by Azure for the availability of your server.

Image: Leave this selected as OpenVPN Access Server [latest version #].

Size: Leave as default or change the size as necessary.

Authentication type: We recommend that you use SSH public key authentication. You can use a public key generated from a tool like ssh-keygen or PuTTYgen. If you do not have this information already generated, you may select Password to create a secure username and password for connecting to your instance. This information only applies to SSH connectivity to your instance and will have no impact on the VPN server itself.

Username: Enter the username you would like to use to connect to your VM. This username will be used for SSH access to your VM only and will be separate from your VPN server admin credentials.

After all of the requested information is filled out, click Next: Disks > to continue with the resource manager wizard. Select the disk type of your preference. Microsoft provides a comparison of the disks if you click on the link Learn more.

Click on Next: Networking > to define network connectivity.

Most of the default options are already optimal and the following is helpful to know:

Virtual network: This points to a virtual network (Vnet) containing the computing resources you would like your VPN clients to have access to.

Subnet: This should be pointed to a subnet within the previously selected Vnet. Please note that while you are free to assign a different subnet to the VPN server, the VPN clients will not be able to assume addresses within this subnet due to Layer 3 routing. For this reason, it is recommended that you use the same subnet as the rest of the computing resources you intend to connect to with your VPN server.

Public IP: You need to use a Static IP address. To do this, you may need to click on Create new and choose from the options that pop up on the right. Enter a Name for the IP, the SKU, and select Static under Assignment. This step is especially important if you are planning to get a commercial SSL certificate that would be valid for your VPN administration portal. Selecting a static IP address makes it easier for you to point your DNS records to the correct IP address if you are going to be using a custom domain name or FQDN for your VPN server.

 

NIC network security group: We have already preconfigured the rules for this so there is no need to create additional rules here.

Configure network security group: When you click on Create new, you’ll see the preconfigured settings we’ve defined. Review these and click OK.

Click Next: Management > to review monitoring and management options. You may leave all of these as the default selections. Click on Next: Advanced > if you’d like to review additional options and click on Next: Tags >  if you need to assign name and value pairs for categorizing resources. Finally, click on Review + create.

Wait while a final validation runs. Then, you can review all options for your new instance and click on Create. You have now initiated your instance on your Azure cloud and deployment begins.


Please note that Azure subscription billing is separate from an OpenVPN Access Server license. If you require a software license, please refer to VPN Pricing. You do not need a license to get started. Without a license key, your VPN server can run with two-concurrent connections for testing purposes.

Connecting to your instance

The OpenVPN Access Server appliance is a Linux-based appliance that is managed via an SSH connection. You can connect to the instance by using an SSH client and the credentials you previously used to initiate the instance. For more information on how to connect to your instance using SSH, refer to Microsoft Azure documentation.

When your deployment is complete, you can click on Go to resource to open your virtual machine dashboard. You’ll find your IP address for your VPN server under Public IP address.

Running the OpenVPN Access Server Setup Wizard

Note: You will need to complete this setup wizard before your VPN server will be operational.

The OpenVPN Access Server Setup Wizard runs automatically upon your initial login to the appliance. Read through the EULA, and enter yes to agree:

Will this be the primary Access Server node? Hit Enter to accept the default setting if this is your initial Access Server node. Otherwise, if you are setting up a failover node, change this to no.
Please specify the network interface and IP address to be used by the Admin Web UI This will be the interface where OpenVPN Access Server will listen to Admin Web UI requests. Make sure you have access to the interface listed, otherwise you will be unable to login to your server. If you are uncertain, select option 1 for all interfaces. Note: If your network did not assign your appliance a DHCP lease, or if you are planning to use a static IP for your server, make sure you did so when setting up your instance as detailed above. You can change this option anytime using the Admin Web UI.
Please specify the port number for the Admin Web UI This is the port you will use to access the web-based administration area. It typically works well to leave this as the default port unless you need customization.
Please specify the TCP port number for the OpenVPN Daemon This is the port that the Access Server will listen on for incoming OpenVPN client TCP connections. The web interface also listens on this port. We recommend leaving this at the default port TCP 443, the standard HTTPS port.

This port will have to be forwarded to the Internet if your server is behind a NAT-based router.

Should client traffic be routed by default through the VPN? If you use the OpenVPN Access Server only to access resources on a private, Azure network, set this to no. If you wish to redirect the VPN client’s Internet-related traffic through your VPN server, set it to yes. This is especially useful if you want to secure data communications over an insecure link such as Public Wi-Fi.
Should client DNS traffic be routed by default through the VPN? If you would like your VPN clients to be able to resolve local domain names through using an on-site DNS server, select yes for this option. Also select yes if you will use a custom DNS server. Otherwise, select no.

If you selected yes for the previous option, all traffic will route over the VPN regardless of what you choose here.

Use local authentication via internal DB? Select yes to use local authentication. It is the simplest and best option as well as the default. With it, you will use the Admin Web UI to manage your user accounts for Access Server.

In this same Admin Web UI, you can always change the authentication method to PAM, LDAP, or RADIUS at any time.

If you select no, Linux PAM authentication is used and you will need to add/change/delete users within the Linux operating system itself.

If you plan on using LDAP or RADIUS, choose yes and configure these settings after you login to the Admin Web UI.

Should private subnets be accessible to clients by default? The Access Server can try to detect which private network it is connected to and make it available to VPN clients by default. In the Admin Web UI, you can change this and add or remove private network subnets from the VPN Settings page. This option is called “Should VPN clients have access to private subnets?” and you can specify any that all VPN clients should be able to access.
Do you wish to login to the Admin UI as “openvpn”? This defines the initial username for the admin account to login to the Access Server Admin Web UI. It will also serve as your lockout administrator username should you ever lock yourself out of your own server. If you’d like to specify your own username, select no. Otherwise, accept yes as the default.

If you choose no, you will be prompted to enter a new username as well as type and confirm the password.

Please specify your OpenVPN-AS license key (or leave blank to specify later) If you are testing out the product, we recommend you leave this blank. The Access Server will allow two connections for free by default. A fixed license key can be activated at any time.

If you are an experienced user of Access Server, you can activate your fixed license key immediately on this Access Server without running any prior tests. Enter the activation key here.

After you complete the setup wizard, the initial configuration will run. Upon completion, you will be given a URL containing your internal Vnet IP address. This will not work unless you are accessing this URL from another instance inside the same Vnet. To access the administration UI from the Internet, replace the internal IP address with your instance’s public IP address.

As a last step, make sure and define a password for your “openvpn” user before attempting to login to the Admin Web UI. Please note that if you specified a custom Admin UI username instead of the default ‘openvpn’ user account, you should set the password for that username instead.

Enter sudo passwd openvpn and press Enter. Set and confirm the password.

Login to Admin Web UI

You can access your Admin Web UI from the web browser. The URL will be dependent on your virtual machine IP address or defined hostname (example: https://123.45.67.89:943/admin/).

  • Upon first login, you will see an SSL certificate warning. This is normal. Please override. If you’d like, here are more details about SSL certificates.
  • Login with the username ‘openvpn’, or the username specified during initial setup if you took this step.
  • Read and agree to the EULA.
  • You can now start using your OpenVPN Access Server by adding users in the User Permission table and other settings

Setting up a Hostname

Since Microsoft Azure automatically assigns an internal IP address for your instance, you will need to login to the Admin Web UI if you wish to configure the Hostname. We strongly recommend using a hostname, rather than an IP address if possible, since your clients will depend on this setting to know how to connect. Updating a DNS record is easier than reinstalling all client profiles to update the IP address if that changes for any reason. Also, SSL certificates require a proper FQDN hostname in order to function properly.

Note: If you leave the Hostname or IP Address setting as the default, NONE of your clients will be able to connect to your VPN server since by default it is set to a non-routable (private) IP address.

Here are some helpful tips for setting this up with a custom domain or FQDN:

  • Register a domain name with a registrar.
  • Add a DNS A record that points to your domain with the value of your Access Server public IP address. For example: vpn.example.com points to 123.45.67.89.
  • Within the Access Server Admin Web UI, navigate to Configuration > Network Settings.
  • Enter the new hostname (vpn.example.com) in the Hostname or IP Address field.
  • Click Save Settings and Update Running Server.
  • When you type in https://vpn.example.com/ in your web browser, you will reach your Access Server.
  • If the public IP address of your Access Server ever changes, from your registrar’s DNS management, change the DNS A record to point to the new public IP address.
  • Clients will automatically connect to the updated IP address.

Here’s how to set this up with an Azure-supplied DNS hostname, if you do not have a custom domain or FQDN:

  • Select your OpenVPN Access Server virtual machine in your Microsoft Azure portal.
  • Under DNS name, click Configure.
  • On the Configuration page, under Assignment, choose Static.
  • Adjust your idle timeout if desired.
  • Enter the desired DNS name under DNS name label (optional). (If the name is invalid or already taken, you will not be able to click Save.)
  • Click Save and your virtual machine may reboot to apply the changes.
  • The public IP address is saved with the new DNS record.
  • Enter this Azure-supplied DNS hostname within the Access Server Admin Web UI by navigating to Configuration > Network Settings.
  • Enter the new hostname in the Hostname or IP Address field.
  • Click Save Settings and Update Running Server.
  • You can now reach your Access Server with that hostname.

Changing Default Timezone

The default timezone is set to UTC. If you reside at another timezone and you would like to set the timezone to reflect local time, run the following command (you will be asked what timezone you would like to set):

sudo dpkg-reconfigure tzdata

The system will show the new local time after you configure this setting.

Install NTP client for automatic time synchronization

We recommend this step for all situations, but especially for those that want to use Google Authenticator. Run this command to install the package:

sudo apt-get install ntp

Enabling IP Forwarding (required for use with routing)

In order for your instance to function properly if you use “Routing” as your mode of operation inside Access Server instead of NAT, IP forwarding will need to be turned on:

  1. From the Azure portal, enter network interfaces in the search box at the top.
  2. Select Network interfaces from the search results.
  3. Select the network interface of your Access Server virtual machine.
  4. Select IP configurations under the Settings section.
  5. Click on the toggle to Enable IP forwarding.
  6. Click Save.
  7. The network interface change saves.

Take note of your Private IP address noted here as you will need it for creating and assigning a routing table, explained below.

Creating and assigning a routing table (required for use with routing)

When you use “Routing” for your Access Server instead of NAT, it is necessary to create a routing table on Azure so that traffic to your VPN subnet is directed back to your VPN instance:

    1. Click on Create a resource from your Azure portal.
    2. Enter route table in the search field.
    3. Select the Route table from Microsoft when prompted.
    4. Click on Create.
    5. Enter a name for the routing table (choose any you would like).
    6. Under Resource group select the group with your VPN server:

 

    1. Click Create.
    2. From your Portal, click on Virtual networks.
    3. Click on the Vnet for your VPN server.
    4. Under Settings, click on Subnets.
    5. Click on the subnet used by your computing resources (may be called default).
    6. Click on the Route table drop-down and select your newly created routing table from the list:

 

    1. Click Save.
    2. Repeat this step for any additional subnets you may have under the same Vnet that the VPN server needs to communicate with.
    3. Now that the routing table is set, you’ll need to add a new route by first clicking on All resources and selecting your new routing table.
    4. Under Settings of your route table, click on Routes:

 

    • Click Add.
    • On the Add route page, enter a name, then the following:
      • Address Prefix: 172.27.224.0/20
      • Next hop type: Virtual appliance
      • Next hop address:
    • Click OK when done.
    • Click Add again to add a second record:
      • Address Prefix: 172.27.240.0/20
      • Next hop type: Virtual appliance
      • Next hop address:
    • Click OK when done.

You have completed the routing table configuration.

NOTE: You will need to edit your routing table configuration if you decide to change your VPN subnets in the future using the Admin Web UI.

Updating Operating System Software (recommended)

From the time we have generated the appliance to the time you have downloaded and are using it, many operating system updates might have become available. To make sure your appliance OS is up to date, execute the following commands:

sudo apt-get update

sudo apt-get upgrade

Further security recommendations

We have additional security recommendations we suggest you implement, for all OpenVPN Access Server installations.

Share