Using the OpenVPN Server Wizard for Remote Access

The OpenVPN wizard is a convenient way to setup a remote access VPN for mobile clients. It configures all of the necessary prerequisites for an OpenVPN Remote Access Server:

  • An authentication source (Local, RADIUS server, or LDAP server)
  • A Certificate Authority
  • A Server Certificate
  • An OpenVPN server instance.

By the end of the wizard a fully functioning sever will be configured and ready for users. An example setup will be used to aide in explaining the options available in the wizard.

Before Starting The Wizard

Before starting the wizard to configure the Remote Access Server, there are some details that must be planned.

Determine an IP addressing scheme

An IP subnet must be chosen for use by the OpenVPN clients themselves. This is the subnet filled in under Tunnel Network in the server configuration. Connected clients will receive an IP address within this subnet, and the server end of the connection also receives an IP address used by the client as its gateway for networks on the server side.

As always when choosing internal subnets for a single location, ideally the chosen subnet will be designed so that it can be CIDR summarized with other internal subnets. The example network depicted here uses 10.3.0.0/24 for LAN, and 10.3.201.0/24 for OpenVPN. These two networks can be summarized with 10.3.0.0/16, making routing easier to manage. CIDR summarization is discussed further in CIDR Summarization.

Example Network

Figure OpenVPN Example Remote Access Network shows the network configured in this example.

../_images/diagrams-openvpn-server.png

OpenVPN Example Remote Access Network

Choose Authentication Type

On the first screen of the OpenVPN Remote Access server wizard, choose a method for user authentication. The choices available for Authentication Backend Type are Local User Access, LDAP, and RADIUS.

If an existing authentication system is already in place, such as Active Directory, pick LDAP or RADIUS depending on how that system is configured. Local User Access may be selected to manage the users, passwords, and certificates on the pfSense firewall. When using Local User Access, per- user certificates may be used easily, managed completely in the pfSense GUI. This is much more secure, but depending on the number of users which will access the service, may be less convenient than using a central authentication system.

Note

For LDAP or RADIUS, per-user certificates cannot be used without generating them manually.

The Local User Access choice is the equivalent of choosing Remote Access (SSL/TLS + User Auth) mentioned earlier in this chapter. LDAP and RADIUS are equivalent to Remote Access (User Auth).

After selecting the authentication server type, click Next. If LDAP or RADIUS were chosen the server configuration for those choices will be the next step. If Local User Access was chosen, the LDAP and RADIUS wizard steps are skipped. For this example, Local User Access will be chosen, but the other options are discussed for completeness.

Choosing an LDAP Server

If an LDAP server is already defined on the pfSense firewall it may be chosen from the list. To use a different LDAP server instead choose Add new LDAP server. If there are no LDAP servers defined, this step is skipped.

Adding an LDAP Server

If no LDAP servers exist or Add new LDAP server is chosen a screen will be presented with the options needed to add a new server. Many of these options will depend on the specific LDAP directory configuration and structure. If there is any uncertainty about the settings, consult the LDAP server administrator, software vendor, or documentation.

Note

The details of LDAP servers are covered in Authentication Servers. Some detail is omitted here since the options are discussed in-depth elsewhere. For more information on the options listed in this section, refer there instead.

Name:Descriptive name for this LDAP server, for reference.
Hostname or IP address:
 The hostname or IP address of the LDAP server.
Port:The port on which the LDAP server may be contacted. The default port is 389 for standard TCP connections, and 636 for SSL.
Transport:This can be set to TCP - Standard for unencrypted connections, or SSL - Encrypted for secure connections. A standard connection may be sufficient at least for local servers or initial testing. If the server is remote or crosses any untrusted network links, SSL is a more secure choice. If SSL is to be used, the CA Certificate from the LDAP server must be imported into pfSense, and the Hostname or IP address above must match the value in the Common Name field of the server certificate.
Search Scope Level:
 Selects how deep to search in the LDAP directory, One Level or Entire Subtree. Most commonly, Entire Subtree is the correct choice.
Search Scope Base DN:
 The Distinguished Name upon which the search will be based. For example DC=example,DC=com
Authentication Containers:
 These values specify where in the directory that users are found. For example, it may be CN=Users;DC=example.
LDAP Bind User DN:
 The Distinguished Name for a user that can be used to bind to the LDAP server and perform authentication. If this is left blank, an anonymous bind will be performed, and the password setting below will be ignored.
LDAP Bind Password:
 The password to be used with the LDAP Bind User DN.
User Naming Attribute:
 Varies depending on the LDAP directory software and structure. Typically cn for OpenLDAP and Novell eDirectory, and samAccountName for Microsoft Active Directory.
