OpenVPN Site-to-Site Configuration Example with SSL/TLS and DCO

A site-to-site server using OpenVPN and Data Channel Offload (DCO) in Peer-to-Peer SSL/TLS mode can connect one remote site and can work with either static or dynamic routing. OpenVPN DCO allows for huge performance gains when processing encrypted OpenVPN data by reducing the amount of context switching that happens for each packet.

Note

DCO is available exclusively in pfSense® Plus software.

Warnings and Limitations

Note

Some OpenVPN features and use cases are not compatible with DCO. See Limitations for a list of known DCO limitations.

  • This configuration does not require assigning the OpenVPN instance on either side as an interface in pfSense® Plus software. While assigning the interface may work, this recipe assumes the interface is not assigned on the server or client.

  • When DCO is enabled on pfSense® Plus software, OpenVPN handles the routing in a much different manner at the operating system level. DCO is not compatible with internal routing in OpenVPN (iroute) which limits a server to one client. However, it is compatible with routing traffic on the interface using the operating system routing table, which allows OpenVPN with DCO to utilize dynamic routing protocols such as BGP or OSPF to exchange routes between VPN peers.

  • Static routes must be configured through OpenVPN itself and not by using gateways and routing in pfSense® Plus software.

  • Each server can only have one client connection, however, separate servers can be created for each remote client by changing the port number and tunnel network to unique values for each client/server pair.

  • OpenVPN DCO is not compatible with a /30 or smaller tunnel network. There are problems with the code for this mode in OpenVPN which can lead to failed connections and instability. That style of connection is being phased out of OpenVPN itself, so the best practice is to avoid that type of configuration.

Example Configuration Overview

When configuring a site-to-site OpenVPN connection using SSL/TLS one node will be the server and the other will be a client.

Tip

Usually a primary site or data center will be the server and a smaller or remote site will act as a client. However, if a remote site has a static IP address and more bandwidth than the primary site that may be a more desirable location for the server.

This style of VPN requires a dedicated subnet for the OpenVPN interconnection between networks in addition to the subnets on both ends. This can be any valid IPv4 subnet so long as it is larger than a /30 (e.g. /29 or /24) and it does not overlap another subnet currently in use on any of the connected networks.

OpenVPN allocates IP addresses for this type of configuration the same way it does for remote access clients. Using a Topology style of subnet, the client obtains an IP address in a common subnet with the server.

Summary of Requirements

This style of VPN requires several items, all of which are covered in this recipe:

On the server:

  • A certificate structure including a certificate authority, server certificate, and a client certificate

  • An OpenVPN server instance

  • An IPv4 subnet for the OpenVPN tunnel network, larger than a /30, such as 10.18.104.0/29.

  • Firewall rules on the WAN to allow a connection from the client node

On the client:

  • Imported CA and client certificate

  • OpenVPN client instance

On both nodes:

  • pfSense® Plus software version 22.05 or later for DCO support

    The best practice is to use the current supported version, pfSense® Plus software version 24.11-RELEASE

  • Firewall rules to pass traffic inside the tunnel

  • An appropriate routing configuration (static or dynamic) – specifics vary by method, see Configuring Routing for SSL/TLS with DCO.

Example Configuration Settings

OpenVPN Endpoint Settings - Site A - Server

Site A - Server

Name

Austin

CA Name

S2SCA

Cert CN

serverA

WAN Address

198.51.100.18

LAN Subnet

10.18.0.0/24

LAN Address

10.18.0.1

Tunnel Net

10.18.104.0/29

OpenVPN Endpoint Settings - Site B - Client

Site B - Client

Name

Colorado

Cert CN

clientB

WAN Address

203.0.113.19

LAN Subnet

10.19.0.0/24

LAN Address

10.19.0.1

Configuring SSL/TLS with DCO Server Instance

The server configuration consists of a certificate structure, OpenVPN server instance, firewall rules, and a routing configuration.

Note

