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.
See also
OpenVPN Site-to-Site Configuration Example with SSL/TLS (without DCO), upon which this recipe is based.
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 as10.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.03-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¶
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 |
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
.
See also
Create a Server Certificate¶
Create a server certificate signed by the VPN CA:
Navigate to System > Certificates, Certificates tab
Click 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 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 on the row for the CA to export its certificate
Navigate to System > Certificates, Certificates tab
Click on the row for the client certificate to export the certificate
Click 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 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
See Server Configuration Options for details on each of these options.
See OpenVPN Data Channel Offload (DCO) for details on options which are incompatible with DCO.
- 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 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 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 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.
See also
Import these items at System > Certificates.
First import the CA:
Navigate to System > Certificates, Authorities tab
Click 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 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 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 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 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
See also
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.
See also