VPN

The VPN view presents the scaffolds associated with configuring the IPsec and OpenVPN services integrated into the rXg.

OpenVPN Servers

Entries in the OpenVPN Servers scaffold define configuration profiles for the rXg integrated SSL(TLS) VPN.

OpenVPN is an industry standard, open-source software application that the rXg leverages to implement virtual private network (VPN) techniques to create secure point-to-point connections in a routed configuration. It uses a custom security protocol that utilizes SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls. The OpenVPN functionality allows peers to authenticate each other using certificates and/or username/password. When used in a multiclient-server configuration, it allows the server to release an authentication certificate for every client, using signatures and certificate authority. It uses the OpenSSL encryption library extensively, as well as the TLS protocol, and contains many security and control features.
https://community.openvpn.net/openvpn/wiki

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

Each server represents a virtual network interface on a subnet specified by a related Network Address. A separate VPN instance exists for each configured server. A Network Address that is assigned to an OpenVPN interface cannot be configured on a traditional ethernet Interface or VLAN. All servers/networks operate in OpenVPN's TUN (tunnel) mode, which transports only layer 3 IP packets.

If the default gateway field is checked the client will use the VPN interface's IP as its default gateway and DNS server, and route everything over the VPN. An OpenVPN server's Network Address behaves similarly to any other routed subnet behind an ethernet interface or VLAN, in that IP clients behind it are subject to Policy enforcement. For example, creating an IP Group and Landing Portal Policy without a subnet filter for the VPN network would permit the client to access all networks. Conversley, a portal-enabled Policy could be deployed for the VPN client's network. If gateway redirect is not enabled on the server, then it will push routes for all other local networks to a VPN client, which allows it to route through the normal Internet whilst also having knowledge of networks behind the VPN. Note that like any other traditionally-attached subnet, or when the VPN is the default gateway, the routes pushed to the client do not necessarilly ensure firewall access to all networks. In general, an OpenVPN client can also manipulate its routing table independently on a per-client basis.

Authentication from a client may be multi or single-factor via certificates ( require certificate ) and/or username/password ( require login ). If certificates are required, clients must have a unique certificate installed to authenticate. The certificate must be signed by the same CA as the OpenVPN Server's certificate. If multiple devices need to use the same client certificate, the allow duplicate certificates field must be checked, otherwise only one connection per certificate Common Name is permitted. Requiring a unique certificate per client is more secure, but requires each client to have a unique configuration.

If client-to-client behavior is enabled, then clients on the same virtual network can route to each other as if the firewall was disabled. This does not include L2 traffic. Otherwise, if this behavior is disabled, all traffic is forced to route through the rXg and is thus filtered according to Policy enforcement. This should only be enabled when_everyone_ connecting to the same OpenVPN Server should be allowed to communicate.

Configuring the Admin Roles or Account Groups fields permit corresponding Admins and/or Accounts access to the VPN via login. If client certificates are required, the login is only half the authentication process. If client login is not required then these selections are ignored. It is recommended that operators (Admins) and end-users (Accounts) connect to separate OpenVPN Servers. In the case where an OpenVPN Server has Admins and Accounts allowed, an Admin having the same login as an Account always takes precedence for login and instrumentation purposes.

The port and protocol fields define how a client initially connects to the VPN server. A TCP and UDP server may be configured to run on the same port. There are advantages and disadvantages to either protocol (OpenVPN tcp vs udp).

An OpenVPN Server must have a Certificate configured. This identifies the server's certificate and private key in additon to the Certificate Authority (CA) that establishes the PKI used to trust clients. The selected Certificate must be associated with and created from a local Certificate Authority. The certificate must be marked for server usage, meaning it was signed with an explicit key usage and extended key usage based on RFC3280 TLS rules. This can be done when creating the Certificate Signing Request (CSR). This is an important security precaution to protect against a man-in-the-middle attack where an authorized client attempts to connect to another client by impersonating the server.

The cipher and digest options affect the strength of the underlying encryption, where a longer key length increases security and reduces throughput performance. Data compression is enabled by default and is very efficient when LZ4 is employed, which reduces the bandwidth requirements of the VPN at the expense of additional overhead on the client and server.