Parts of this configuration will vary depending on the routing style the tunnel will use. See Configuring Routing for SSL/TLS with DCO for details.

Create Certificate Structure

The first step is to create a certificate structure for this VPN.

This example uses the names listed in Example Configuration Settings – The CA is named S2SCA, the server certificate CN is serverA, and the client certificate CN is clientB.

Create a Certificate Authority

Create a CA unique to this VPN:

  • Navigate to System > Certificates, Authorities tab

  • Click fa-plus Add to create a new a CA

  • Enter the settings as follows:

    Descriptive Name:

    S2SCA

    Method:

    Create an internal Certificate Authority

    Randomize Serial:

    Checked

    Key Type:

    RSA, 2048 (or higher)

    Digest Algorithm:

    sha256 (or higher)

    Lifetime (days):

    3650

    Common Name:

    S2SCA

    Subject Component Fields:

    The remaining fields are optional, but can be set to reflect the location of the CA.

  • Click Save

Create a Server Certificate

Create a server certificate signed by the VPN CA:

  • Navigate to System > Certificates, Certificates tab

  • Click fa-plus Add/Sign to create a new certificate

  • Enter the settings as follows:

    Method:

    Create an internal Certificate

    Descriptive Name:

    serverA

    Certificate Authority:

    S2SCA

    Key Type:

    RSA, 2048 (or higher)

    Digest Algorithm:

    sha256 (or higher)

    Lifetime (days):

    398

    Note

    Some operating systems and software limit server certificates to a maximum lifetime of 398 days for security reasons. Clients on these platforms may reject a server certificate with a longer lifetime.

    Common Name:

    serverA

    Subject Component Fields:

    The fields contain data copied from the CA and are optional, but can be set to reflect the location of the server.

    Certificate Type:

    Server Certificate

    Warning

    This setting is critical, do not forget to set this value!

    Alternative Names:

    Optional extra entries, if needed, which specify alternate ways to identify the server. This can be left blank if the certificate will only be used by OpenVPN. Otherwise, add fields with additional information such as alternate hostnames, static IP addresses, and so on which are relevant to this server.

  • Click Save

Create User Certificate

Create a user certificate for the remote site signed by the VPN CA.

  • Navigate to System > Certificates, Certificates tab

  • Click fa-plus Add/Sign to create a new certificate

  • Enter the settings as follows:

    Method:

    Create an internal Certificate

    Descriptive Name:

    clientB

    Certificate Authority:

    S2SCA

    Key Type:

    RSA, 2048 (or higher)

    Digest Algorithm:

    sha256 (or higher)

    Lifetime (days):

    3650

    Common Name:

    clientB

    Subject Component Fields:

    The fields contain data copied from the CA and are optional, but can be set to reflect the location of the client.

    Certificate Type:

    User Certificate

    Warning

    This setting is critical, do not forget to set this value!

    Alternative Names:

    Optional extra entries which specify alternate ways to identify the client. These can be left blank if the certificate will only be used by OpenVPN. Otherwise, add fields with additional information such as alternate hostnames, static IP addresses, and so on which are relevant to this client.

  • Click Save

Export Certificates

The next task is to export the certificates and keys which the client requires when connecting to the OpenVPN server.

  • Navigate to System > Certificates, Authorities tab

  • Click fa-certificate on the row for the CA to export its certificate

  • Navigate to System > Certificates, Certificates tab

  • Click fa-certificate on the row for the client certificate to export the certificate

  • Click fa-key on the row for the client certificate to export the private key for the client certificate

Warning

Do not export the CA key, server certificate, or server key! The client does not need these files and copying them unnecessarily significantly weakens the security of the VPN.

