OpenVPN Site-to-Site Tunnel in pfSense - Setup Guide

An OpenVPN site-to-site tunnel provides a persistent encrypted connection between two or more locations, merging their local networks into a unified address space. Unlike IPsec, OpenVPN operates in userspace over SSL/TLS and can function through TCP 443, making it the preferred option when working through networks with strict filtering (corporate proxies, hotel Wi-Fi, mobile carriers blocking ESP/IKE).

This guide covers two modes of site-to-site tunnel configuration in pfSense: the simplified Shared Key approach and the scalable TLS/PKI approach. The material is intended for network engineers with pfSense administration experience and a solid understanding of routing fundamentals.

When to Choose OpenVPN Over IPsec

The choice between OpenVPN and IPsec for site-to-site connections depends on the specific operating conditions.

Recommendation: use OpenVPN when connecting sites through restrictive networks or when compatible IPsec equipment is unavailable on the remote side. When maximum performance and compatibility with third-party equipment are required, use IPsec site-to-site .

Prerequisites

Before configuring, verify the following conditions are met:

1. Public IP addresses or Dynamic DNS on both endpoints. At least one side must have a static address or an FQDN reachable from the internet.
2. Non-overlapping subnets behind both endpoints:
   • Site A (server): LAN 10.1.0.0/24
   • Site B (client): LAN 10.2.0.0/24
   • Tunnel Network: 10.8.1.0/30 (a /30 suffices for point-to-point)
3. Agreed parameters - both sides must use identical encryption algorithms and protocol (UDP/TCP).

Shared Key Mode

Shared Key (Pre-Shared Key) mode is the simplest method for establishing a site-to-site tunnel between two locations. Instead of a PKI infrastructure, a single static key known to both sides is used.

Warning:

The OpenVPN developers have deprecated Shared Key mode. It will be removed from future OpenVPN releases. TLS/PKI mode is recommended for new deployments.

Shared Key Limitations

• Supports only a single peer-to-peer connection (two endpoints).
• Does not scale - each pair of sites requires a separate instance with a unique port.
• Key compromise exposes the entire tunnel.
• No Perfect Forward Secrecy (PFS).
• Incompatible with DCO (Data Channel Offload).

Server-Side Configuration (Site A)

Configuration is performed under VPN > OpenVPN > Servers.

Fig. 1. OpenVPN server list in pfSense

1. Click Add to create a new server.
2. Fill in the parameters:

3. Click Save.
4. After saving, reopen the server and copy the contents of the Shared Key field - it will be needed for the client-side configuration.

Client-Side Configuration (Site B)

On the Site B pfSense, navigate to VPN > OpenVPN > Clients and click Add.

Warning:

All cryptographic parameters (encryption algorithms, HMAC, Shared Key) must be identical on both sides. A mismatch will cause tunnel establishment to fail without an informative error message.

TLS/PKI Mode

TLS/PKI mode (Peer to Peer SSL/TLS) uses X.509 certificates for authentication and provides scalability, Perfect Forward Secrecy, and compatibility with DCO. This is the recommended mode for new deployments.

Certificate Preparation

The following must be created:

1. CA - under System > Certificates > Authorities (if not already created).
2. Server certificate - type Server Certificate, signed by the CA.
3. Client certificate - type User Certificate for each remote site. Created under System > Certificates > Certificates (not through User Manager, as site-to-site does not require user accounts).

Detailed certificate creation instructions are provided in the OpenVPN Remote Access Server section.

Server-Side Configuration

Configuration is performed under VPN > OpenVPN > Servers.

For TLS mode with multiple clients (hub-and-spoke), the IPv4 Remote Network(s) field is populated with subnets from all remote sites, separated by commas.

Client-Side Configuration

On the remote site pfSense: VPN > OpenVPN > Clients > Add.

Routing

Correct routing is the critical element of a functioning site-to-site tunnel. OpenVPN uses two mechanisms for conveying route information.

Remote Network(s) Field vs iroute

• IPv4 Remote Network(s) in the server settings creates an operating system-level route indicating that traffic to the specified subnets should be directed to the OpenVPN interface.
• iroute in Client Specific Overrides tells the OpenVPN process which client serves a specific subnet. Without iroute, OpenVPN does not know through which tunnel connection to send packets.

In TLS mode with multiple clients, both mechanisms must be configured:

1. In the server settings, list all remote subnets in IPv4 Remote Network(s).
2. For each client, create an entry in Client Specific Overrides with the iroute directive:

iroute 10.2.0.0 255.255.255.0;

In Shared Key mode, iroute is not used - routing is determined by the Remote Network(s) field on both sides.

Static Routes on Internal Devices

Devices on the local networks of both sites must have a route to the remote subnets via pfSense. If pfSense serves as the default gateway, routes are created automatically. Otherwise, static routes must be added on routers or L3 switches.

Multi-Site Hub-and-Spoke

A hub-and-spoke topology allows multiple remote sites (spokes) to connect to a central office (hub) through a single OpenVPN server instance in TLS/PKI mode.

