OPNsense - IPsec Road Warrior mit IKEv2

Aus maxTechCorner
(Weitergeleitet von OPNsense IPsec EAP-MSCHAPv2)

Auf einen Blick

Gilt fürOPNsense 26.1 und 26.7 (VPN → IPsec → Connections, Pools), IKEv2, Clients unter Windows, macOS, iOS, Android und Linux
BereichIT-Security
Dauerca. 45 Minuten (Server mit EAP-MSCHAPv2), ca. 15 Minuten je Client-Plattform
RechteAdministrator (OPNsense-WebUI), Zugriff auf den öffentlichen DNS
StandOktober 2026 (OPNsense 26.7.5)

IPsec Road Warrior auf OPNsense bindet Notebooks und Smartphones per IKEv2 an das Firmennetz an – ohne zusätzliche Software, denn Windows, macOS, iOS und Android bringen IKEv2-Clients bereits mit. Der Server authentisiert sich mit einem Zertifikat, die Benutzer per Benutzername und Passwort (EAP-MSCHAPv2), per RADIUS mit Anbindung an Active Directory (EAP-RADIUS) oder mit eigenem Client-Zertifikat (EAP-TLS). Die Adressen werden aus einem Pool vergeben, DNS-Server direkt mitgeliefert.

Dieser Artikel zeigt die Einrichtung mit der aktuellen Connections-Oberfläche (Stand OPNsense 26.7): Voraussetzungen, Server mit EAP-MSCHAPv2 (gemeinsamer Pool oder feste Adresse je Benutzer), Firewall, NAT und DNS, die Alternativen EAP-RADIUS und EAP-TLS sowie die Einrichtung der Clients und die Fehlersuche.

IPsec Road Warrior, OpenVPN oder WireGuard?

Kriterium IPsec IKEv2 OpenVPN WireGuard
Client-Software in allen Betriebssystemen eingebaut OpenVPN-Client nötig WireGuard-App nötig
Benutzeranmeldung EAP-MSCHAPv2 (lokal oder per RADIUS), Zertifikat; MFA nur eingeschränkt (Push) LDAP, RADIUS, TOTP, Zertifikat nur Schlüssel pro Gerät
Roaming (WLAN ↔ Mobilfunk) sehr gut (MOBIKE) Neuverbindung sehr gut
Typischer Einsatz verwaltete Geräte ohne Zusatzsoftware, Smartphones Benutzer-VPN mit integrierter MFA einfache, schnelle Geräte-VPNs
IPsec Road Warrior auf der OPNsense: Clients verbinden sich per IKEv2 über UDP 500/4500 mit vpn1.example.com; der Server weist sich per Zertifikat aus, Benutzer melden sich per EAP-MSCHAPv2, EAP-RADIUS oder EAP-TLS an und erhalten eine Adresse aus dem Pool 172.16.203.0/24 samt DNS-Server.

Beispiel und Voraussetzungen

Element Wert
Öffentlicher Name vpn1.example.com → WAN-Adresse 203.0.113.1
LAN 192.168.1.0/24 (Firewall 192.168.1.1)
Pool für die Clients 172.16.203.0/24
  1. DNS: A-Eintrag (und ggf. AAAA) für vpn1.example.com beim DNS-Anbieter.
  2. Zertifikate unter System → Trust: eine eigene CA (z. B. IPsec CA) und ein Server-Zertifikat für vpn1.example.com mit diesem Namen als Subject Alternative Name. Die CA muss später auf den Clients installiert werden. Alternativ ein öffentlich vertrauenswürdiges Zertifikat über den ACME-Client – dann entfällt in der Regel die Verteilung der CA.
  3. Firewall-Regel auf dem WAN (Firewall → Rules): Pass, UDP, Quelle any, Ziel WAN-Adresse bzw. Alias für vpn1.example.com, Ports 500 und 4500. Da Road Warrior mit UDP-Kapselung arbeiten, ist keine Regel für ESP nötig.

Server mit EAP-MSCHAPv2

EAP-MSCHAPv2 ist die universellste Variante: Der Server weist sich per Zertifikat aus, die Benutzer per Benutzername und Passwort. Die OPNsense-Dokumentation beschreibt zwei Methoden – nur eine davon verwenden:

Methode Vorteil Nachteil
1: Gemeinsamer Pool (EAP Id %any) einfach, funktioniert mit praktisch allen Clients (auch dem Windows-Client) alle Benutzer im selben Netz, keine individuellen Regeln
2: Feste Adresse je Benutzer (eigene Connection und Pool je Benutzer) individuelle Firewall-Regeln pro Benutzer mehr Aufwand; der eingebaute Windows-Client erwartet %any und funktioniert damit nicht

Schritt 1: Pools

VPN → IPsec → Connections, Bereich Pools → +:

  • Name: pool-roadwarrior-ipv4, Network: 172.16.203.0/24, DNS: 192.168.1.1 (Unbound auf der Firewall)
  • optional IPv6: pool-roadwarrior-ipv6 mit z. B. 2001:db8:1234:ec::/120 (strongSwan-Pools höchstens /97)

Für Methode 2 stattdessen je Benutzer einen Pool mit einer Adresse (172.16.203.1/32, 172.16.203.2/32 …).

Schritt 2: Benutzer (EAP-Schlüssel)

VPN → IPsec → Pre-Shared Keys → + je Benutzer:

  • Local Identifier: Benutzername, z. B. mueller@vpn1.example.com
  • Remote Identifier: vpn1.example.com (für den eingebauten Android-Client nötig; bei Problemen leer lassen)
  • Pre-Shared Key: das Passwort des Benutzers – lang und zufällig
  • Type: EAP

Schritt 3: Connection

VPN → IPsec → Connections: unten Enable IPsec anhaken und anwenden, dann + (erweiterter Modus):

Feld Wert
Proposals aes256-sha256-modp2048 (default entfernen) – auf die Clients abstimmen
Version IKEv2
Local addresses vpn1.example.com
UDP encapsulation aktiv
Rekey time 2400; beim eingebauten Windows-Client 86400
DPD delay 30
Pools pool-roadwarrior-ipv4 (und -ipv6)
Send certificate Always
Keyingtries 0

Speichern, dann:

  • Local Authentication: Authentication Public Key, Id vpn1.example.com, Certificates = Server-Zertifikat
  • Remote Authentication: Authentication EAP-MSCHAPv2, EAP Id %any (Methode 2: der jeweilige Benutzername)
  • Children → +: Start action None, ESP proposals aes256-sha256-modp2048, Local = freigegebene Netze, Rekey time 600 (Windows-Client: 0)

Split Tunnel oder Full Tunnel entscheidet das Feld Local im Child: 192.168.1.0/24 leitet nur das Firmennetz durch den Tunnel, 0.0.0.0/0 (und ::/0) den gesamten Verkehr. Ein Full Tunnel ist sicherer, weil kein Verkehr am Tunnel vorbei läuft – vor allem bei Dual-Stack-Netzen.


HinweisNur eine Connection mit EAP Id %any anlegen. Mehrere davon würden es jedem Benutzer erlauben, sich an jeder dieser Connections anzumelden.

Firewall, NAT und DNS

Regeln auf der IPsec-Schnittstelle

Firewall → Rules, Interface IPsec (Reihenfolge beachten):

  1. ICMP von den Clients zur Firewall (Fehlersuche).
  2. Zugriff des Pools (Alias net_pool_roadwarrior) auf die benötigten Ziele, z. B. LAN net – bei Methode 2 je Benutzer-Alias eigene Regeln.
  3. Bei Full Tunnel Internetzugriff: Ziel = Alias mit den privaten Netzen, invertiert – nicht any, da any auch alle lokal angeschlossenen Netze umfasst.

Benutzerrechte begrenzen: Statt dem ganzen Pool das ganze LAN zu öffnen, die Ziele auf benötigte Server und Ports beschränken.

Source NAT

Für den Internetzugriff im Full Tunnel unter Firewall → NAT → Source NAT (Modus Hybrid oder Manual, siehe NAT in OPNsense): Interface WAN, Quelle Pool-Netz, Übersetzung WAN address.

DNS

Den Clients per Pool einen internen DNS-Server mitgeben (z. B. Unbound auf der Firewall) und das Pool-Netz in den Access Lists von Unbound erlauben. Interne Zonen wie die Active-Directory-Domain per Query Forwarding an die Domain Controller. Bei einem reinen IPv4-Full-Tunnel in Dual-Stack-Netzen bevorzugen Clients sonst unter Umständen IPv6-DNS-Server des lokalen Netzes (DNS-Leak).