Configure the OpenVPN Server Instance

  • Navigate to VPN > OpenVPN, Servers tab

  • Click fa-plus Add to create a new server

  • Fill in the fields as described below, with everything else left at defaults.

    Use values appropriate for this network, or the defaults if unsure.

    See also

    Description:

    Enter text to describe the connection, e.g. Site-to-Site VPN.

    Server Mode:

    Peer to Peer (SSL/TLS)

    Warning

    DCO requires SSL/TLS, shared key is not compatible.

    DCO (Plus Only):

    Checked

    Protocol:

    UDP on IPv4 only

    Note

    DCO is not compatible with TCP.

    Interface:

    WAN

    Local Port:

    1194

    TLS Configuration:

    Check the Use a TLS Key box to enable TLS authentication which provides protection for the tunnel control channel.

    Leave Automatically generate a TLS Key checked so the firewall will generate a new key automatically the first time this entry is saved.

    Peer Certificate Authority:

    Select the CA created at the beginning of this process (S2SCA)

    Peer Certificate Revocation List:

    Select a CRL for the CA, if one exists.

    Server Certificate:

    Select the server certificate created at the beginning of this process (serverA)

    Data Encryption Algorithms:

    DCO is limited to the AES-256-GCM, AES-128-GCM, and ChaCha20-Poly1305 encryption algorithms. Any of these options will work, provided the same algorithms are selected on the server and client side.

    The best algorithm for an environment depends on the hardware and what it may be capable of accelerating. See Cryptographic & Thermal Hardware for details.

    IPv4 Tunnel Network:

    Enter the chosen tunnel network, 10.18.104.0/29

    Warning

    This cannot be set to a /30 or /31 subnet, it must be a larger subnet, such as a /29 or /24.

    IPv4 Local Network(s):

    If this setup uses static routing, enter the LAN subnet(s) for the server site: 10.18.0.0/24.

    This will push a route for these networks to the client.

    Tip

    If there are more networks on the server side that clients need to reach, such as networks reachable via static routes, other VPNs, and so on, add them as additional entries in the IPv4 Local Network box separated by a comma. For example, 10.18.0.0/24, 10.18.5.0/24.

    See also

    See Configuring Routing for SSL/TLS with DCO for details on alternative routing configurations.

    IPv4 Remote Network(s):

    If this setup uses static routing, enter the LAN subnet(s) for the client site: 10.19.0.0/24.

    This will direct the operating system to deliver traffic for these networks to this OpenVPN instance.

    Tip

    If there are more networks on the client side that the server side needs to reach, such as networks reachable via static routes, other VPNs, and so on, add them as additional entries in the IPv4 Remote Network box separated by a comma. For example, 10.18.0.0/24, 10.18.5.0/24.

    See also

    See Configuring Routing for SSL/TLS with DCO for details on alternative routing configurations.

    Other options can remain at their default values.

  • Click Save.

  • Click fa-pencil to edit the new server instance

  • Find the TLS Key box

  • Select all of the text inside

  • Copy the text to the clipboard

  • Save this to a file or paste it into a text editor such as Notepad temporarily

Firewall Rules

External Traffic (WAN)

Next, add a firewall rule for the WAN interface which allows access to the OpenVPN server.

  • Navigate to Firewall > Rules, WAN tab

  • Click fa-turn-up Add to create a new rule at the top of the list

  • Set the options as follows:

    Protocol:

    UDP

    Source:

    Any

    If the client has a static IP address, set it as the source on this rule instead, either directly or by using an alias.

    Destination:

    WAN Address

    Destination port:

    1194

    Description:

    OpenVPN Site-to-Site DCO VPN

  • Click Save

  • Click Apply Changes

Tunneled Traffic

Now add a rule to the OpenVPN tab to pass traffic over the VPN from the Client-side LAN to the Server-side LAN. This can be an “allow all” style rule or a set of stricter rules. This example allows all traffic using this rule:

  • Navigate to Firewall > Rules, OpenVPN tab

  • Click fa-turn-up Add to create a new rule at the top of the list

  • Set the options as follows:

    Protocol:

    Any

    Source:

    Any

    Tip

    For extra security, create an alias containing only the remote hosts or subnets which must initiate contact with hosts on the sever LAN, then use that alias as the source on this rule.

    Destination:

    Any

    Tip

    For extra security, create an alias containing only the local hosts or subnets on the server LAN which must accept connections from remote hosts across the VPN, then use that alias as the destination on this rule.

    Description:

    Allow all tunneled OpenVPN traffic from clientB

  • Click Save

  • Click Apply Changes

