OPNsense - Tinc Mesh-VPN
Auf einen Blick
| Gilt für | OPNsense 26.1/26.7 mit Plugin os-tinc 1.8 (tinc 1.0.37) |
|---|---|
| Bereich | IT-Security |
| Dauer | ca. 30 Minuten für zwei Standorte, je weiterem Standort ca. 10 Minuten |
| Rechte | Administrator (OPNsense-WebUI) auf allen beteiligten Firewalls |
| Stand | Oktober 2026 |
tinc ist ein seit vielen Jahren bewährtes Open-Source-VPN, das mehrere Standorte zu einem vermaschten Netz (Mesh) verbindet: Jeder Knoten kennt die anderen, Verbindungen werden automatisch aufgebaut, und fällt ein Knoten aus, findet tinc selbstständig andere Wege. Neben gerouteten Netzen (Layer 3) beherrscht tinc auch einen Switch-Modus (Layer 2), der entfernte Standorte wie an einem gemeinsamen Ethernet-Switch verbindet. Mit dem Plugin os-tinc lässt sich tinc direkt auf der OPNsense betreiben.
Wie tinc funktioniert
- Dezentral: Es gibt keinen zentralen Server. Jeder Knoten hat ein Schlüsselpaar; die öffentlichen Schlüssel der Partner werden als Hosts hinterlegt.
- Meta-Verbindungen und Datenverkehr: Knoten bauen TCP-Verbindungen (Standardport 655) für den Austausch von Routing-Informationen auf. Nutzdaten werden möglichst direkt per UDP (ebenfalls Port 655) zwischen den beteiligten Knoten übertragen – auch wenn diese nicht direkt miteinander „verbunden“ wurden.
- Automatisches Mesh: Es genügt, wenn jeder Knoten zu einem oder zwei anderen eine Verbindung herstellt (Connect To); tinc lernt die übrigen Knoten und Netze automatisch.
- Modi: Im Router-Modus (Standard) gibt jeder Knoten an, welche Subnetze hinter ihm liegen. Im Switch-Modus arbeitet tinc wie ein virtueller Ethernet-Switch (Layer 2, inklusive Broadcast).