Group Naming Attribute:
 Varies depending on the LDAP directory software and structure, but is most typically cn.
Member Naming Attribute:
 Varies depending on the LDAP directory software and structure. Typically member on OpenLDAP, memberOf on Microsoft Active Directory, and uniqueMember on Novell eDirectory.

Choosing a RADIUS Server

If there is an existing RADIUS server defined on the pfSense firewall, choose it from the list. To use a different RADIUS server, instead choose Add new RADIUS server. If no RADIUS servers are defined on pfSense, this step is skipped.

Adding a RADIUS Server

If no RADIUS servers exist, or Add new RADIUS server was selected, a screen is presented with the options needed to add a new server. If there is any uncertainty about the settings, consult the RADIUS server administrator, software vendor, or documentation.

Note

The details of RADIUS servers are covered in Authentication Servers. Some detail is omitted here since the options are discussed in-depth elsewhere. For more information on the options listed in this section, refer there instead.

Name:Descriptive name for this RADIUS server, for reference.
Hostname or IP address:
 The hostname or IP address of the RADIUS server.
Authentication Port:
 Port used by the RADIUS server for accepting Authentication requests, typically 1812.
Shared Secret:The Shared Secret is the password configured on the RADIUS server for accepting authentication requests from the IP address of the pfSense firewall.

Choosing a Certificate Authority

If there is an existing Certificate Authority defined on the pfSense firewall, it may be chosen from the list. To create a new Certificate Authority, choose Add new CA. If no Certificate Authorities are defined, this step is skipped.

Creating a Certificate Authority

This step presents all of the necessary fields to create a new certificate authority (CA). Every option on this page is required, and all fields must be filled out correctly to proceed. The CA is used to establish a trust base from which the server certificates can be generated and deemed “trustworthy” by clients. Because this CA is self-generated, it will only be trusted by clients who are also supplied with a copy of this CA certificate.

See also

For more information on creating and managing CAs, see Certificate Authority Management.

Descriptive Name:
 A name for reference to identify this certificate. This is the same as Common Name field for other Certificates. For this example CA, ExampleCoCA is used. Although using spaces in this field is allowed, we strongly discourage using spaces in a Common Name field because some clients have issues handling them properly.
Key Length:Size of the key which will be generated. The larger the key, the more security it offers but larger keys are generally slower to use. 2048 is a good choice.
Lifetime:The time in days that this CA will be valid. On a self-generated CA such as this, it is commonly set to 3650, which is approximately 10 years.
Country Code:Two-letter ISO country code (e.g. US, AU, CA). If the two-letter ISO country code is unknown, locate it on the ISO Online Browsing Platform site. Since the ExampleCo company is set in the United States, enter US for this example.
State or Province:
 Full unabbreviated State or Province name (e.g. Texas, Indiana, California). ExampleCo is located in Texas for this example.
City:City or other Locality name (e.g. Austin, Indianapolis, Toronto). ExampleCo’s headquarters is in Austin.
Organization:Organization name, often the Company or Group name. ExampleCo goes here for this example. Do not use any special characters in this field, not even punctuation such as a period or comma.
E-Mail:E-mail address for the Certificate contact. Often the e-mail of the person generating the certificate, such as vpnadmin@example.com.

Click Add new CA to finish the CA creation process

Choosing a Server Certificate

If there is an existing Certificate defined on the pfSense firewall, it may be chosen from the list. To create a new Certificate, choose Add new Certificate. If no Certificates are defined, this step is skipped.

Adding a Server Certificate

This screen creates a new server certificate which will be used to verify the identity of the server to the clients. The server certificate will be signed by the certificate authority chosen or created previously in the wizard. In most cases, as with this example, the same information from the previous step is used and it will be pre-filled on the form automatically.

Descriptive Name:
 This is the Common Name (CN) field for the server certificate and is also used to reference the certificate in pfSense. Using the hostname of the firewall is a common choice for a server certificate, such as vpn.example.com. Although using spaces in this field is allowed, we strongly discourage using spaces in a Common Name field because clients tend to have issues handling them properly.
Key Length:Size of the key which will be generated. The larger the key, the more security it offers but larger keys are generally slower to use. 2048 is a good choice.
Lifetime:Lifetime in days. This is commonly set to 3650 (Approximately 10 years).
Country Code:Two-letter ISO country code (e.g. US, AU, CA)
State or Province:
 Full State of Province name, not abbreviated (e.g. Texas, Indiana, Ontario).
City:City or other Locality name (e.g. Austin, Indianapolis, Toronto).
Organization:Organization name, often the Company or Group name. Do not use any special characters in this field, not even punctuation such as a period or comma.
E-Mail:E-mail address for the Certificate contact. Often the e-mail of the person generating the certificate. (e.g. vpnadmin@example.com)