That completes the server setup, now move on to configure the client.

Configuring SSL/TLS with DCO Client Instance

The client configuration consists of an imported certificate structure, OpenVPN client instance, firewall rules, and a routing configuration.

Note

Parts of this configuration will vary depending on the routing style the tunnel will use. See Configuring Routing for SSL/TLS with DCO for details.

Import CA and Certificate

On the client, import the CA certificate along with the client certificate and key. This is the same CA and client certificate created earlier in this document.

Import these items at System > Certificates.

First import the CA:

  • Navigate to System > Certificates, Authorities tab

  • Click fa-plus Add to create a new certificate authority

  • Enter the settings as follows:

    Descriptive Name:

    S2SCA

    Method:

    Import an existing Certificate Authority

    Certificate Data:

    Open the CA certificate file in a text editor on the client PC, select all of the text, and copy it to the clipboard. Then paste it into this field.

  • Click Save

Next, import the client certificate:

  • Navigate to System > Certificates, Certificates tab

  • Click fa-plus Add to create a new certificate

  • Enter the settings as follows:

    Method:

    Import an existing Certificate

    Descriptive Name:

    clientB VPN Certificate

    Certificate Type:

    X.509 (PEM)

    Certificate Data:

    Open the client certificate file in a text editor on the client PC, select all of the text, and copy it to the clipboard. Then paste it into this field.

    Private Key Data:

    Open the client certificate private key in a text editor on the client PC, select all of the text, and copy it to the clipboard. Then paste it into this field.

  • Click Save

Configure the OpenVPN Client Instance

After importing the certificates, create the OpenVPN client:

  • Navigate to VPN > OpenVPN, Clients tab

  • Click fa-plus Add to create a new client

  • Fill in the fields as follows, with everything else left at defaults:

    See also

    See Client Configuration Options for details on each of these options.

    Description:

    Text to describe the connection (e.g. Site A VPN)

    Server Mode:

    Peer to Peer (SSL/TLS)

    DCO (Plus Only):

    Checked

    Protocol:

    UDP on IPv4 only

    Interface:

    WAN

    Server host or address:

    The public IP address or hostname of the OpenVPN server (198.51.100.18 in this example)

    Server Port:

    1194

    Use a TLS Key:

    Checked

    Automatically generate a TLS key:

    Unchecked

    TLS Key:

    Paste in the TLS key copied from the server instance

    Peer Certificate Authority:

    The CA imported at the beginning of this process

    Client Certificate:

    The client certificate imported at the beginning of this process

    Data Encryption Algorithms:

    Match the algorithm(s) selected in the server configuration

    IPv4 Tunnel Network:

    Leave blank

  • Click Save

Note

With SSL/TLS server/client configurations such as this example, the server automatically pushes address configuration, routes, and certain other options to the client. These options do not need to be present in the client configuration.

If the client side must reach additional networks, configure them in the server settings.

Firewall Rules

This next step is optional depending on whether or not hosts on the server network need to initiate contact with hosts on the client network. If the other site does not need to initiate contact with hosts behind this client, then no action is necessary.

Incoming connections from the server side to the client side require a firewall rule on the OpenVPN tab on the client firewall. An “allow all” style rule is OK in some cases, but a set of stricter rules is the best practice.

This example allows all traffic:

  • Navigate to Firewall > Rules, OpenVPN tab

  • Click fa-turn-up Add to create a new rule at the top of the list

  • Set the options as follows:

    Protocol:

    Any

    Source:

    Any

    Tip

    For extra security, create an alias containing only the remote hosts or subnets which must initiate contact with hosts on the client side, then use that alias as the source on this rule.

    Destination:

    Any

    Tip

    For extra security, create an alias containing only the local hosts or subnets on the client side which must accept connections from remote hosts across the VPN, then use that alias as the destination on this rule.

    Description:

    Allow all tunneled OpenVPN traffic from serverA

  • Click Save

  • Click Apply Changes