The TLS-auth option adds an additional layer of HMAC authentication on top of TLS to mitigate DoS and other attacks againist the TLS layer. This is accomplished by including a unique key that resides on top of TLS. The key is generated behind the scenes when an OpenVPN Server is created, and included in the client config output. If a client is configured manually and this is enabled, then the operator must obtain the key from the record via scaffold show action.

By default, access to rXg services are either limited to the LAN or disabled entirely. In certain cases, the operator may desire to permit accessibility to services over the WAN and/or LAN. To enable access to rXg services over the WAN, the operator should specify one or more WAN targets containing the list of allowed hosts and then set the visibility appropriately. If no WAN target is specified and WAN visibility is enabled, any node on the WAN may connect to the service. It is highly recommended that this wide-open configuration be avoided to ensure system security. If LAN visibility is included then all authenticated nodes on the LAN may access this service.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Clicking the Download Config link will generate an OpenVPN config (.ovpn) file containing the necessary client connection parameters based on the server's configuration, including the Server certificate. Currently, if a client certificate is required, it must be generated manually via the local CA and installed in the client along with the config file.

IPsec VPN

IPsec is an industry standard mechanism that enables secure communication between two nodes or networks that are connected by a potentially insecure IP transit. The rXg supports bidirectional site-to-site IPsec VPNs between rXgs and between rXgs and other kinds of routers. In addition, the rXg may be configured to be a concatenator for host-to-site VPNs originating from nearly any operating system.

Site-to-site VPNs are typically used to enable secure bidirectional communication between two private IP blocks that are behind different routers that are located in geospatially distinct locations. For example, if a WISP has three distinct fixed wireless broadband coverage areas, all three could be linked together via site-to-site VPNs. This could be used as part of a revenue generation strategy such as allowing business customers to access their systems from home for an additional fee.

Site-to-site VPNs are very useful in geospatially diverse deployments that are connected via a central cluster controller. Establishing site-to-site VPNs between the rXgs and the cluster controller enables the operator to easily access all nodes at any part of the network. It is important to keep in mind that the private LAN addresses blocks behind the various rXgs be kept distinct as having the same private LAN block behind two rXgs would cause routing confusion.

Host-to-site VPNs are often used by operators for remote administration. An operator that is on the WAN side of a rXg may use host-to-site IPsec VPNs to directly access machines that are connected to a private address range. In a typical deployment, LAN equipment is assigned IP addresses from private ranges that cannot be reached from the WAN. An operator who is on the WAN side on the rXg (e.g., away on business) that wishes to have complete and direct access to the LAN equipment private address range would setup a host-to-site IPsec VPN using the rXg as the concatenator.

Host-to-site VPNs are also used as a revenue generation mechanism as they are typically sold as a premium service or as a value-added extra part of business class service. End-users originating traffic from the LAN side of the rXg may create a host-to-site VPN using the rXg as a concatenator to protect their traffic from sniffers present in the distribution network. Of course, end-users may also be sold host-to-site VPNs as a mechanism for remote connectivity to nodes addressed on a private LAN.

The rXg uses an industry standard reference implementation of the IPsec suite. Site-to-site VPNs are easily established between an rXg and nearly any other router that supports IPsec VPNs. In addition, site-to-site and site-to-host VPNs may be established between the rXg and almost any operating system released since 2005. Most operating systems have a built-in IPsec stack that is meant to be configured by a trained and certified specialist. However, VPN client software (e.g., Greenbow for Windows and IPsecuritas for Mac OS X) simplify the process to the extent that anybody with a working knowledge of basic TCP/IP can accomplish the task.

IPsec Tunnels

An entry in the IPsec tunnels scaffold is used to configure a site-to-site IPsec VPN.

The specification field selects the credential and encryption settings for this IPsec tunnel. It is critically important to ensure that the settings in the chosen IPsec specification matches those of the node at the other end of the site-to-site VPN created by this IPsec tunnel.

The Pre-Shared key and Certificates fields are used to configure the certificates or pre-shared key that will be used for authenticating IPsec tunnels that use this IPsec specification. The operator may choose to use one or more certificates or a pre-shared key but not both. If one or more certificates are chosen, then the node at the other end of the IPsec tunnel must have the matching private key. If a pre-shared key is chosen, then the node at the other end of the IPsec tunnel must have the exact same pre-shared key programmed.

