Remote work, mobile field staff, and distributed locations have become the norm for most businesses. With that comes a central requirement: employees need secure access to internal resources from anywhere — file servers, ERP systems, office printers, or internal web applications. A professionally configured remote access VPN is the standard solution for this, and OPNsense offers a mature, free, and highly flexible OpenVPN implementation.
Why Remote Access VPN Is Essential
Without a VPN, there are essentially two alternatives: either expose services directly to the internet — with all the associated attack surface — or have employees work without access to internal systems, which drastically limits productivity. A VPN tunnel encrypts all traffic between the client and the corporate network, reliably authenticates the user, and prevents third parties from intercepting sensitive data.
For SMBs without their own cloud infrastructure, a self-operated VPN on the OPNsense firewall is the most cost-effective solution: no monthly licensing fees, full control over users and access rights, and security stays in-house.
OpenVPN vs. WireGuard vs. IPSec
OPNsense supports multiple VPN protocols. Which one fits best?
| Criterion | OpenVPN | WireGuard | IPSec |
|---|---|---|---|
| Maturity / Stability | Very high (since 2001) | High (since 2018) | Very high (RFC standard) |
| Configuration effort | Medium | Low | High |
| Client software | OpenVPN Connect (all platforms) | Native on Linux/macOS/iOS/Android | Built into OS |
| Performance | Good | Excellent | Good |
| PKI / Certificates | Yes (recommended) | No (public keys) | Optional |
| 2FA / TOTP | Yes | No (natively) | Limited |
| NAT traversal | Excellent | Good | Problematic |
| Site-to-site | Yes | Yes | Yes |
OpenVPN remains the first choice when maximum compatibility, certificate-based authentication, and two-factor authentication are required. WireGuard stands out with its lean codebase and higher performance, but is less suited for user-based PKI setups. IPSec is the standard for site-to-site connections to third-party systems, but is considerably more complex to administer for road-warrior scenarios.
Setting Up OPNsense as an OpenVPN Server
1. Create a Certificate Authority (CA)
The first step is building your own public key infrastructure. Under System > Trust > Authorities, create a new CA:
Description: Company VPN CA
Method: Create an internal Certificate Authority
Key type: RSA, 4096 bit
Digest: SHA-256
Lifetime: 3650 days (10 years)
CN: vpn-ca.company.com
This CA is used exclusively for VPN certificates. A separate CA is recommended for web server certificates.
2. Create a Server Certificate
Under System > Trust > Certificates, issue a new certificate for the VPN server:
Method: Create an internal Certificate
Issuing CA: Company VPN CA
Type: Server Certificate
CN: openvpn-server
Lifetime: 825 days
3. Configure the OpenVPN Server
Under VPN > OpenVPN > Servers, create a new server. The key parameters:
Server Mode: Remote Access (SSL/TLS + User Auth)
Protocol: UDP on IPv4 only
Interface: WAN
Local Port: 1194
TLS Auth: Enabled (tls-auth HMAC)
Peer Cert. Auth: Company VPN CA
Server Cert.: openvpn-server
Tunnel Network: 10.8.0.0/24
Local Network: 192.168.10.0/24
tun vs. tap: For remote access scenarios, always use tun. The tun mode operates at Layer 3 (IP routing) and is more efficient. tap emulates an Ethernet adapter at Layer 2 and is only needed when broadcast traffic (e.g., for certain legacy protocols) must be transmitted through the tunnel.
Creating and Exporting Client Certificates
An individual certificate is issued for each VPN user. Under System > Trust > Certificates, create a client certificate for each user:
Method: Create an internal Certificate
Issuing CA: Company VPN CA
Type: Client Certificate
CN: john.doe
Lifetime: 365 days
The client certificate is exported together with the client configuration using the OpenVPN Client Export plugin (installable via System > Firmware > Plugins, package os-openvpn-client-export). The plugin generates ready-to-use .ovpn files that can be imported directly into OpenVPN Connect — including CA, certificate, private key, and server configuration in a single file.
Split Tunneling vs. Full Tunnel
One of the most important design decisions in a VPN setup concerns routing:
Full tunnel: All internet traffic from the client passes through the VPN tunnel. This maximizes control and enables centralized logging and filtering. The downside: increased load on the firewall and slower internet connections for clients.
Split tunneling: Only traffic destined for internal networks is routed through the tunnel. Internet traffic goes directly from the client’s location to the internet. This reduces load on the firewall and significantly improves client performance.
In OPNsense, split tunneling is controlled via the “Redirect Gateway” option. When disabled, split tunneling applies; only the subnets defined under Local Networks are routed through the tunnel.
Pushing DNS Through the Tunnel
For clients to resolve internal hostnames, the internal DNS server is pushed through the tunnel. In the OpenVPN server under Advanced, add the following options:
push "dhcp-option DNS 192.168.10.1"
push "dhcp-option DOMAIN company.internal"
push "dhcp-option DOMAIN-SEARCH company.internal"
The internal DNS server (often the OPNsense Unbound DNS Resolver itself) must accept incoming requests from the VPN tunnel subnet (10.8.0.0/24) — do not forget to add the corresponding firewall rules on the OpenVPN interface.
Two-Factor Authentication with TOTP
A user certificate alone is insufficient protection if the private key is compromised. TOTP (Time-based One-Time Password) as a second factor closes this gap significantly.
OPNsense supports TOTP natively through the local authentication server. Set it up under System > Access > Servers: create a new server of type Local + TOTP. In the OpenVPN server, set this as the backend authentication method.
Each user scans a QR code (generatable under System > Access > Users) with an authenticator app such as Google Authenticator or Bitwarden Authenticator during their first login. For subsequent VPN logins, the currently valid 6-digit TOTP token is entered together with the password:
Username: john.doe
Password: password + TOTP token (e.g., "secret123456789")
Client Software: OpenVPN Connect
For end users, OpenVPN Connect is recommended — the official client from OpenVPN Technologies, available for Windows, macOS, iOS, and Android. The imported .ovpn file contains all necessary parameters; the user only needs to enter a username and password (including TOTP).
Alternatives include OpenVPN GUI (open source) on Windows, the native openvpn command on Linux, and Tunnelblick on macOS. All of these clients support the configuration files exported by OPNsense without further modification.
Site-to-Site OpenVPN
Beyond remote access, OPNsense OpenVPN also works well for site-to-site connections between locations. In this setup, one OPNsense acts as the server while the other acts as the client. The Peer to Peer (SSL/TLS) mode is used, and both sides are assigned fixed tunnel IPs. The respective remote networks can then be added as static routes on each side — either manually or via the iroute directive.
Monitoring Active Connections
OPNsense displays all active VPN connections in real time under VPN > OpenVPN > Connection Status. Visible details include connected clients, assigned tunnel IPs, data volume, and connection duration. These data points can also be queried programmatically via the OPNsense API.
Integration with DATAZONE Control
For professional operations, manual checks in the web interface are not sufficient. DATAZONE Control enables continuous monitoring of the OpenVPN setup:
- Service status — Is the OpenVPN server process running? Is the port reachable?
- Connection count — How many clients are currently connected? Deviations from expected values trigger alerts.
- Certificate expiration — Warning before client or server certificates expire and cause VPN outages.
- Logs and anomalies — Failed authentication attempts are detected and reported.
Combined with DATAZONE Control patch management, the OPNsense installation stays up to date and security vulnerabilities in the OpenVPN stack are addressed promptly.
Conclusion
OPNsense OpenVPN gives SMBs a fully featured, cost-free remote access solution at the enterprise level. The combination of PKI-based certificate authentication, TOTP two-factor authentication, and split tunneling makes the setup both secure and user-friendly. Consistent certificate management, regular updates, and active monitoring are essential for long-term operation — so that VPN access is always available when it is needed most.
Looking to set up remote access VPN for your team professionally? We plan and implement OpenVPN on OPNsense — including PKI, 2FA, and monitoring. Learn more on our OPNsense service page or contact us directly.
More on these topics:
More articles
Backup Strategy for SMBs: Proxmox PBS + TrueNAS as a Reliable Backup Solution
Backup strategy for SMBs with Proxmox PBS and TrueNAS: implement the 3-2-1 rule, PBS as primary backup target, TrueNAS replication as offsite copy, retention policies, and automated restore tests.
OPNsense Suricata Custom Rules: Write and Optimize Your Own IDS/IPS Signatures
Suricata custom rules on OPNsense: rule syntax, custom signatures for internal services, performance tuning, suppress lists, and EVE JSON logging.
Systemd Security: Hardening and Securing Linux Services
Systemd security hardening: unit hardening with ProtectSystem, PrivateTmp, NoNewPrivileges, CapabilityBoundingSet, systemd-analyze security, sandboxing, resource limits, and creating custom timers.