OPNsense - Stunnel-Plugin

Auf einen Blick

Gilt für	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

Stunnel ist ein seit vielen Jahren etablierter Open-Source-Proxy, der beliebige TCP-Verbindungen in TLS einpackt. Er arbeitet in zwei Richtungen:

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

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

1. System → Firmware → Plugins öffnen, nach stunnel suchen und os-stunnel installieren.
2. 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 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:

Feld	Bedeutung
enabled	Tunnel aktivieren.
Listen address	Adresse, auf der Stunnel lauscht. Standard ist 127.0.0.1 – 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 (requireCert und verifyChain). 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 (192.168.10.25) 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.

Feld	Wert
Listen address / Listen port	127.0.0.1 / 995
Target hostname / Target port	192.168.10.25 / 110
Protocol	leer (POP3S = TLS ab dem ersten Byte)
Certificate	Let’s-Encrypt-Zertifikat für mail.example.com
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 127.0.0.1 Port 995 (mit zugehöriger Filterregel). In Outlook, Thunderbird oder auf dem Smartphone wird dann mail.example.com, 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).

HinweisStunnel 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. 192.168.10.1 / 110
• Target: pop.provider.de / 995, 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 192.168.10.1, 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 110 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).

Feld	Wert
Listen address / Listen port	192.168.30.1 (Firewall-IP im Geräte-VLAN) / 389
Target hostname / Target port	dc01.firma.local / 636
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 192.168.30.1, 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 389 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.

HinweisAuch 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 192.168.10.1:25 → Target smtp.provider.de:465 (SMTPS, Protocol leer) oder Target Port 587 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:

; 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

Die Datei client.pem enthält Zertifikat und privaten Schlüssel des Clients, ca.pem die interne CA. Mit dem ident-Dienst kann der Proxy die Verbindungen sogar dem Zertifikatsinhaber zuordnen.

Firewall-Regeln und NAT

Lauscht Stunnel auf …	Benötigte Regeln
127.0.0.1 (empfohlen für Zugriffe aus dem Internet)	Firewall → NAT → Destination NAT: Weiterleitung des externen Ports an 127.0.0.1 + 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 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 OpenVPN oder IPsec die richtige Wahl.

Fehlerbehebung

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 OPNsense-Firewall-Services von m.a.x. it sowie mit 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

• OPNsense-Doku – Stunnel
• stunnel – offizielles Handbuch
• Quellcode des Plugins os-stunnel
• 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? Kontakt aufnehmen