OPNsense - OpenVPN Site-to-Site und Client-VPN
Auf einen Blick
| Gilt für | OPNsense 26.1 und 26.7 (VPN → OpenVPN → Instances), OpenVPN 2.7 |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 30 Minuten (Site-to-Site), ca. 45 Minuten (Client-VPN inkl. MFA) |
| Rechte | Administrator (OPNsense-WebUI) |
| Stand | Oktober 2026 (OPNsense 26.7.5, OpenVPN 2.7.5) |
OpenVPN auf OPNsense ist eine der flexibelsten VPN-Lösungen für Unternehmen: Es verbindet Standorte per Site-to-Site-Tunnel, bindet mobile Mitarbeitende per Client-VPN an und unterstützt dabei zahlreiche Anmeldeverfahren – vom reinen Zertifikat über Active Directory bis zu Einmalpasswörtern (TOTP) und RADIUS-basierter Mehr-Faktor-Authentifizierung. Mit den Client Specific Overrides (CSC) lassen sich zudem für einzelne Clients und Standorte eigene Adressen, Routen und Einstellungen festlegen.
Dieser Artikel beschreibt die Einrichtung mit der aktuellen Instances-Oberfläche (Stand 2026) in drei Teilen: Site-to-Site, Client Specific Overrides und Client-VPN mit den verschiedenen Anmeldeverfahren.
OpenVPN in OPNsense: Was sich geändert hat (Stand 2026)
- Seit OPNsense 23.7 gibt es unter VPN → OpenVPN → Instances eine neue Oberfläche, die sich eng an die Optionen von OpenVPN selbst anlehnt. Server und Client sind dort nur noch eine Rolle derselben Instanz.
- Seit OPNsense 25.7 liegen die alten Seiten Servers und Clients nicht mehr im Kern, sondern im Plugin os-openvpn-legacy. Neue Tunnel sollten ausschließlich als Instances angelegt werden.
- OPNsense 26.7 bringt OpenVPN 2.7 (aktuell 2.7.5) und OpenSSL 3.5 mit. Als Tunneltyp steht neben TUN und TAP auch DCO (Data Channel Offload) zur Verfügung: Die Verschlüsselung der Nutzdaten läuft dann im Kernel und ist deutlich schneller.
- Ebenfalls mit 26.7 sind die alten Firewall-Regelseiten in das Plugin os-firewall-legacy gewandert. Regeln werden jetzt unter Firewall → Rules mit Auswahl der Schnittstelle gepflegt; ausgehendes NAT heißt Firewall → NAT → Source NAT.
OpenVPN, IPsec oder WireGuard?
| Kriterium | OpenVPN | IPsec | WireGuard |
|---|---|---|---|
| Stärke | Client-VPN mit vielen Anmeldeverfahren (LDAP, RADIUS, TOTP), Client-Export | Standortvernetzung, Interoperabilität mit anderen Herstellern | Einfachheit und Geschwindigkeit |
| Site-to-Site | Gut, vor allem zwischen zwei OPNsense | Sehr gut, Industriestandard | Gut |
| Benutzer-Anmeldung mit MFA | Ja, integriert | Möglich (EAP/RADIUS), aufwendiger | Nein, nur Schlüssel |
| Durchsatz | Gut, mit DCO sehr gut | Sehr gut | Sehr gut |
Für die reine Kopplung von Standorten ist IPsec meist die erste Wahl (siehe OPNsense - IPsec Site-to-Site route-based). OpenVPN spielt seine Stärken vor allem beim Client-VPN aus.
Grundlagen: Zertifikate und TLS-Schlüssel
OpenVPN arbeitet im TLS-Modus mit einer eigenen PKI. Diese wird direkt in OPNsense unter System → Trust angelegt:
- Authorities: eine neue interne Zertifizierungsstelle erstellen, z. B. OpenVPN-CA (RSA 4096 oder ECDSA, SHA-256).
- Certificates: ein Server-Zertifikat (Typ Server, Common Name = FQDN der Firewall) ausstellen.
- Für jeden Standort bzw. Benutzer ein eigenes Client-Zertifikat (Typ Client). Bei Benutzerzertifikaten entspricht der Common Name (CN) dem Benutzernamen – beim Anlegen über System → Access → Users setzt OPNsense den CN automatisch.
- Revocation: eine Sperrliste (CRL) für die CA anlegen, um verlorene Zertifikate sperren zu können.
Zusätzlich wird unter VPN → OpenVPN → Instances → Static Keys ein TLS static key erzeugt (Zahnrad-Symbol). Empfohlen ist der Modus crypt (Standard): Er verschlüsselt und authentifiziert den Steuerkanal und schützt den Server so vor Port-Scans und DoS-Angriffen auf den TLS-Stack.
Teil 1: OpenVPN Site-to-Site
Beispiel-Szenario
| Eigenschaft | Standort A (Zentrale, Server) | Standort B (Filiale, Client) |
|---|---|---|
| Öffentliche Adresse | vpn.example.com (203.0.113.1) |
beliebig, auch dynamisch |
| LAN | 192.168.10.0/24 |
192.168.20.0/24
|
| Tunnelnetz | 10.8.0.0/24
| |
| Client-Zertifikat (CN) | filiale-b
| |
Ein Vorteil gegenüber route-based IPsec: Der Client-Standort darf eine dynamische IP-Adresse haben.
Schritt 1: Zertifikate auf die Filiale übertragen
Auf der Zentrale unter System → Trust die CA (nur öffentlicher Teil) sowie Zertifikat und privaten Schlüssel von filiale-b exportieren und auf der Filiale unter System → Trust importieren. Den TLS static key ebenfalls kopieren (gleicher Inhalt, gleicher Modus).
Schritt 2: Server-Instanz auf der Zentrale
VPN → OpenVPN → Instances → +:
| Feld | Wert |
|---|---|
| Role | Server |
| Description | S2S Filialen |
| Protocol / Port number | UDP (IPv4) / 1194
|
| Type | TUN (oder DCO für höheren Durchsatz) |
| Server (IPv4) | 10.8.0.0/24
|
| Topology | subnet |
| Certificate | Server-Zertifikat |
| TLS static key | der erzeugte Schlüssel (Modus crypt) |
| Data Ciphers | AES-256-GCM, CHACHA20-POLY1305
|
| Local Network | 192.168.10.0/24 (wird an die Clients übertragen)
|
| Remote Network | 192.168.20.0/24 (Route auf der Zentrale zur Filiale)
|
Speichern und Apply.
Schritt 3: Client Specific Override für die Filiale (Pflicht!)
Damit der Server weiß, hinter welchem Client das Netz 192.168.20.0/24 liegt, ist zwingend ein CSC nötig. Ohne ihn legt OPNsense zwar die Route an, der OpenVPN-Prozess verwirft die Pakete aber:
VPN → OpenVPN → Client Specific Overrides → +:
- Servers: S2S Filialen (oder leer = alle)
- Common name:
filiale-b - Remote Network:
192.168.20.0/24(wird alsiroutegesetzt) - optional IPv4 Tunnel Network: feste Tunneladresse, z. B.
10.8.0.20/24
Schritt 4: Client-Instanz auf der Filiale
VPN → OpenVPN → Instances → +:
- Role: Client, Protocol: UDP (IPv4), Remote:
vpn.example.com:1194 - Certificate: filiale-b, TLS static key: importierter Schlüssel, gleiche Data Ciphers
- Remote Network:
192.168.10.0/24
Schritt 5: Firewall-Regeln
- Zentrale, Firewall → Rules, Interface WAN: Pass, UDP, Ziel WAN address, Port
1194. - Beide Seiten, Interface-Gruppe OpenVPN: gewünschten Verkehr zwischen den LANs erlauben (z. B. Quelle
192.168.20.0/24→ Ziel192.168.10.0/24).
Den Status zeigt VPN → OpenVPN → Connection Status. Für Monitoring, Policy-based Routing oder eigene Regeln pro Tunnel kann das Tunnelgerät (z. B. ovpns1) unter Interfaces → Assignments zugewiesen werden.
Teil 2: Client Specific Overrides (CSC) im Detail
Client Specific Overrides nutzen die OpenVPN-Option client-config-dir: Für jeden Client wird anhand des Common Name seines Zertifikats (oder des Benutzernamens, siehe unten) eine eigene Konfiguration ausgeliefert.
Die wichtigsten Felder
| Feld | Zweck |
|---|---|
| Servers | Instanzen, für die der Eintrag gilt (leer = alle). |
| Common name | X.509-Common-Name des Clients – hierauf wird abgeglichen. |
| Connection blocking | Blockiert die Verbindung dieses Clients. Nicht als Ersatz für das Sperren kompromittierter Zertifikate verwenden – dafür ist die CRL da. |
| Push reset | Globale Push-Optionen der Instanz für diesen Client nicht übernehmen. |
| IPv4/IPv6 Tunnel Network | Feste Tunneladresse für diesen Client. |
| Local Network | Netze, die nur diesem Client als Route übertragen werden. |
| Remote Network | Netze hinter diesem Client (iroute) – Pflicht für Site-to-Site.
|
| Route gateway | Abweichendes Gateway, wenn das Tunnelnetz segmentiert wird. |
| Redirect gateway | Gesamten Internetverkehr dieses Clients durch den Tunnel leiten. |
| DNS Servers / DNS Domain / NTP / WINS | Abweichende Client-Einstellungen. |
Typische Einsatzzwecke
- Site-to-Site mit mehreren Filialen: Pro Filiale ein CSC mit ihrem Remote Network – eine einzige Server-Instanz bedient so beliebig viele Standorte (Hub-and-Spoke).
- Feste IP-Adressen für Benutzer oder Gruppen: Etwa Admins in
10.9.0.0/27, Dienstleister in10.9.0.64/27. Mit Aliassen auf diese Bereiche lassen sich unter Firewall → Rules → OpenVPN unterschiedliche Rechte pro Benutzergruppe umsetzen. - Dienstleisterzugang einschränken: Per CSC nur ein einzelnes Zielnetz als Local Network übertragen und Push reset setzen.
- Full Tunnel nur für bestimmte Benutzer: Redirect gateway im CSC statt global in der Instanz.
CSC mit Benutzername statt Zertifikat
Standardmäßig wird nach dem Common Name des Zertifikats gesucht. Ist in der Instanz Username as CN aktiviert, wird stattdessen der angemeldete Benutzername verwendet – praktisch, wenn mehrere Benutzer dasselbe Zertifikat verwenden oder die Anmeldung über LDAP/RADIUS erfolgt.
CSC über RADIUS
Liefert ein RADIUS-Server bei der Anmeldung die Attribute Framed-IP-Address, Framed-IP-Netmask und Framed-Route, übernimmt OPNsense diese wie einen CSC. So lassen sich Adressen und Routen zentral im Verzeichnis (z. B. über Microsoft NPS oder privacyIDEA/FreeRADIUS) verwalten. Mit der Instanz-Option Require Client Provisioning werden nur Clients zugelassen, für die ein CSC oder eine RADIUS-Zuweisung existiert.
Fehlersuche bei CSC
Die meisten Probleme entstehen durch einen nicht passenden Common Name. Im Log (VPN → OpenVPN → Log File) helfen diese Meldungen:
Locate overwrite for 'XXX' using server 'XXX'– OPNsense sucht einen passenden CSC (bei Benutzeranmeldung).client config created @ ...– CSC wurde geschrieben.unable to write client config for XXX, missing target filename– kein passender CSC gefunden.
Teil 3: Client-VPN (Road Warrior)
Server-Instanz für mobile Clients
Für das Client-VPN empfiehlt sich eine eigene Instanz (eigener Port, z. B. 1195, und eigenes Tunnelnetz, z. B. 10.9.0.0/24), getrennt von der Site-to-Site-Instanz:
| Feld | Wert |
|---|---|
| Role / Protocol / Port | Server / UDP (IPv4) / 1195
|
| Server (IPv4) | 10.9.0.0/24
|
| Certificate / TLS static key | Server-Zertifikat / Static Key (crypt) |
| Verify Client Certificate | require (Standard) |
| Authentication | je nach Verfahren, siehe unten |
| Strict User/CN Matching | aktiv, wenn jeder Benutzer ein eigenes Zertifikat hat |
| Local Network | 192.168.10.0/24 (Split Tunnel) – oder Redirect gateway = default für Full Tunnel
|
| DNS Servers / DNS Domain | interne DNS-Server und Domäne |
Bei Full Tunnel (Redirect gateway) zusätzlich unter Firewall → NAT → Source NAT eine Regel anlegen, die das Tunnelnetz 10.9.0.0/24 auf die WAN-Adresse übersetzt.
Die Anmeldeverfahren im Überblick
Die Anmeldung setzt sich aus dem Client-Zertifikat (Verify Client Certificate) und optional einer Benutzeranmeldung (Feld Authentication) zusammen. Die Authentifizierungsserver werden unter System → Access → Servers angelegt.
| Verfahren | Faktoren | Einrichtung | Bewertung |
|---|---|---|---|
| Nur Zertifikat | Besitz (Zertifikat) | Authentication leer | Einfach, aber ein gestohlenes Notebook genügt für den Zugang – nur für Geräte-/Standortzugänge. |
| Zertifikat + lokaler Benutzer | Besitz + Wissen | Authentication = Local Database | Gut für kleine Umgebungen; Benutzer in OPNsense pflegen. |
| Zertifikat + Active Directory/LDAP | Besitz + Wissen | LDAP-Server anlegen, in Authentication wählen | Zentrale Benutzerverwaltung, sauberes Offboarding. |
| Zertifikat + lokaler Benutzer + TOTP | Besitz + Wissen + Einmalpasswort | Server-Typ Local + Timebased One Time Password | Echte MFA ohne externe Komponenten. |
| Zertifikat + LDAP + TOTP | Besitz + Wissen + Einmalpasswort | Server-Typ LDAP + Timebased One Time Password | AD-Passwort plus OTP-Seed in OPNsense. |
| Zertifikat + RADIUS (z. B. privacyIDEA, NPS mit MFA) | Besitz + Wissen + beliebiger zweiter Faktor | Server-Typ Radius | Flexibelste Lösung: Push, OTP, Hardware-Token, zentrale Richtlinien, CSC per RADIUS. |
| Nur Benutzer/Passwort | Wissen | Verify Client Certificate = none | Nicht empfohlen – ohne Zertifikat nur mit MFA vertretbar. |
Verfahren 1: Zertifikat + Benutzer aus Active Directory (LDAP)
- System → Access → Servers → +, Typ LDAP: Hostname des Domain Controllers, Port 636 mit Transport SSL - encrypted (LDAPS), Bind-Konto mit Leserechten, Base DN und Authentication containers (Schaltfläche Select).
- Zugriff auf eine AD-Gruppe beschränken: unter Extended Query z. B.
&(memberOf=CN=VPN-Benutzer,OU=Gruppen,DC=firma,DC=local). - Unter System → Access → Tester die Anmeldung testen.
- In der OpenVPN-Instanz unter Authentication den LDAP-Server auswählen.
Da die Benutzer nicht lokal existieren, für sie unter System → Trust → Certificates Client-Zertifikate mit CN = Benutzername ausstellen; Strict User/CN Matching stellt sicher, dass Zertifikat und Anmeldung zusammengehören.
Verfahren 2: Zertifikat + Benutzer + TOTP (Einmalpasswort)
OPNsense bringt einen eigenen TOTP-Server mit, kompatibel mit jeder Authenticator-App:
- System → Access → Servers → +, Typ Local + Timebased One Time Password (bzw. LDAP + Timebased One Time Password für AD-Benutzer). Standard: Token length 6, Time window 30 s, Grace period 10 s.
- Für jeden Benutzer unter System → Access → Users das Feld OTP seed mit Generate new secret füllen, speichern und den angezeigten QR-Code mit der Authenticator-App scannen. (Bei LDAP+TOTP müssen die AD-Benutzer dazu als lokale Benutzer existieren – z. B. über die Import-Funktion unter System → Access → Users –, damit der OTP-Seed gespeichert werden kann; das Passwort wird weiterhin gegen LDAP geprüft.)
- In der OpenVPN-Instanz den TOTP-Server unter Authentication wählen.
- Renegotiate time auf
0setzen oder ein Auth Token Lifetime festlegen – sonst fordert OpenVPN nach einer Stunde (Standard 3600 s) erneut die Anmeldung an, und das inzwischen abgelaufene Einmalpasswort führt zum Verbindungsabbruch.
Eingabe beim Verbinden: Standardmäßig wird das Einmalpasswort vor dem Passwort in das Passwortfeld eingegeben (z. B. 123456MeinPasswort). Mit der Option Reverse token order am Authentifizierungsserver kommt der Code ans Ende. Komfortabler ist die Export-Option Enable static challenge (OTP): Der Client fragt das Einmalpasswort dann in einem eigenen Feld ab.
Verfahren 3: Zertifikat + RADIUS (z. B. privacyIDEA)
Für unternehmensweite MFA mit Push-Bestätigung, Hardware-Token oder Passkeys wird OPNsense als RADIUS-Client an einen MFA-Server angebunden:
- System → Access → Servers → +, Typ Radius: Adresse des RADIUS-Servers, Shared Secret, Services Authentication (optional Accounting), ausreichend hohes Timeout (z. B. 30 s für Push-Bestätigungen).
- Auf dem RADIUS-Server die OPNsense als Client eintragen.
- In der OpenVPN-Instanz den RADIUS-Server unter Authentication wählen und ein Auth Token Lifetime setzen, damit Neuverhandlungen ohne erneute MFA-Abfrage laufen.
Zusätzlich können RADIUS-Attribute (Framed-IP-Address, Framed-Route) Adressen und Routen pro Benutzer liefern – siehe CSC über RADIUS.
Client-Profile exportieren
Unter VPN → OpenVPN → Client Export:
- Remote Access Server: die Client-VPN-Instanz, Hostname: öffentlicher DNS-Name der Firewall.
- Export type: File Only (eine
.ovpn-Datei mit eingebetteten Zertifikaten) für OpenVPN Connect und den OpenVPN-Community-Client; Varianten für Viscosity sind ebenfalls verfügbar. - Sinnvolle Optionen: Validate server subject, Disable password save (verhindert gespeicherte Passwörter), Enable static challenge (OTP) bei TOTP sowie ein P12 Password zum Schutz des privaten Schlüssels.
- Unten in der Liste beim gewünschten Benutzer bzw. Zertifikat auf Download klicken.
Sicherheitsempfehlungen
- Pro Benutzer ein eigenes Zertifikat mit Strict User/CN Matching – keine geteilten Zertifikate (Option duplicate-cn vermeiden).
- MFA für alle Benutzerzugänge (TOTP oder RADIUS); reine Zertifikatsanmeldung nur für Standorte.
- Data Ciphers auf AES-256-GCM und CHACHA20-POLY1305 beschränken; CBC-Verfahren nur für Altclients.
- TLS static key im Modus crypt verwenden.
- CRL pflegen und bei Verlust eines Geräts das Zertifikat sofort widerrufen; optional OCSP aktivieren (Use OCSP (when available)).
- Getrennte Instanzen für Site-to-Site, Mitarbeitende und Dienstleister mit eigenen Tunnelnetzen und Firewall-Regeln.
- Logs auswerten: VPN-Anmeldungen und Fehlversuche an ein SIEM weiterleiten, z. B. ein Open-Source-SIEM auf Wazuh-Basis.
Typische Probleme und Lösungen
| Symptom | Ursache und Lösung |
|---|---|
| Site-to-Site: Tunnel steht, aber kein Verkehr zur Filiale | CSC mit Remote Network fehlt oder Common Name stimmt nicht – siehe Log-Meldungen oben. |
| TLS handshake failed / TLS key negotiation failed | WAN-Regel fehlt, falscher Port/Protokoll oder TLS static key bzw. Modus stimmen nicht überein. |
| AUTH_FAILED | Benutzer/Passwort falsch, TOTP-Reihenfolge falsch, Benutzer nicht in der LDAP-Gruppe oder Strict User/CN Matching greift. |
| Verbindung bricht nach ca. 60 Minuten ab | Neuverhandlung mit abgelaufenem Einmalpasswort – Renegotiate time = 0 oder Auth Token Lifetime setzen. |
| Interne Namen werden nicht aufgelöst | DNS Servers/DNS Domain in Instanz oder CSC setzen; unter Windows ggf. Register DNS aktivieren. |
| Full Tunnel: kein Internet | Source-NAT-Regel für das Tunnelnetz fehlt. |
| Langsamer Durchsatz | Typ DCO prüfen, UDP statt TCP verwenden, MTU/MSS fix anpassen. |
Fazit
OpenVPN auf OPNsense ist 2026 moderner denn je: Die Instances-Oberfläche bildet OpenVPN 2.7 sauber ab, DCO sorgt für hohen Durchsatz, und Client Specific Overrides machen aus einer Server-Instanz einen flexiblen Hub für Filialen und Benutzergruppen. Seine größte Stärke bleibt das Client-VPN: Zertifikat, Active Directory, TOTP und RADIUS lassen sich frei kombinieren – bis hin zu echter Mehr-Faktor-Authentifizierung mit Push-Bestätigung über einen zentralen MFA-Server.
Unterstützung von m.a.x. it
Sie möchten Ihr Client-VPN mit Mehr-Faktor-Authentifizierung absichern, Filialen per OpenVPN anbinden oder bestehende Legacy-Server auf Instances migrieren? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit OPNsense-Firewall-Services von m.a.x. it und einer Managed Firewall von m.a.x. it.
Siehe auch
- OPNsense - WireGuard Site-to-Site und Road Warrior
- VPN Techniken für das Homeoffice
- OPNsense - IPsec Site-to-Site policy-based
- OPNsense - IPsec Site-to-Site route-based
- OPNsense - Radius
- privacyIDEA – Open-Source-Mehr-Faktor-Authentifizierung
- Zwei-Faktor-Authentifizierung
- LDAP
- Active Directory
- PKI
- OPNsense - NetBird-Plugin
Links und Quellen
- OPNsense-Doku – Virtual Private Networking (OpenVPN)
- OPNsense-Doku – OpenVPN Site-to-Site mit Instances
- OPNsense-Doku – OpenVPN Road Warrior mit Instances
- OPNsense-Doku – Zwei-Faktor-Authentifizierung
- m.a.x. it – OPNsense-Firewall-Services
Über m.a.x. it Die m.a.x. Informationstechnologie AG ist seit über 30 Jahren IT-Partner mittelständischer und großer Unternehmen in München und bietet maßgeschneiderte Lösungen und Services in den Bereichen Cloud, Cybersecurity, Netzwerk, Windows, Linux und Softwareentwicklung. Sie haben eine Frage zu diesem Artikel oder brauchen Unterstützung?