Alternative Anmeldeverfahren

Verfahren Remote Authentication Einsatz
EAP-MSCHAPv2 Benutzer und Passwörter unter Pre-Shared Keys (Typ EAP) kleine Umgebungen, universell
EAP-RADIUS Benutzer werden per RADIUS geprüft Active Directory (z. B. über Microsoft NPS oder FreeRADIUS), Gruppensteuerung; MFA nur per Push-Verfahren (siehe unten)
EAP-TLS Client-Zertifikat je Gerät oder Benutzer verwaltete Geräte, keine Passwörter; Zertifikate unter System → Trust ausstellen und sperren
Public Key Zertifikat direkt im IKEv2-Austausch Geräte- bzw. strongSwan-Clients
Xauth PAM nur IKEv1 Altlösungen – für neue Installationen nicht verwenden

EAP-RADIUS einrichten

  1. RADIUS-Server unter System → Access → Servers anlegen (Typ Radius, Shared Secret, ausreichendes Timeout – bei Push-Bestätigungen z. B. 30 Sekunden).
  2. VPN → IPsec → Mobile & Advanced Settings: im RADIUS-Bereich den Server unter Servers auswählen; optional Accounting und Group selection (class_group) für Gruppenrechte.
  3. In der Connection unter Remote Authentication EAP RADIUS mit EAP Id %any wählen.
  4. Auf dem RADIUS-Server die OPNsense als Client eintragen und EAP-MSCHAPv2 (bzw. das vom Client genutzte EAP-Verfahren) zulassen.

So werden Benutzer zentral im Verzeichnis gepflegt, etwa über Microsoft NPS oder FreeRADIUS.


HinweisMFA mit EAP-RADIUS: Die Clients melden sich per EAP-MSCHAPv2 an, und die OPNsense reicht dieses Verfahren an den RADIUS-Server weiter. MSCHAPv2 ist ein Challenge-Response-Verfahren, das das Passwort nicht im Klartext überträgt – ein an das Passwort angehängtes Einmalpasswort (OTP), wie es z. B. privacyIDEA per RADIUS prüft, funktioniert damit nicht. Möglich ist ein zweiter Faktor nur, wenn der RADIUS-Server ihn außerhalb des Passworts abfragt, etwa per Push-Bestätigung auf dem Smartphone; das RADIUS-Timeout muss dafür ausreichend lang sein. Wer Einmalpasswörter einsetzen möchte, nutzt für das Client-VPN OpenVPN mit TOTP oder RADIUS oder für IPsec EAP-TLS mit Gerätezertifikaten.

EAP-TLS einrichten

