imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt

2026-10-08T00:00:00Z

Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt

Neue Seite

{{Steckbrief
| gilt_fuer = OPNsense 26.1/26.7 mit Plugin os-stunnel (Plugin-Version 1.0.6)
| bereich = IT-Security
| dauer = ca. 15 Minuten pro Tunnel
| rechte = Administrator (OPNsense-WebUI)
| stand = Oktober 2026
}}
Mit dem Plugin '''os-stunnel''' wird OPNsense zum '''TLS-Proxy''': Stunnel nimmt unverschlüsselte TCP-Verbindungen entgegen und leitet sie verschlüsselt weiter – oder umgekehrt. So lassen sich Protokolle wie '''POP3, LDAP, SMTP oder IMAP nachträglich mit TLS absichern''', ohne die beteiligten Programme oder Geräte zu verändern. Typische Einsatzfälle sind ältere Anwendungen, Multifunktionsdrucker, Maschinensteuerungen oder Fachsoftware, die nur Klartextprotokolle beherrschen, aber mit Servern sprechen müssen, die heute verschlüsselte Verbindungen verlangen.

Dieser Artikel erklärt die Funktionsweise des Plugins, seine Einstellungen und vier praktische Anwendungsfälle.

== Was ist Stunnel? TLS für Programme ohne TLS ==
[https://www.stunnel.org/ Stunnel] ist ein seit vielen Jahren etablierter Open-Source-Proxy, der beliebige TCP-Verbindungen in [[TLS]] einpackt. Er arbeitet in zwei Richtungen:

{| class="wikitable"
! Modus !! Stunnel nimmt an … !! … und leitet weiter als !! Typischer Zweck
|-
| '''Server-Modus''' (Standard) || TLS-Verbindungen von Clients || Klartext an den internen Dienst || Einem alten Server einen verschlüsselten Zugang voranstellen (z. B. POP3 → POP3S)
|-
| '''Client-Modus''' || Klartext-Verbindungen von internen Geräten || TLS an den Zielserver || Alten Clients Zugriff auf Server ermöglichen, die nur noch TLS akzeptieren (z. B. LDAP → LDAPS)
|}

Zusätzlich kann Stunnel '''STARTTLS''' aushandeln: Bei Protokollen wie POP3, IMAP, SMTP oder LDAP beginnt die Verbindung im Klartext auf dem Standardport und wird dann per Befehl auf TLS umgeschaltet. Stunnel übernimmt diesen Protokollschritt, wenn im Plugin das passende '''Protocol''' gewählt ist.

[[Datei:OPNsense-Stunnel-Anwendungsfaelle.png|thumb|center|750px|Stunnel auf OPNsense: Im Server-Modus erhält ein alter POP3-Server einen verschlüsselten POP3S-Zugang, im Client-Modus erreicht ein Altgerät per Klartext-LDAP den Domain Controller über LDAPS.]]

== Das Plugin os-stunnel in OPNsense ==
=== Installation ===
# '''System → Firmware → Plugins''' öffnen, nach ''stunnel'' suchen und '''os-stunnel''' installieren.
# Die Konfiguration befindet sich anschließend unter '''VPN → Stunnel → Configuration''', das Protokoll unter '''VPN → Stunnel → Log File'''.

=== Zertifikate vorbereiten ===
Jeder Tunnel benötigt ein Zertifikat aus '''System → Trust''':
* '''Öffentlich erreichbare Dienste''' (z. B. POP3S für Mail-Clients): ein Zertifikat einer öffentlichen CA, idealerweise automatisch per [[ACME]]/[[Let's Encrypt]] über das Plugin [[OPNsense - ACME-Client für Let's Encrypt-Zertifikate|os-acme-client]] bezogen. Mail-Programme vertrauen diesem Zertifikat ohne weitere Verteilung.
* '''Interne Tunnel und gegenseitige Authentifizierung''' ([[Mutual TLS]]): eine interne CA unter ''System → Trust → Authorities'' anlegen und daraus Server- und Client-Zertifikate ausstellen.
* '''Client-Modus mit Prüfung des Zielservers:''' die CA des Zielservers (z. B. die Root-CA der Microsoft-Zertifizierungsstelle oder die öffentliche Root-CA des Providers) unter ''System → Trust → Authorities'' importieren.

=== Die Einstellungen eines Tunnels ===
Unter '''VPN → Stunnel → Configuration''' wird im Reiter '''Services''' mit '''+''' ein neuer Tunnel angelegt:

{| class="wikitable"
! Feld !! Bedeutung
|-
| '''enabled''' || Tunnel aktivieren.
|-
| '''Listen address''' || Adresse, auf der Stunnel lauscht. Standard ist <code>127.0.0.1</code> – der sicherste Wert; Zugriffe werden dann per Destination NAT dorthin geleitet. Alternativ eine feste Schnittstellen-IP (z. B. die LAN-Adresse).
|-
| '''Listen port''' || Port, auf dem Verbindungen angenommen werden.
|-
| '''Target hostname''' / '''Target port''' || Ziel, an das Stunnel weiterleitet.
|-
| '''Protocol''' || Optional: STARTTLS-Aushandlung für '''IMAP, LDAP, NNTP, POP3''' oder '''SMTP'''. '''Leer lassen''', wenn TLS auf einem eigenen Port läuft (POP3S 995, IMAPS 993, SMTPS 465, LDAPS 636).
|-
| '''Certificate''' || Eigenes Zertifikat dieses Tunnels (Pflichtfeld). Im Server-Modus das Serverzertifikat, im Client-Modus das Zertifikat, mit dem sich Stunnel ggf. gegenüber dem Ziel ausweist.
|-
| '''CA to validate connections to''' || Ist eine CA gewählt, akzeptiert Stunnel nur Gegenstellen mit einem Zertifikat dieser CA (<code>requireCert</code> und <code>verifyChain</code>). Im Server-Modus heißt das: Clients '''müssen''' ein Client-Zertifikat vorlegen. Im Client-Modus wird das Zertifikat des Zielservers geprüft.
|-
| '''enable CRL''' || Sperrlisten prüfen. Fehlt eine gültige CRL, werden alle Verbindungen abgelehnt.
|-
| '''Client mode''' || Stunnel arbeitet als TLS-Client: Klartext annehmen, verschlüsselt weiterleiten.
|-
| '''Ciphers''' || Erlaubte Verschlüsselungsverfahren. Voreingestellt sind ausschließlich moderne AEAD-Verfahren (AES-GCM, ChaCha20-Poly1305) mit TLS 1.2 und 1.3; ältere TLS-Versionen sind fest ausgeschlossen.
|-
| '''Description''' || Sprechende Beschreibung, z. B. ''POP3S für Altserver''.
|}

Im Reiter '''General''' (ebenfalls unter ''VPN → Stunnel → Configuration'') gibt es zwei globale Optionen:
* '''chroot service''' – Stunnel in einer abgeschotteten Umgebung starten. Sicherer, aber nach einem Neustart des Syslog-Dienstes gehen Stunnel-Logmeldungen verloren, bis Stunnel neu gestartet wird.
* '''enable ident protocol''' – ein Ident-Dienst (RFC 1413, Port 113), über den z. B. ein Proxy erfährt, welcher Zertifikatsinhaber (CN) hinter einer Stunnel-Verbindung steckt.

== Anwendungsfall 1: POP3 verschlüsseln – POP3S für einen alten Mailserver ==
'''Ausgangslage:''' Ein älterer interner Mailserver bzw. eine Branchenlösung (<code>192.168.10.25</code>) stellt Postfächer nur per unverschlüsseltem '''POP3 (Port 110)''' bereit. Mitarbeitende sollen ihre Mails auch von unterwegs abrufen – aber Passwörter dürfen keinesfalls im Klartext über das Internet laufen.

'''Lösung:''' Stunnel im '''Server-Modus''' bietet nach außen '''POP3S auf Port 995''' an und leitet intern Klartext-POP3 an den Mailserver weiter.

{| class="wikitable"
! Feld !! Wert
|-
| Listen address / Listen port || <code>127.0.0.1</code> / <code>995</code>
|-
| Target hostname / Target port || <code>192.168.10.25</code> / <code>110</code>
|-
| Protocol || ''leer'' (POP3S = TLS ab dem ersten Byte)
|-
| Certificate || Let’s-Encrypt-Zertifikat für <code>mail.example.com</code>
|-
| CA to validate connections to || ''leer'' (Mail-Clients legen kein Client-Zertifikat vor)
|-
| Client mode || aus
|}

Anschließend unter '''Firewall → NAT → Destination NAT''' eine Regel anlegen: Interface ''WAN'', Protokoll ''TCP'', Ziel ''WAN address'', Port ''995'', Weiterleitung an <code>127.0.0.1</code> Port <code>995</code> (mit zugehöriger Filterregel). In Outlook, Thunderbird oder auf dem Smartphone wird dann <code>mail.example.com</code>, Port 995, ''SSL/TLS'' eingetragen.

Der direkte Zugriff auf Port 110 von außen bleibt gesperrt. Dasselbe Prinzip funktioniert für '''IMAP → IMAPS (993)''' und '''SMTP-Submission → SMTPS (465)'''.

{{Hinweis|Stunnel schützt nur die Strecke zwischen Client und Firewall. Zwischen Firewall und Mailserver läuft weiterhin Klartext – dieser Abschnitt sollte daher in einem vertrauenswürdigen Netzsegment liegen. Mittelfristig gehört ein Mailserver, der kein TLS beherrscht, ersetzt; Stunnel ist eine saubere Brücke bis dahin.}}

=== Variante: POP3-Abruf eines Altgeräts beim Provider ===
Umgekehrt kommt es oft vor, dass ein '''Gerät oder eine Fachanwendung im LAN''' Mails per POP3 bei einem externen Provider abholen muss, dieser aber nur noch '''POP3S (995)''' anbietet. Dann arbeitet Stunnel im '''Client-Modus''':
* '''Listen address/port:''' LAN-Adresse der Firewall, z. B. <code>192.168.10.1</code> / <code>110</code>
* '''Target:''' <code>pop.provider.de</code> / <code>995</code>, '''Client mode''' aktiv, '''Protocol''' leer
* '''CA to validate connections to:''' die öffentliche Root-CA des Providers (importiert unter ''System → Trust'')
* Im Gerät als POP3-Server <code>192.168.10.1</code>, Port 110, ohne Verschlüsselung eintragen und unter ''Firewall → Rules'' auf dem LAN-Interface nur diesem Gerät den Zugriff auf Port 110 der Firewall erlauben.
Bietet der Provider stattdessen POP3 mit STARTTLS auf Port 110 an, als Ziel Port <code>110</code> und als '''Protocol''' ''POP3'' wählen.

== Anwendungsfall 2: LDAP verschlüsseln – Altgeräte an Active Directory anbinden ==
'''Ausgangslage:''' Multifunktionsdrucker (Adressbuch, Scan-to-Mail-Anmeldung), ältere NAS-Systeme, Telefonanlagen oder Eigenentwicklungen fragen Benutzer per '''LDAP auf Port 389 im Klartext''' beim [[Active Directory]] ab – inklusive Passwort bei der Anmeldung (''Simple Bind''). Das ist doppelt problematisch: Passwörter lassen sich im Netz mitlesen, und aktuelle Domain Controller lehnen unsignierte Klartext-Anmeldungen zunehmend ab (LDAP-Signing und Channel Binding, bei neuen Windows-Server-Versionen standardmäßig verschärft). LDAPS beherrschen viele dieser Geräte nicht oder nur mit veralteten TLS-Versionen.

'''Lösung:''' Stunnel im '''Client-Modus''' nimmt die Klartext-LDAP-Anfragen der Geräte entgegen und spricht mit dem Domain Controller ausschließlich '''LDAPS (Port 636)'''.

{| class="wikitable"
! Feld !! Wert
|-
| Listen address / Listen port || <code>192.168.30.1</code> (Firewall-IP im Geräte-VLAN) / <code>389</code>
|-
| Target hostname / Target port || <code>dc01.firma.local</code> / <code>636</code>
|-
| Protocol || ''leer'' (LDAPS = TLS auf eigenem Port)
|-
| Certificate || internes Zertifikat der Firewall
|-
| CA to validate connections to || Root-CA der Microsoft-Zertifizierungsstelle (AD CS), zuvor unter ''System → Trust → Authorities'' importiert
|-
| Client mode || '''aktiv'''
|}

Im Gerät wird als LDAP-Server die Firewall-Adresse <code>192.168.30.1</code>, Port 389, ohne Verschlüsselung eingetragen. Unter '''Firewall → Rules''' auf dem Geräte-Interface nur den betroffenen Geräten den Zugriff auf TCP 389 der Firewall erlauben.

'''Alternativen je nach Domain Controller:'''
* Spricht der DC '''STARTTLS auf Port 389''' statt LDAPS, als Ziel Port <code>389</code> und als '''Protocol''' ''LDAP'' wählen.
* Für Redundanz einen zweiten Tunnel (anderer Port) zu einem zweiten Domain Controller anlegen, sofern das Gerät einen Ausweichserver unterstützt.

{{Hinweis|Auch hier läuft der Abschnitt zwischen Gerät und Firewall weiterhin im Klartext. Geräte daher in ein eigenes VLAN legen, den Tunnel nur dort anbieten und für die Anbindung ein '''eigenes Dienstkonto mit minimalen Leserechten''' verwenden – nie ein Administratorkonto.}}

== Anwendungsfall 3: Mailversand von Altgeräten (SMTP) ==
Scanner, USV-Systeme oder Überwachungssoftware versenden Benachrichtigungen oft nur per '''SMTP ohne TLS'''. Moderne Mailanbieter und [[Microsoft 365]]-Konnektoren nehmen solche Mails nicht mehr an.
* Stunnel im '''Client-Modus''': Listen <code>192.168.10.1:25</code> → Target <code>smtp.provider.de:465</code> (SMTPS, Protocol leer) '''oder''' Target Port <code>587</code> mit '''Protocol''' ''SMTP'' (STARTTLS).
* Die SMTP-Anmeldung (Benutzername/Passwort) konfiguriert weiterhin das Gerät – sie läuft dann geschützt durch den Tunnel.

== Anwendungsfall 4: Interne Dienste mit Mutual TLS veröffentlichen ==
Soll ein interner TCP-Dienst ausschließlich für bestimmte '''Systeme oder Standorte''' erreichbar sein, sichert Stunnel im Server-Modus mit gesetzter '''CA to validate connections to''' ihn per '''gegenseitiger Zertifikatsprüfung''' ab: Nur Gegenstellen mit einem Client-Zertifikat der internen CA können überhaupt eine Verbindung aufbauen. Das klassische Beispiel aus der OPNsense-Dokumentation ist ein '''HTTP-Proxy''' (Squid, Port 3128), den Außendienstmitarbeitende über einen Stunnel-Client auf ihrem Notebook nutzen:
<syntaxhighlight lang="ini">
; stunnel.conf auf dem Client-Rechner
[proxy]
client = yes
accept = 127.0.0.1:3128
connect = firewall.example.com:31280
requireCert = yes
verifyChain = yes
cert = C:\stunnel\client.pem
CAfile = C:\stunnel\ca.pem
</syntaxhighlight>
Die Datei <code>client.pem</code> enthält Zertifikat und privaten Schlüssel des Clients, <code>ca.pem</code> die interne CA. Mit dem ''ident''-Dienst kann der Proxy die Verbindungen sogar dem Zertifikatsinhaber zuordnen.

== Firewall-Regeln und NAT ==
{| class="wikitable"
! Lauscht Stunnel auf … !! Benötigte Regeln
|-
| <code>127.0.0.1</code> (empfohlen für Zugriffe aus dem Internet) || '''Firewall → NAT → Destination NAT''': Weiterleitung des externen Ports an <code>127.0.0.1</code> + zugehörige Filterregel
|-
| einer LAN-/VLAN-Adresse der Firewall || '''Firewall → Rules''' auf diesem Interface: Zugriff der berechtigten Quellen auf den Listen-Port der Firewall
|-
| Ausgehende Verbindungen (Client-Modus) || Verkehr der Firewall selbst ist standardmäßig erlaubt; ggf. Ziel auf vorgeschalteten Firewalls freigeben
|}
Bei Listen-Ports unter 1024 auf einer Schnittstellen-IP darauf achten, dass kein anderer Dienst der Firewall (z. B. ein Mail- oder LDAP-Plugin) denselben Port belegt.

== Grenzen von Stunnel und Sicherheitshinweise ==
* '''Nur TCP:''' UDP-Protokolle (z. B. Syslog über UDP, RADIUS, SNMP) lassen sich nicht tunneln.
* '''Ein Port pro Dienst:''' Protokolle mit dynamischen Zusatzverbindungen wie FTP funktionieren nicht.
* '''Keine Hostnamen-Prüfung im Plugin:''' Im Client-Modus prüft das Plugin die Zertifikatskette gegen die gewählte CA, nicht aber, ob der Name im Zertifikat zum Zielhost passt. Deshalb möglichst eine '''spezifische''' CA (z. B. die eigene AD-CS-Root-CA) statt einer großen öffentlichen CA auswählen und das Ziel per fester IP oder internem DNS ansprechen.
* '''Klartext-Abschnitt bleibt:''' Zwischen Altgerät/Altserver und Firewall wird nicht verschlüsselt – Segmentierung und restriktive Regeln sind Pflicht.
* '''Zertifikate erneuern:''' Bei Let’s Encrypt übernimmt ''os-acme-client'' die Verlängerung; Stunnel nach einer Erneuerung ggf. neu starten (''VPN → Stunnel'' bzw. Dienste-Widget).
* '''Logs prüfen:''' Fehlgeschlagene Handshakes erscheinen unter ''VPN → Stunnel → Log File'' und lassen sich an ein SIEM weiterleiten, z. B. ein [https://www.max-it.de/it-services/siem-open-source/ Open-Source-SIEM auf Wazuh-Basis].
* '''Alternativen:''' Für HTTP(S)-Dienste mit mehreren Domains, Lastverteilung oder Weiterleitung nach Hostname (SNI) ist ein [[Reverse Proxy]] wie das HAProxy-Plugin (siehe [[OPNsense - HAProxy mit Passwortauthentifizierung]]) besser geeignet. Für vollständige Netzverbindungen sind VPNs wie [[OPNsense - OpenVPN Site-to-Site und Client-VPN|OpenVPN]] oder [[OPNsense - IPsec Site-to-Site route-based|IPsec]] die richtige Wahl.

== Fehlerbehebung ==
{| class="wikitable"
! Symptom !! Ursache und Lösung
|-
| Verbindung wird sofort geschlossen || Server-Modus mit gesetzter CA: Client legt kein Zertifikat vor – CA-Feld leeren, wenn kein Mutual TLS gewünscht ist.
|-
| ''certificate verify failed'' im Log || Client-Modus: falsche oder fehlende CA für den Zielserver; Zwischenzertifikate fehlen.
|-
| ''wrong version number'' / ''unknown protocol'' || STARTTLS und separater TLS-Port verwechselt: Protocol nur bei STARTTLS setzen, bei 995/993/465/636 leer lassen.
|-
| Alle Verbindungen abgelehnt nach Aktivieren von CRL || Keine gültige Sperrliste vorhanden – CRL für die CA erzeugen oder Option deaktivieren.
|-
| Keine Logmeldungen mehr || ''chroot service'' aktiv und Syslog wurde neu gestartet – Stunnel neu starten.
|-
| Altgerät verbindet sich nicht || Listen-Adresse/Port oder Firewall-Regel auf dem Geräte-Interface prüfen; manche Geräte erwarten zwingend den Standardport.
|}

== Fazit ==
Das Stunnel-Plugin ist ein kleines, aber sehr nützliches Werkzeug im OPNsense-Baukasten: Mit wenigen Klicks erhalten alte Server einen verschlüsselten Zugang, und Altgeräte, die nur Klartext-POP3, -LDAP oder -SMTP beherrschen, können weiter mit modernen, TLS-pflichtigen Servern arbeiten. Wichtig ist, Stunnel als das zu sehen, was es ist – eine Brücke: Der Klartext-Abschnitt gehört in ein abgeschottetes Segment, und mittelfristig sollten die Altsysteme modernisiert werden.

== Unterstützung von m.a.x. it ==
Sie möchten Altgeräte sicher an Active Directory oder Mailserver anbinden, Klartextprotokolle in Ihrem Netz aufspüren und absichern oder Ihre OPNsense um TLS-Proxy-Funktionen erweitern? m.a.x. it unterstützt Sie als OPNsense-Gold-Partner mit [https://www.max-it.de/it-services/opnsense/ OPNsense-Firewall-Services von m.a.x. it] sowie mit [https://www.max-it.de/it-services/cybersecurity/ Cybersecurity-Leistungen von m.a.x. it].

== Siehe auch ==
* [[OPNsense - ACME-Client für Let's Encrypt-Zertifikate]]
* [[OPNsense - Plugin-Liste]]
* [[OPNsense - HAProxy mit Passwortauthentifizierung]]
* [[OPNsense - OpenVPN Site-to-Site und Client-VPN]]
* [[TLS]]
* [[Mutual TLS]]
* [[LDAP]]
* [[POP3]]
* [[IMAP]]
* [[SMTP]]
* [[Let's Encrypt]]

== Links und Quellen ==
* [https://docs.opnsense.org/manual/how-tos/stunnel.html OPNsense-Doku – Stunnel]
* [https://www.stunnel.org/manual.html stunnel – offizielles Handbuch]
* [https://github.com/opnsense/plugins/tree/master/security/stunnel Quellcode des Plugins os-stunnel]
* [https://www.max-it.de/it-services/opnsense/ m.a.x. it – OPNsense-Firewall-Services]

{{Uebermax}}
[[Kategorie:IT-Security]]

OPNsense - Stunnel-Plugin - Versionsgeschichte

imported>TechCorner-Redaktion: Verlinkung auf den Artikel OPNsense - ACME-Client für Let's Encrypt-Zertifikate ergänzt