The addresses and static routes checkboxes specify which LAN address blocks will be forwarded to the remote node of this site-to-site VPN.

The remote gateway field specifies the IP address of the node at the other end of this site-to-site IPsec VPN.

The remote networks field specifies the IP address blocks at the other end of this site-to-site VPN that will be routable once the VPN is established.

Conflicts between addresses or static routes and remote networks will cause severe routing problems. In situations where multiple site-to-site VPNs will be deployed, it is critically important to carefully plan the addressing across all current and potential future networks.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

IPsec Specifications

An entry in the IPsec specifications scaffold defines an IPsec policy that can be used for bidirectional site-to-site VPN tunnels as well as host-to-site VPN concatenation.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The IKE Version field allows the operator to select which IKE(Internet Key Exhange) version to use for the tunnel. IKEv1 and IKEv2 are supported.

The phase 1 and phase 2 groups are used to configure the encryption specifications for the initialization and operational phases of a IPsec tunnel. The chosen encryption , authentication , Diffie-Hellman group , exchange mode and proposal check must exactly match the settings on the node at the other end of the IPsec tunnel.

The encryption field specifies the algorithm that will be used for bulk encryption of the packet data that will transit the VPN connection. The DES option is included for reference only and should be avoided as it is trivially broken given contemporary computing power. The 3DES and AES options are the most compatible and generally accepted to be strong enough for most purposes. AES is preferable as it is the new government standard encryption protocol. Blowfish and CAST are less known protocols but widely believed to be as strong if not stronger than AES but not as well supported.

The authentication field specifies the algorithm that will be used for generating cryptographic hashes to authenticate data passing through the VPN connection. The MD5 option is included for reference only and should be avoided as researchers have discovered methods to break it. The SHA1 option is the most compatible option as it is broadly supported. If possible, the SHA256, SHA384 or SHA512 options as researchers have found a handful of minor vulnerabilities in SHA1 to date.

The Diffie-Hellman group and PFS group fields configure the strength of the encryption keys that will be used to protect the session keys used by the encryption algorithm. The stronger the key, the less likely that it will be broken. However, the stronger the key, the more CPU utilization and entropy it will consume and less compatible it will be. The Group 1 / 768 bit key length option should be avoided unless the other end of the VPN cannot support any other option. The Group 2 / 1024 bit key length is the absolute minimum key strength that should be used for a production environment. The longer key lengths are recommended if the other end of the VPN connection supports it.

The lifetime field configures the length of time in seconds of the security association. A shorter lifetime causes the system to rotate keys more often (potentially increasing security). As a result, shorter lifetimes will increase CPU utilization and entropy consumption.

The nonce field configures the size of the "number used once" for IPsec initialization. A longer nonce helps prevent replay attacks, but trades off CPU utilization and entropy consumption. A longer nonce is also less compatible with other IPsec implementations.

IPsec Server

Entries in the IPsec Server scaffold define configuration profiles for the rXg integrated IPsec server.

The active field enables an option set. Exactly one option set may be active at any time. Enabling a particular option set will automatically disable another existing active option set.