Beispiel-Szenario
| Knoten (Hostname) | Öffentliche Adresse | Tinc-Netzadresse | Lokales LAN |
|---|---|---|---|
zentrale |
vpn.example.com |
10.99.0.1 |
192.168.10.0/24
|
filiale1 |
dynamisch | 10.99.0.2 |
192.168.20.0/24
|
filiale2 |
203.0.113.50 |
10.99.0.3 |
192.168.30.0/24
|
Netzname: firmennetz, Tinc-Netz: 10.99.0.0/24 (Router-Modus).
Schritt 1: Plugin installieren
Auf allen Firewalls System → Firmware → Plugins: os-tinc installieren und die Seite neu laden. Die Konfiguration befindet sich unter VPN → Tinc → Configuration, das Protokoll unter VPN → Tinc → Log File.
Schritt 2: Netzwerk auf jedem Knoten anlegen
VPN → Tinc → Configuration, Reiter Networks → + (Beispiel Zentrale):
| Feld | Wert | Hinweis |
|---|---|---|
| Enabled | an | |
| Mode | router | switch für Layer 2 |
| Network Name | firmennetz |
auf allen Knoten identisch, nur Buchstaben/Ziffern |
| Network | 10.99.0.1/24 |
eigene Tinc-Adresse + Maske des gesamten Tinc-Netzes |
| PingTimeout | 5 (Standard) | |
| StrictSubnets | nach Bedarf | nur Subnetze aus den lokal hinterlegten Host-Einträgen akzeptieren – empfehlenswert, damit kein Knoten fremde Netze „beanspruchen“ kann |
| Cipher | aes-256-cbc (Standard) |
auf allen Knoten gleich; niemals none |
| path MTU Discovery | an | vermeidet Fragmentierungsprobleme |
| Hostname (This Host) | zentrale |
eindeutiger Name dieses Knotens |
| Ext. Address / Ext. Port | vpn.example.com / 655 |
öffentliche Adresse; bei dynamischer IP DNS-Name verwenden oder leer lassen, wenn der Knoten nur selbst verbindet |
| Subnet | 192.168.10.0/24, 10.99.0.1/32 |
Netze hinter diesem Knoten plus eigene Tinc-Adresse (im Router-Modus Pflicht) |
| Private key / Public key | leer | beim Speichern werden Schlüssel erzeugt |
Nach dem Speichern den erzeugten Public key kopieren – er wird auf den anderen Knoten benötigt. Auf den Filialen entsprechend mit eigener Adresse, eigenem Hostnamen und eigenem Subnetz verfahren.
Schritt 3: Partner (Hosts) eintragen
Reiter Hosts → + – auf jedem Knoten für jeden anderen Knoten einen Eintrag (Beispiel auf der Zentrale für Filiale 2):
| Feld | Wert |
|---|---|
| Network | firmennetz |
| Hostname | filiale2 (exakt wie dort konfiguriert)
|
| Ext. Address / Ext. Port | 203.0.113.50 / 655 (leer bei dynamischer IP)
|
| Subnet | 192.168.30.0/24 und dessen Tinc-Adresse 10.99.0.3/32
|
| Public key | öffentlicher Schlüssel von Filiale 2 |
| Cipher | identisch zum Netzwerk |
| Connect To | auf Knoten mit dynamischer IP aktivieren, um aktiv zu Knoten mit fester Adresse zu verbinden |
Faustregel: Knoten mit dynamischer IP verbinden sich aktiv (Connect To) zu den Knoten mit fester Adresse. Es reicht, wenn jeder Knoten mindestens eine erfolgreiche Verbindung hat; mit zwei Verbindungen pro Knoten bleibt das Mesh auch beim Ausfall eines Partners zusammen. Apply auf allen Knoten.
Schritt 4: Firewall-Regeln und Interface
- WAN (Firewall → Rules, Interface WAN): TCP und UDP 655 auf This Firewall erlauben – idealerweise mit den bekannten Partneradressen als Quelle; bei dynamischen Partnern von any.
- Tunnelverkehr: Das Plugin legt pro Netzwerk ein Gerät
tincIDan (z. B.tinc1). Unter Interfaces → Assignments zuweisen (Beschreibung z. B. TINC), aktivieren, ohne IP-Konfiguration, und unter Firewall → Rules auf diesem Interface den gewünschten Verkehr zwischen den Standorten erlauben (z. B. Quelle192.168.20.0/24→ Ziel192.168.10.0/24). - Routen: tinc setzt die Routen für die Subnetze der Partner automatisch. Mit Disable subnet routes lässt sich das abschalten, z. B. für eigene Routing-Entscheidungen über Gateways und Policy-Based Routing.
Schritt 5: Testen
- VPN → Tinc → Log File zeigt Verbindungsaufbau (Connection with … activated) und Fehler; für Details unter Debug die Stufe erhöhen.
- Von einem Client in Filiale 1 einen Server in der Zentrale anpingen; anschließend Filiale 1 → Filiale 2 testen – auch ohne direkt konfigurierte Verbindung sollte der Verkehr fließen.
Layer-2-Modus (Switch)
Im Modus switch verhält sich tinc wie ein verteilter Ethernet-Switch: Statt Subnetze anzugeben, wird das Tinc-Interface z. B. per Bridge (Interfaces → Devices → Bridge) mit einem LAN- oder VLAN-Interface verbunden. Damit lassen sich Broadcast-abhängige Anwendungen, Altsysteme oder ein gemeinsames VLAN über Standorte hinweg betreiben. Nachteile: Broadcast- und Multicast-Verkehr läuft über alle Standorte, und Fehler wirken sich auf das gesamte Netz aus – Layer-2-Kopplungen daher sparsam einsetzen. Eine Alternative für virtuelles Ethernet ist ZeroTier.
tinc im Vergleich
| Kriterium | tinc (os-tinc) | IPsec route-based | WireGuard (OPNsense-Kern) | NetBird |
|---|---|---|---|---|
| Topologie | automatisches Mesh | Punkt-zu-Punkt-Tunnel | Punkt-zu-Punkt / Hub | automatisches Mesh |
| Layer 2 möglich | ja (switch) | nein | nein | nein |
| Zentrale Steuerung | keine | keine | keine | Management-Server mit SSO |
| Kryptografie | tinc 1.0: RSA, AES-CBC + HMAC | IKEv2, AES-GCM | Curve25519, ChaCha20-Poly1305 | WireGuard |
| Weiterentwicklung | 1.0 auslaufend, 1.1 Vorabversion | aktiv | aktiv | aktiv |
Sicherheitsempfehlungen
- Cipher auf allen Knoten auf
aes-256-cbc(oder ein anderes starkes Verfahren) setzen – nie none. - StrictSubnets aktivieren, damit nur die lokal hinterlegten Netze akzeptiert werden.
- Private Schlüssel nur auf dem jeweiligen Knoten belassen; bei Verdacht auf Kompromittierung neue Schlüssel erzeugen und auf allen Partnern aktualisieren.
- Firewall-Regeln auf dem Tinc-Interface gezielt setzen – ein Mesh verbindet sonst schnell „jeden mit jedem“.
- Bestehende tinc-Netze mittelfristig migrieren, z. B. auf IPsec route-based oder WireGuard; Logs zentral auswerten, etwa in einem Open-Source-SIEM auf Wazuh-Basis.
Typische Probleme
| Symptom | Lösung |
|---|---|
| Peer … had unknown identity / Verbindung wird abgelehnt | Hostname oder Public key im Host-Eintrag stimmt nicht mit dem Partner überein. |
| Meta-Verbindung steht, aber kein Datenverkehr | UDP 655 blockiert (WAN-Regel oder vorgeschalteter Router); Cipher unterschiedlich; Firewall-Regel auf dem Tinc-Interface fehlt. |
| Netze eines Standorts nicht erreichbar | Subnet beim Knoten bzw. im Host-Eintrag fehlt; mit StrictSubnets muss das Subnetz lokal im Host-Eintrag stehen. |
| Große Übertragungen hängen | path MTU Discovery aktivieren, MSS-Clamping über Firewall → Settings → Normalization. |
| Dienst startet nicht | Netzwerkname mit Sonderzeichen; Pflichtfeld Subnet im Router-Modus leer. |
Fazit
tinc ist ein elegantes, dezentrales Mesh-VPN, das auf der OPNsense mit wenigen Einträgen mehrere Standorte automatisch vernetzt – inklusive optionalem Layer-2-Betrieb. Für bestehende Installationen und Spezialfälle bleibt es nützlich; da der 1.0-Zweig ausläuft und die Kryptografie nicht mehr dem neuesten Stand entspricht, sollten neue Standortvernetzungen jedoch auf IPsec, WireGuard oder ein modernes Overlay wie NetBird setzen.
Unterstützung von m.a.x. it
Sie betreiben ein tinc-Netz und möchten es modernisieren, oder suchen das passende VPN-Konzept für mehrere Standorte? 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 - IPsec Site-to-Site route-based
- OPNsense - OpenVPN Site-to-Site und Client-VPN
- OPNsense - NetBird-Plugin
- ZeroTier – virtuelle Netzwerke mit Layer-2-Overlay
- Tailscale – Mesh-VPN auf WireGuard-Basis
- VPN
- WireGuard
Links und Quellen
- tinc – Projektseite und Dokumentation
- tinc – Versionshinweise
- Quellcode des Plugins os-tinc
- 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?