Für jeden Benutzer bzw. jedes Gerät unter System → Trust → Certificates ein Client-Zertifikat der IPsec-CA ausstellen (als PKCS#12 mit Passwort exportieren). In der Connection Remote Authentication EAP TLS wählen und unter Certificate Authorities die IPsec-CA. Verlorene Geräte werden über die Sperrliste (System → Trust → Revocation) ausgeschlossen.

Clients einrichten

Plattform Einrichtung
Windows 10/11 CA in den Speicher Vertrauenswürdige Stammzertifizierungsstellen des Computers importieren. VPN-Verbindung „IKEv2“ mit Server vpn1.example.com, Anmeldung mit Benutzername/Passwort (EAP-MSCHAPv2). Die Standard-Algorithmen von Windows sind schwach – per PowerShell anpassen, z. B. Set-VpnConnectionIPsecConfiguration -ConnectionName "Firma" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup PFS2048 (passend zu aes256-sha256-modp2048). Rekey-Werte der Connection wie oben für Windows setzen.
macOS / iOS CA als Profil installieren und vertrauen; VPN-Typ IKEv2, Server und Entfernte ID vpn1.example.com, Benutzerauthentifizierung Benutzername. Für viele Geräte ein Konfigurationsprofil (MDM) verteilen.
Android eingebauter Typ IKEv2/IPSec MSCHAPv2 mit Server-Kennung vpn1.example.com und CA, oder die App strongSwan VPN Client (ausführliche Protokolle zur Fehlersuche).
Linux NetworkManager mit dem strongSwan-Plugin (EAP) oder direkt strongSwan/swanctl.

Status und Fehlersuche

  • VPN → IPsec → Status Overview – verbundene Benutzer und Tunnel; Lease Status – vergebene Pool-Adressen.
  • VPN → IPsec → Log File – Fehlermeldungen beim Verbindungsaufbau; für Details unter Mobile & Advanced Settings die Log Level einzelner Bereiche (z. B. IKE, Configuration) erhöhen.
Symptom Ursache und Lösung
Keine Pakete im Log WAN-Regel für UDP 500/4500 fehlt, falscher DNS-Eintrag oder Netz des Clients blockiert IPsec – mit tcpdump bzw. Interfaces → Diagnostics → Packet Capture prüfen. Bei der allerersten Connection Enable IPsec nicht vergessen.
no matching proposal Proposals von Client und Server passen nicht – Windows-Algorithmen per PowerShell setzen bzw. Proposal angleichen.
Zertifikatsfehler (z. B. Windows Fehler 13801) CA auf dem Client nicht vertrauenswürdig, falscher Speicher (Benutzer statt Computer) oder Name nicht im Subject Alternative Name des Server-Zertifikats.
Anmeldung schlägt fehl (EAP authentication failed) Benutzername/Passwort falsch, Typ des Schlüssels nicht EAP, RADIUS-Server antwortet nicht oder lehnt ab.
Verbunden, aber kein Zugriff Firewall-Regel auf der IPsec-Schnittstelle fehlt oder Local im Child enthält das Zielnetz nicht.
Full Tunnel ohne Internet Source-NAT-Regel für das Pool-Netz fehlt.
Interne Namen werden nicht aufgelöst DNS im Pool fehlt, Unbound-ACL für das Pool-Netz fehlt oder Client nutzt fremde (IPv6-)DNS-Server.
Verbindung bricht nach einiger Zeit ab Rekey-Einstellungen nicht auf den Client abgestimmt (Windows: 86400/0).

Sicherheitsempfehlungen

  • Starke Proposals (AES-256, SHA-256, DH-Gruppe 14 oder höher bzw. elliptische Kurven), default entfernen.
  • Bevorzugt EAP-TLS (Gerätezertifikate) oder EAP-RADIUS mit zentraler Benutzerverwaltung statt lokaler Passwörter; lokale EAP-Passwörter lang und zufällig wählen.
  • Zugriffsrechte auf der IPsec-Schnittstelle so eng wie möglich; mit Methode 2 bzw. RADIUS-Gruppen unterschiedliche Rechte pro Benutzergruppe.
  • Full Tunnel für unverwaltete Netze (Hotel, öffentliches WLAN).
  • Anmeldungen und Fehlversuche aus dem IPsec-Log an ein SIEM übertragen, z. B. mit dem Wazuh-Agent.
  • Im HA-Cluster die CARP-Adresse des WAN als Local address bzw. als DNS-Ziel verwenden – siehe OPNsense - Hochverfügbarkeit mit CARP und pfsync.

Fazit

IPsec IKEv2 ist auf OPNsense die naheliegende Wahl für Road Warrior, wenn keine zusätzliche Client-Software verteilt werden soll: Windows, macOS, iOS und Android verbinden sich mit Bordmitteln, MOBIKE sorgt für stabiles Roaming, mit EAP-RADIUS lässt sich Active Directory anbinden, und EAP-TLS sichert verwaltete Geräte ohne Passwörter ab. Für Einmalpasswörter ist OpenVPN die bessere Wahl. Entscheidend sind ein sauberes Server-Zertifikat, abgestimmte Proposals für die Clients, eine Connection mit Pool sowie Firewall-, NAT- und DNS-Einstellungen für das Pool-Netz.

Unterstützung von m.a.x. it

Sie möchten mobile Mitarbeitende per IPsec, OpenVPN oder WireGuard anbinden und dabei Active Directory und MFA integrieren? 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

Links und Quellen


Ü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? Kontakt aufnehmen

Abgerufen von „http://techcorner.max-it.de/index.php?title=OPNsense_-_IPsec_Road_Warrior_mit_IKEv2&oldid=4125“