The anonymous specification field selects the credential and encryption settings for anonymous IPsec connections (i.e., where the client's originating IP address is unknown). Pre-shared-key authentication may not be used for anonymous connections. An anonymous IPsec client must authenticate using a certificate. The certificates to be used by the anonymous clients should be configured in the IPsec Specifications scaffold for the selected anonymous specification. It is critically important to ensure that the settings in the chosen anonymous specification match those of the IPsec client.

The certificate field specifies an alternate certificate to configure the IPsec server with.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Site-to-site IPsec VPN Configuration

Site-to-site IP-sec VPNs enable devices that are behind VPN concatenators to communicate with each other securely without any configuration changes to the end-user devices. In most cases, site-to-site IPsec VPNs are deployed with privately addressed end-user devices behind the VPN concatenators. Without a site-to-site IPsec VPN, the privately addressed devices would not be able to initiate communication with each other due to the one-way nature of network address translation. Consider the following network diagram:

In this example, we have two rXgs and we desire to create a site-to-site IPsec VPN to enable two way communication for devices that are on private addresses behind the rXgs. We will call the rXg on the left with WAN IP 66.67.68.2 east and the rXg on the right with WAN IP 55.45.35.2 west. The network dashboard of the_east_ rXg is shown below:

The rXg IPsec VPN feature is compatible with a broad spectrum of IPsec implementations. It is not necessary for a site-to-site VPN to be established between two rXgs. We have used two rXgs in this example so that we can best illustrate the appropriate configuration for either end of the site-to-site VPN. The network dashboard of the_west_ rXg is shown below:

Notice that both rXgs have a single private LAN block associated with them. The east rXg has 192.168.6.0/24 behind it and the west rXg has 192.168.7.0/24 behind it. When configuring IPsec VPNs, it is critically important to ensure that the networks behind the various endpoints of the IPsec VPN do not intersect. This is because IPsec depends on a valid L3 (routing layer) configuration in order to operate.

Establishing a site-to-site VPN is simply a matter of creating a single record in the IPsec Tunnel scaffold on both ends of the connection. The remote gateway field must be set to the IP address of the concatenator on the other end of the site-to-site VPN. The remote networks field must contain the CIDR of the block present on the other end of the site-to-site VPN.

Following our example, the IPsec tunnel record on east(which has WAN IP address 66.67.68.2, LAN address 192.168.6.1 / 24) must have the following settings:

remote gateway - 55.45.35.2
remote networks - 192.168.7.0/24 Below is a screenshot of the configuration that is present on east:

Similarly, west (which has WAN IP address 55.45.35.2, LAN address 192.168.7.1 / 24) must have the following settings in the IPsec tunnel record:

remote gateway - 66.68.67.2
remote networks - 192.168.6.0/24 Below is a screenshot on configuration that is present on west:

Notice that the IPsec Tunnel records depend on the existence of an IPsec Specification record in order to configure the encryption protocol and keys for the tunnel. In the configuration screenshots shown above, we seen that the specification is referenced as PSK for S2S. A screen shot of the configuration for_PSK for S2S_ that is present on both east and _west_is shown below:

Since we are configuring a site-to-site VPN, we are assuming that both ends of the connection are controlled by trusted parties. Thus we will use a pre-shared key to secure the connection. To accomplish this, we will create a new record in the IPsec Specifications scaffold on both the east and west rXgs. To get a site-to-site IPsec VPN up and running, the individual choices for the encryption protocol and credentials are not as important as the simple fact that they must be exactly the same on both machines. Using a strong pre-shared key is obviously a prerequisite to maintaining the confidentiality and integrity of the VPN.

Several templates are provided as examples for strong, medium and minimum security configurations. The minimum security configuration is the least secure against brute force attacks but is the most compatible. The template for the most secure setting will only function with KAME derived IPsec stacks such as the ones present in OpenBSD and FreeBSD. For more information on the precise meaning behind each of the settings, we recommend reading information that may acquired via a search on IPsec. When configuring a site-to-site VPN, keep in mind that even the slightest difference in a single setting will prevent the site-to-site IPsec VPN from initializing.

For your reference, the complete IPsec configuration for both_east_ and west is shown below:

Once we have this configuration in place on both east and_west_, devices on the 192.168.6.0 / 24 private network behind_east_ may directly contact devices on the 192.168.7.0 / 24 private network behind west and vice versa. Note that absolutely no configuration changes needs to be made on the end-user devices whatsoever. All of the encryption, decryption and routing between the private networks is handled by the IPsec VPN endpoints, which in this case are the east and west rXgs.

For example, let us assume there is a Windows XP laptop behind_east_. The XP machine will acquire a DHCP address in the 192.168.6.0 / 24 CIDR. Similarly, let us assume there is a Windows 2003 server behind west that is on the 192.168.7.0 / 24 CIDR. Given the site-to-site VPN configuration that we have created on the rXgs, the XP laptop will be able to directly communicate with the Win2k3 server without any configuration changes to the clients.

The screenshot below shows the desktop of the Windows XP laptop that is behind east. It has acquired address 198.168.6.100 / 24 from the east rXg. Notice that it can ping the private address 192.168.7.100 directly. The 192.168.7.100 address is configured on the Windows 2003 Server that is behind the _west_rXg.

No configuration changes were made to the Windows XP laptop whatsoever. The Windows XP laptop has no knowledge that the 192.168.7.100 is behind the west rXg. The 192.168.7.100 could be on the other side of the world and the XP laptop would not know any better. Furthermore, the XP laptop does not do any encryption or decryption of traffic. It merely sends traffic to the east rXg which does all of the work in encrypting and forwarding the traffic to the west router for delivery to 192.168.7.100.

The screenshot below shows the desktop of the Windows 2003 Server that is behind east. It has an address of 198.168.7.100 / 24 which is behind the west rXg. Notice that it can ping the private address 192.168.6.100 directly. As depicted in the previous screenshot, the 192.168.6.100 address belongs to the Windows XP laptop behind the east rXg.

The Windows 2003 Server has no knowledge about the site-to-site IPsec VPN. The Win2k3 server simply forwards packets to the_west_ rXg which does all of the work involved in the encryption and routing of packets to 192.168.6.100 via east.

The site-to-site IPsec VPN enables routing between private networks to occur over the public Internet that is otherwise not possible. Once established, any network application may be used. In the screenshots below, the Windows XP client on 192.168.6.100 behind east_is shown initiating and utilization a remote desktop connection to manage the Windows 2003 Server on 192.168.7.100 behind _west.

Site-to-site IPsec VPNs enable RGN operators to have secure remote access to all of their various networks. Any devices that is on a private network behind an rXg may be accessed as if it is a local device at the other end of the site-to-site VPN without any configuration changes to the devices themselves. The possibilities of what site-to-site IPsec VPNs may be used for is limitless. Many RGN operators deploy site-to-site VPNs for remote access as demonstrated above. Another frequent use of site-to-site VPNs is for monitoring. For example, site-to-site VPNs may be used to enable a central site to have a single network monitoring system (NMS) or element monitoring system (EMS) to monitor multiple remote networks.

Host-to-site IPsec VPN Configuration

Host-to-site VPNs are used with the rXg to securely route data between a specific end-user device and the rXg. Host-to-site VPNs may be initiated to the rXg from the WAN or the LAN. The process and technical steps of creating either a WAN to rXg or LAN to rXg host-to-site VPN are identical. However, the use case and business reasons for using the two topologies are radically different.

If the end-user device is on the WAN-side of the rXg, a host-to-site VPNs is usually deployed for the purpose of remote access to local privately addressed machines similar to a site-to-site VPN. However, a host-to-site VPN obviates the need to deploy and configure a VPN concatenator on the end-user network.

A WAN host-to-site VPN is the appropriate methodology to use with a mobile client used by a network administrator that requires access to privately addressed resources when the mobile client must connect to networks which the administrator does not control. For example, if the mobile client uses a wireless WAN connection (e.g., cellular 3G), it would be more difficult to install a VPN concatenator for site-to-site VPN than it would be to configure the device for host-to-site VPN. The use of host-to-site VPNs is ubiquitous in enterprise networks to the extent that even mobile phones operating systems such as Symbian, Windows Mobile and Apple iPhone OS are capable of initiating host-to-site VPNs.

Host-to-site VPNs originating from the LAN-side of the rXg are typically deployed as a facet of revenue generation for the operator. Popular media has helped educate most end-users to understand that there are many security issues present when computer networks are used. This effect may be exploited by RGN operators for the purpose of generating additional revenue by offering security related premium services.

For example, if the LAN distribution mechanism is wireless, a host-to-site IPsec VPN upgrade may be offered to end-users to provide confidentiality and integrity to the traffic over the wireless portion of the Internet link. Enabling the anonymous IPsec VPN capability and integrating the generation of a client certificate into the rXg captive portal allows operators to enjoy zero operator intervention provisioning of host-to-site VPNs.

Host-to-site IPsec VPNs typically use public key cryptography in order to authenticate the initiating hosts. Each initiating host must have a unique keypair in order to ensure the confidentiality and integrity of the IPsec VPN connection. In addition, the IPsec VPN concatenator must identify itself with a keypair to the initiating client. The rXg uses X.509 certificates and private keys for the purposes of authenticating both ends of a host-to-site IPsec VPN.

The rXg expects that the operator has stored certificates for each of the hosts that will be initiating a host-to-site IPsec VPN in the certificates scaffold on the certificates view. When a host-to-site IPsec VPN connection is initialized, the rXg expects that the initiating client will authenticate by using the matching private key to sign an authentication credential. Similarly, the rXg must be configured with a private key and certificate for authenticating the site. The initiating client is assumed to have a copy of the rXg certificate and the rXg will sign an authentication credential with the matching private key.

The certificates view of the rXg administrative console may also be used to create keypairs that may be used for authenticating host-to-site IPsec VPNs. To accomplish this, use the certificate authorities scaffold to create a new authority that can be used to sign certificate signing requests to fully populate certificates. For more information, please see the documentation on the certificates view.

In order to instantiate a host-to-site IPsec VPN, configuration changes must be executed on both the rXg and the end-user device. However, the same process is used to configure the end-user device and the rXg to enable a host-to-site IPsec VPN concatenator regardless of whether the VPN will be initiated from the WAN or LAN. Let us consider the east rXg that was discussed earlier. The configuration and network diagram for the east rXg is shown below:

The rXg must be configured to allow anonymous connections to enable the host-to-site IPsec VPN capability. To accomplish this, an entry in the IPsec servers scaffold must be created that specifies the site authentication certificate. The IPsec server record must be linked to a IPsec specification record that defines the encryption protocol as well as the client certificates that will be accepted for connection initiation.

The configuration steps of the end-user device needed to setup a host-to-site VPN follow the same pattern regardless of the operating system of the end-user device. At a bare minimum, the following items need to be configured in order for a host-to-site IPsec VPN to be established:

host certificate
host private key
IP address of VPN router
remote network CIDR
encryption protocol and associated parameters The precise steps that are needed depend on both the operating system as well as the VPN client software. Many popular operating systems have "bare metal" VPN clients built into them that are suited for operation by IT professionals. However, in almost all cases, user friendly VPN client GUIs are available from both free and commercial sources.

The IPsec capabilities of all recent versions of Microsoft Windows is configured using the Microsoft Management Console. Depending on the specific of Windows, the MMC snap-in will be called something like "IP Security Policy Management" or "Windows Firewall with Advanced Security." Search the web for Microsoft'sstep by step guide to deploying Windows firewall and IPsec policies and review pages 15-17 as well as 89-91 for specific instructions. For those who are less technically inclined, we have that the Greenbow VPN client greatly simplifies the creation of host-to-site IPsec VPNs on Windows.

The MacOS X operating system incorporates numerous open source components into its IPsec VPN stack. This makes the MacOS X IPsec VPN one of the most compatible of the commonly available commercial offerings. However, the command line configuration is needed to setup the IPsec stack for the vast majority of use cases. For this reason, we recommend that users download and install the IPsecuritas freeware GUI to configure host-to-site IPsec VPNs between MacOS X clients and rXgs.

Example OpenVPN Configuration

Create certificate
Create Networking
Configure OpenVPN in rXg Navigate to System-->Certificates. If there are no Certificate Authorities we will need to create one to self sign our OpenVPN certificate. Click Create New on the Certificate Authorities scaffold.

Name is arbitrary and be set to anything. Days by default will be 825. Common Name does not need to resolve for the purposes of using OpenVPN. Fill out the remaining fields with the appropriate information for your location. Click Create.

Next create a new Certificate.

For the certificate only the name needs to be entered at this step. Verify CA is set to Local CA. Click Create.

Next create a new Certificate Signing Request.

Verify that the Certificate field is set to the correct certificate. Sign mode should be set to Generate CSR and sign with linked local Certificate Authority. Common Name should match the Common Name in the Certificate Authority. Fill out the remaining fields with the appropriate information if applicable. Click Create.

Next we need to create the networking that will be used for devices connecting to the OpenVPN. Navigate to Network-->LAN, and create a new Network Address.

Enter a name. Make sure that Interface is set to -select- for each box. The IP field will be the addresses available to devices connecting via OpenVPN and should be entered in CIDR notaton. Autoincrement and Span should be left set to 1, do not check Create DHCP Pool. Click Create.

Navigate to Services-->VPN and create a new OpenVPN Server.

Enter a name, or use the default. Under Client Configuration Network should be set to the Network Addresses we created earlier. If you want traffic to route through the remote system check the Default gateway option. Require login is checked by default and this prevents access except for Admin Roles we have selected in this example. Server Options will be left at their default values for this example. WAN Targets can be selected to further restrict access if desired. Click Create.

Now the config can be downloaded from the rXg and imported into a VPN client of choice.