Click Create New Certificate to store the settings and continue to the next step of the wizard.

Configuring OpenVPN Server Settings

The options on this step of the wizard configure each aspect of how the OpenVPN server itself will behave as well as options which are passed on to clients. The options presented here are the same as those discussed previously in OpenVPN Configuration Options, refer to that section for details. Because the options are covered in detail in that section, only the settings for this example will be mentioned.

General OpenVPN Server Information

These options control how the OpenVPN instance operates.

Interface:Since incoming connections will be from the WAN side, select WAN.
Protocol:The default of UDP is acceptable.
Local Port:This will be the first OpenVPN server instance so the default of 1194 is preferred. If there is an existing OpenVPN on that port, use a different port number. The wizard will suggest an unused port number.
Description:As this will be for remote user access, ExampleCo Mobile VPN Clients is a fitting description.

Cryptographic Settings

These options control how traffic in the tunnel is encrypted and authenticated.

TLS Authentication:
 TLS is highly desirable so check Enable authentication of TLS packets.
Generate TLS Key:
 There is no existing TLS key, so check Automatically generate a shared TLS authentication key.
TLS Shared Key:Since there is no existing TLS key, leave this blank.
DH Parameters Length:
 Select 2048, as it is good balance of speed and strength.
Encryption Algorithm:
 This can be left at the default value of AES-128-CBC, but any other option would also work well as long as the clients are set to match.
Auth Digest Algorithm:
 Leave at the default SHA1 (160-bit)
Hardware Crypto:
 The target device has no accelerator, so leave this set to No Hardware Crypto Acceleration

Tunnel Settings

These options control how traffic coming from the remote clients will be routed.

Tunnel Network:As in the diagram at the start of this example, the subnet 10.3.201.0/24 has been chosen for the VPN clients.
Redirect Gateway:
 For ExampleCo’s setup, The VPN will only carry traffic which is destined for the subnets at the main office so this box is left unchecked.
Local Network:This is the main office subnet, which in this example is 10.3.0.0/24.
Concurrent Connections:
 ExampleCo does not want to limit the number of clients which can connect at the same time, so this is left blank.
Compression:To improve throughput of traffic on the VPN tunnel at the expense of some CPU power, this is set to Enabled with Adaptive Compression.
Type-of-Service:
 This box is unchecked, as there is no traffic on this VPN which requires prioritization/QoS.
Inter-Client Communication:
 Because the clients on this VPN have no need to connect to other client machines, this box is unchecked.
Duplicate Connections:
 Because unique certificates exist for every client, this is unchecked.

Client Settings

These options control specific settings given to the clients when a connection is established.

Dynamic IP:The clients will connect from all over the country and unknown mobile networks and their IP addresses are likely to change without notice so this option is checked.
Address Pool:The clients will be assigned addresses from the tunnel network above, so this is checked.
Topology:The method used to assign IP addresses to clients. The default of Subnet is the best choice.
DNS Default Domain:
 Enter the domain for ExampleCo here, example.com.
DNS Servers:Any internal DNS server could be used here. ExampleCo has a Windows Active Directory Domain Controller which is configured to act as a DNS server, 10.3.0.5.
NTP Servers:The server above, 10.3.0.5, is also used to synchronize client PC clocks.
NetBIOS Options:
 Clients will need access to Windows shares behind the VPN, so check Enable NetBIOS over TCP/IP.
NetBIOS Node Type:
 Because DNS is used primarily, select h-node.
NetBIOS Scope ID:
 This will be left blank, since the NetBIOS scope is not limited.
WINS Servers:WINS has been deprecated, so this is left blank.
Advanced:At this time no additional tweaks are needed, so this is left blank.

Firewall Rule Configuration

As with other parts of the firewall, by default all traffic is blocked from connecting to VPNs or passing over VPN tunnels. This step of the wizard adds firewall rules automatically to allow traffic to connect to the VPN and also so connected clients can pass traffic over the VPN.

Traffic from clients to server

Check this box to add a firewall rule on the chosen interface for the tunnel (e.g. WAN) which lets clients connect. It allows all clients from any source address to connect by default. To allow connections from a limited set of IP addresses or subnets, either make a custom rule or check this box and alter the rule it creates. Since in this example clients are connecting from all over the country, the rule created by this checkbox is ideal, so the box is checked.

Traffic from clients through VPN tunnel

This setting allows all traffic to cross the OpenVPN tunnel, which is desirable for this example, so this box is checked.

Finishing the Wizard

Click Finish and the wizard is now complete; The tunnel is fully configured and ready for client connections. From here the next steps are to add users and configure client devices. If adjustments to the automatically generated firewall rules are required, make them now.