Configuring Routing for SSL/TLS with DCO

Since OpenVPN with DCO enabled cannot handle routing internally in OpenVPN, it requires extra steps to manage routes in certain cases.

Static Routing

The example in this recipe already configures static routing by using the IPv4 Local Network(s) and IPv4 Remote Network(s) configuration options.

This is the most basic method as it only requires configuring these two values on the server side, and the client side automatically picks up routes the server pushes.

Dynamic Routing with BGP

With DCO enabled the operating system can support routing over the OpenVPN interface using BGP. However, BGP requires a static neighbor address so there is one pre-requisite step before configuring BGP itself.

Create Client-Specific Override

On the server side, add a Client Specific Override for the client certificate to set a static IP address in the tunnel network. With this override entry present, the client instance will obtain the same static IP address each time the VPN connects. This is necessary so the BGP configuration on the server side can locate the client as a neighbor.

  • Navigate to VPN > OpenVPN, Client Specific Overrides tab

  • Click fa-plus to add a new override

  • Fill in the fields on this screen as follows:

    Description:

    A name for the override, such as the common name of the client (e.g. clientB).

    Common Name:

    Enter the CN of the client node. In this example, that is clientB.

    Server List:

    Select the server instance description.

    IPv4 Tunnel Network:

    A static address inside the server IPv4 Tunnel Network, e.g. 10.18.104.2/29.

    Warning

    The CIDR mask on this entry must match the CIDR mask on the server IPv4 Tunnel Network.

  • Click Save

Install and configure FRR and BGP

The FRR add-on package available for pfSense® Plus software provides BGP routing functionality. BGP must be configured on both the server and client nodes with appropriate settings for each.

BGP configurations can be quite complex and vary significantly for each environment. As such, examples are unlikely to match the needs of most environments. There is a BGP example in BGP Example Configuration which works for a basic configuration between two peers, as in this recipe.

When following the BGP Example Configuration note the following items of interest:

  • BGP peering happens on the OpenVPN tunnel interface and addresses. The neighbor address for each peer is the VPN interface IP address on the peer. The server side is always the first address in the subnet (e.g. 10.18.104.1), the client side will be the IP address set in the client-specific override (e.g. 10.18.104.2).

  • Ensure firewall rules on the OpenVPN tab pass BGP traffic on TCP port 179.

Dynamic Routing with OSPF

With DCO enabled the operating system can support routing over the OpenVPN interface using OSPF.

The FRR add-on package available for pfSense® Plus software provides OSPF routing functionality. OSPF must be configured on both the server and client nodes with appropriate settings for each.

OSPF configurations can be quite complex and vary significantly for each environment. As such, examples are unlikely to match the needs of most environments. There is an OSPF example in OSPF Example Configuration which works for a basic configuration between two peers, as in this recipe.

When following the OSPF Example Configuration note the following items of interest:

  • OSPF peering happens on the OpenVPN tunnel interface and addresses.

  • Use the OpenVPN server/client interfaces as the backbone area (0.0.0.0) interfaces in the example.

  • Firewall rules on the OpenVPN tab must pass the OSPF Protocol. It is not TCP or UDP. An “allow all” style rule which passes Any Protocol is also a viable choice, though less secure.

  • Firewall rules on the OpenVPN tab must pass multicast traffic destinations for OSPF protocol traffic, it cannot be restricted to specific sources and destinations.

Testing the Connection

The configuration is now complete. OpenVPN client instances automatically start when created, so it will attempt to connect at this point and if the configuration is correct, it will successfully connect to the server.

Try initiating a ping from one LAN to the other LAN in each direction to verify connectivity.