Architecture

          ┌──────────────┐
          │   Hub (HQ)   │
          │  10.1.0.0/24 │
          │  OpenVPN     │
          │  Server      │
          └──────┬───────┘
                 │
        ┌────────┼────────┐
        │        │        │
   ┌────▼───┐ ┌──▼────┐ ┌─▼──────┐
   │ Spoke1 │ │ Spoke2│ │ Spoke3 │
   │10.2.0/24│ │10.3.0/24│ │10.4.0/24│
   └────────┘ └───────┘ └────────┘

Hub Configuration

On the central pfSense, a single OpenVPN server is created in Peer to Peer (SSL/TLS) mode with the following parameters:

• IPv4 Tunnel Network: 10.8.1.0/24 - sufficient for addressing all spokes.
• IPv4 Remote Network(s): 10.2.0.0/24, 10.3.0.0/24, 10.4.0.0/24 - all spoke subnets.

For each spoke, an entry is created in Client Specific Overrides:

Spoke 1 (Common Name: spoke1-cert):

iroute 10.2.0.0 255.255.255.0;

Spoke 2 (Common Name: spoke2-cert):

iroute 10.3.0.0 255.255.255.0;

Spoke 3 (Common Name: spoke3-cert):

iroute 10.4.0.0 255.255.255.0;

Inter-Spoke Communication

By default, spoke sites cannot communicate directly - all traffic passes through the hub. To enable this:

1. Enable the Inter-client communication option on the server (or add client-to-client in Custom options).
2. On each spoke, add routes to the subnets of other spokes via VPN (the IPv4 Remote Network(s) field).

Firewall Rules

WAN Rules

Similar to the Remote Access server - permit inbound connections on the server port:

When the remote site has a known fixed IP address, specifying it in the Source field is recommended to reduce the attack surface.

OpenVPN Interface Rules

Permit traffic between site subnets:

To restrict access, create rules permitting only the necessary protocols and ports. For details, see pfSense Firewall Rules .

Comparison with IPsec

The choice between OpenVPN and IPsec site-to-site depends on the specific scenario.

When OpenVPN Is Preferable

• NAT issues - the remote site sits behind double NAT, or the ISP blocks the ESP protocol.
• TCP fallback - the need to operate over TCP 443 when UDP is blocked.
• Configuration simplicity - Shared Key mode requires a minimal number of parameters.
• Homogeneous equipment - both sides run pfSense or another system supporting OpenVPN.
• Dynamic IPs - OpenVPN handles IP address changes on both sides correctly (when using DDNS).

When IPsec Is Preferable

• Performance - IPsec is processed at the kernel level with hardware acceleration (AES-NI). For links exceeding 500 Mbit/s, IPsec is significantly more efficient.
• Compatibility - connecting to third-party equipment (Cisco, Juniper, cloud providers) that does not support OpenVPN.
• Standardization - corporate policies may mandate standardized protocols (IKEv2, ESP).
• Mesh topology - IPsec with VTI provides more flexible routing between multiple sites.

For details on IPsec configuration, see the IPsec Site-to-Site VPN section.

Troubleshooting

Tunnel Is Up but Traffic Does Not Pass

1. Check routes - on both sides, navigate to Diagnostics > Routes and verify that routes to remote subnets exist via the OpenVPN interface.
2. Check iroute - in TLS mode with multiple clients, verify that an iroute directive is configured for each client in Client Specific Overrides.
3. Check firewall rules - the OpenVPN interface must have rules permitting traffic from the remote subnet.
4. Check return routing - devices on the remote site must have a route back to the local subnet via pfSense.

Tunnel Does Not Establish

1. Check OpenVPN logs - Status > System Logs > OpenVPN on both sides.
2. Verify port accessibility - Diagnostics > Packet Capture on WAN, filtering by the server port.
3. Verify parameter agreement - encryption algorithms, HMAC, protocol, and tunnel network must be identical.
4. Check certificates (TLS mode) - both certificates must be signed by the same CA with valid expiration dates.
5. Check the Shared Key (PSK mode) - the key must be copied in its entirety, without leading or trailing whitespace.

MTU Problems

Symptoms: small packets (ping, DNS) pass through while large ones (HTTP, SMB) do not. Resolution:

1. Add the following to Custom options on both sides:

fragment 1400;
mssfix 1400;

2. If the tunnel traverses networks with reduced MTU (PPPoE, MPLS), decrease the value to 1300.
3. Alternatively, configure MSS Clamping in the pfSense firewall rules.

Intermittent Connection Drops

1. Check keepalive - verify that ping/ping-restart parameters are consistent on both sides. Recommended values: ping 10; ping-restart 60.
2. Check rekeying - if the tunnel drops during key renegotiation, increase reneg-sec or verify that both sides support the same algorithms.
3. Check the ISP - some providers reset long-lived UDP sessions. Switching to TCP may resolve the issue.

Related Sections

• OpenVPN Remote Access Server - configuring OpenVPN for remote employee access
• Client Configuration Export - generating configuration files using the openvpn-client-export package
• IPsec Site-to-Site VPN - alternative site-to-site connectivity via IPsec
• pfSense Firewall Rules - managing rules for VPN traffic