OPNsense - Tailscale-Plugin

Aus maxTechCorner

Auf einen Blick

Gilt fürOPNsense 26.7 mit Plugin os-tailscale 1.4 (Tailscale-Client aus den FreeBSD-Paketen); Tailscale (alle Tarife) oder Headscale als Steuerserver
BereichIT-Security
Dauerca. 20 Minuten (Anmeldung und Subnet Router); Site-to-Site zwischen zwei Standorten ca. 45 Minuten
RechteOPNsense-Administrator, Admin- oder Network-Admin-Rolle in der Tailscale-Konsole
StandOktober 2026

Tailscale auf der OPNsense einzurichten macht die Firewall zum Teil des eigenen Tailnets: Über das Plugin os-tailscale stellt sie das Firmen-LAN als Subnet Router bereit, verbindet Standorte ohne klassisches Site-to-Site-VPN und dient bei Bedarf als Exit Node für den Internetverkehr mobiler Mitarbeiter. Diese Anleitung zeigt Anmeldung, alle Einstellungen, Firewall- und NAT-Regeln für direkte Verbindungen, Standortkopplung, Hochverfügbarkeit im CARP-Cluster und die Fehlersuche. Grundlagen zu Tailscale selbst, Tarifen und Richtlinien erklärt der Artikel Tailscale – Mesh-VPN auf WireGuard-Basis.

OPNsense mit Tailscale-Plugin: Die Firewall meldet sich mit einem Auth Key am Tailnet an und bietet das LAN als Subnet Router an, die Route wird in der Tailscale-Konsole freigegeben. Eine Source-NAT-Regel mit statischem Port für UDP 41641 ermöglicht direkte Verbindungen statt DERP-Relay. Site-to-Site: zwei OPNsense bieten ihre Netze an und übernehmen die Routen der Gegenseite. Im CARP-Cluster melden sich beide Knoten getrennt an und bieten dieselben Netze an – Tailscale schaltet bei Ausfall automatisch um.

Wofür Tailscale auf der OPNsense?

  • Fernzugriff ins Firmen-LAN ohne VPN-Server: Mitarbeiter mit Tailscale-App erreichen freigegebene Server, Drucker oder Altgeräte hinter der Firewall.
  • Standortvernetzung: Zwei oder mehr OPNsense-Firewalls bieten ihre Netze gegenseitig an – auch hinter CGNAT oder ohne feste IP-Adresse.
  • Exit Node: Internetverkehr von Notebooks im Hotel- oder Gäste-WLAN läuft über die Firmenleitung mit Webfilter und IDS/IPS.
  • Administrativer Zugriff auf die Firewall selbst über das Tailnet statt über eine offene WAN-Freigabe.

So arbeitet das Plugin auf FreeBSD

  • Das Plugin installiert den offiziellen Tailscale-Client aus den FreeBSD-Paketen und ergänzt eine Weboberfläche unter VPN → Tailscale mit den Seiten Authentication, Settings und Status sowie ein Dashboard-Widget.
  • Die Anmeldedaten liegen in /var/db/tailscale/tailscaled.state. Ein einmal angemeldetes Gerät verwendet den Auth Key nicht erneut.
  • Auf FreeBSD gibt es kein WireGuard im Kernel für Tailscale; verschlüsselt wird im Userspace. Weitergeleiteter Verkehr in die angebotenen Netze läuft standardmäßig über den internen Netzwerkstack von Tailscale: Die Firewall nimmt die Verbindung aus dem Tailnet an und baut eine neue Verbindung mit ihrer eigenen LAN-Adresse zum Ziel auf (wirkt wie Source NAT).
  • Mit der Option Disable SNAT routet die Firewall stattdessen über das Betriebssystem; Server im LAN sehen dann die echten Tailscale-Adressen (100.64.0.0/10). Die Option ist als experimentell gekennzeichnet.

Schritt 1: Auth Key und Tag vorbereiten

  1. In der Tailscale-Richtlinie einen Tag für Firewalls festlegen, z. B. "tagOwners": {"tag:opnsense": ["group:admins"]}.
  2. In der Admin-Konsole unter Settings → Keys mit Generate auth key einen Schlüssel erzeugen: nicht wiederverwendbar (Reusable aus), nicht flüchtig (Ephemeral aus), mit Tag tag:opnsense.
  3. Geräte mit Tag sind keinem Benutzer zugeordnet; ihr Schlüssel läuft nicht ab, wenn der Mitarbeiter, der sie eingerichtet hat, das Unternehmen verlässt.

Schritt 2: Plugin installieren und anmelden

  1. System → Firmware → Plugins: os-tailscale installieren und die Seite neu laden.
  2. VPN → Tailscale → Authentication: Login Server auf dem Standard https://controlplane.tailscale.com lassen (für Headscale die eigene URL eintragen) und den Auth Key unter Pre-authentication Key einfügen. Ohne Key zeigt die Statusseite stattdessen einen Anmeldelink.
  3. VPN → Tailscale → Settings: Enabled aktivieren, Accept DNS deaktivieren (siehe unten) und speichern.
  4. VPN → Tailscale → Status: Die Firewall muss als verbunden erscheinen und die anderen Geräte des Tailnets anzeigen. In der Admin-Konsole erscheint sie unter Machines.
  5. Den Auth Key anschließend unter Authentication wieder entfernen – er wird nicht mehr benötigt.

Schritt 3: Die Einstellungen im Überblick

Einstellung Standard Empfehlung
Enabled aus einschalten
Login timeout 10 s beibehalten; begrenzt die Wartezeit beim Booten, wenn der Steuerserver nicht erreichbar ist (verhindert, dass die Firewall hängt)
Listen Port 41641 (UDP) beibehalten; wird für die NAT-Regel in Schritt 5 benötigt
Accept DNS ein auf der Firewall ausschalten – sonst übernimmt sie MagicDNS und kann die eigene Namensauflösung (Unbound) stören
Advertise Exit Node aus nur einschalten, wenn die Firewall Exit Node sein soll
Accept Subnet Routes aus für Site-to-Site einschalten, damit die Netze der Gegenseite erreichbar sind
Enable SSH aus aus lassen; Administration besser über die reguläre SSH- bzw. Weboberfläche
Disable SNAT aus nur bei Bedarf (echte Absenderadressen, Firewall-Regeln auf weitergeleitetem Verkehr); experimentell
Subnets leer Netze, die die Firewall anbietet, z. B. 192.168.10.0/24 (IPv4 und IPv6 möglich)

Schritt 4: Interface zuweisen und Zugriffe regeln

  1. Interfaces → Assignments: das Gerät tailscale0 als neue Schnittstelle hinzufügen, z. B. mit der Beschreibung TAILSCALE, und aktivieren (ohne IP-Konfiguration).
  2. Firewall → Rules (Schnittstelle TAILSCALE): Regeln für Verkehr aus dem Tailnet anlegen, z. B. Zugriff von 100.64.0.0/10 auf die Weboberfläche der Firewall nur für Administratoren.
  3. Zugriffe primär in der Tailscale-Richtlinie steuern: Im Standardmodus baut die Firewall Verbindungen ins LAN selbst auf; Regeln auf der Tailscale-Schnittstelle greifen für diesen weitergeleiteten Verkehr nicht zuverlässig. Wer zusätzlich auf der OPNsense filtern möchte, aktiviert Disable SNAT und prüft das Verhalten im Live-Log unter Firewall → Log Files → Live View.

Beispiel für Grants, die Administratoren alles und Mitarbeitern nur HTTPS auf das Intranet im angebotenen Netz erlauben: 

"grants": [
  { "src": ["group:admins"],     "dst": ["192.168.10.0/24"],  "ip": ["*"] },
  { "src": ["autogroup:member"], "dst": ["192.168.10.20/32"], "ip": ["tcp:443"] }
]

Schritt 5: Direkte Verbindungen ermöglichen (Source NAT mit statischem Port)

OPNsense ändert bei ausgehendem Verkehr standardmäßig den Quellport. Das erschwert das NAT-Traversal, und Verbindungen laufen dann über die DERP-Relays von Tailscale – langsamer und mit höherer Latenz.

  1. Firewall → NAT → Source NAT: in den Modus Hybrid wechseln.
  2. Neue Regel: Schnittstelle WAN, Protokoll UDP, Quelle This Firewall, Quellport 41641, Übersetzung auf die WAN-Adresse, Static port aktivieren. Regel ganz oben einsortieren und anwenden.
  3. Optional unter Firewall → Rules (WAN) eingehend UDP 41641 auf This Firewall erlauben – das erhöht die Chance auf Direktverbindungen weiter.
  4. Prüfen in der Shell der Firewall (per SSH oder Konsole, Option 8): tailscale ping <gerät> meldet „via <IP>:<Port>“ für eine Direktverbindung und „via DERP(…)“ für eine Relay-Verbindung. tailscale netcheck zeigt, ob UDP funktioniert und welches NAT vorliegt.

Subnet Router: das Firmen-LAN freigeben

  1. Unter VPN → Tailscale → Settings bei Subnets das LAN eintragen und anwenden.
  2. In der Admin-Konsole bei der Firewall unter Edit route settings die Route freigeben. Ohne Freigabe ist das Netz nicht erreichbar.
  3. Die Freigabe lässt sich automatisieren, damit Routen nach einer Neuinstallation sofort aktiv sind:
"autoApprovers": {
  "routes": { "192.168.10.0/24": ["tag:opnsense"] }
}

Clients müssen Routen annehmen: Windows-, macOS-, iOS- und Android-Apps übernehmen freigegebene Routen automatisch. Linux-Clients nicht – dort einmalig sudo tailscale set --accept-routes ausführen.

Site-to-Site: zwei Standorte über Tailscale verbinden

  1. Beide OPNsense wie oben anmelden, beide mit Tag (z. B. tag:opnsense).
  2. Standort A bietet 192.168.10.0/24 an, Standort B 192.168.20.0/24. Die Netze dürfen sich nicht überschneiden.
  3. Auf beiden Firewalls Accept Subnet Routes aktivieren und die Routen in der Konsole freigeben.
  4. In der Richtlinie den Verkehr zwischen den Netzen erlauben, z. B. { "src": ["192.168.10.0/24", "192.168.20.0/24"], "dst": ["192.168.10.0/24", "192.168.20.0/24"], "ip": ["*"] } – bei aktivem SNAT erscheint der Verkehr mit der Tailscale-Adresse der jeweiligen Firewall, daher zusätzlich tag:opnsense als Quelle aufnehmen.
  5. Da die OPNsense jeweils das Standard-Gateway ihres LANs ist, gelangt der Verkehr ohne zusätzliche Routen auf den Clients zur Gegenseite.

Für sehr hohen Durchsatz zwischen Standorten bleibt ein klassisches WireGuard-Site-to-Site-VPN im Kernel meist schneller; Tailscale punktet bei wechselnden Adressen, CGNAT und einfacher Verwaltung.

OPNsense als Exit Node

Advertise Exit Node aktivieren, in der Konsole freigeben und unter Firewall → NAT → Source NAT eine Regel anlegen, die Verkehr aus 100.64.0.0/10 auf die WAN-Adresse übersetzt. Auf der Tailscale-Schnittstelle den Internetzugang erlauben. Clients wählen die Firewall danach in der App als Exit Node aus.

Hochverfügbarkeit im CARP-Cluster

Die Tailscale-Identität einer Firewall ist an ihren eigenen Schlüssel gebunden und wird nicht über die CARP-/XMLRPC-Synchronisation übertragen. Bewährt hat sich:

  1. Beide Knoten getrennt anmelden (eigener Auth Key, eigener Gerätename, z. B. fw-a und fw-b).
  2. Auf beiden Knoten dieselben Subnets anbieten und in der Konsole freigeben. Tailscale behandelt die beiden Firewalls dann als hochverfügbare Subnet Router und schaltet bei Ausfall des aktiven Routers automatisch auf den anderen um.
  3. Die Datei /var/db/tailscale/tailscaled.state nie von einem Knoten auf den anderen kopieren – zwei Geräte mit identischem Schlüssel stören sich gegenseitig.
  4. Die Source-NAT-Regel mit statischem Port auf beiden Knoten anlegen (bei synchronisierten Regeln mit der WAN-Adresse des jeweiligen Knotens, nicht der CARP-Adresse).

Leistung realistisch einschätzen

Weil Tailscale auf FreeBSD im Userspace verschlüsselt, erreicht die OPNsense in der Regel einen geringeren Durchsatz als ein Linux-System mit gleicher Hardware. Für Fernzugriff und Standorte mit typischen Leitungen genügt das meist. Messen Sie vor der Einführung mit iperf3 durch den Tunnel. Für große Datenmengen kann ein Linux-Subnet-Router hinter der OPNsense die bessere Wahl sein.

Fehlerbehebung

Problem Ursache und Lösung
Firewall startet sehr langsam Steuerserver beim Booten nicht erreichbar; Login timeout nicht auf 0 setzen.
Netz im Tailnet nicht erreichbar Route in der Konsole nicht freigegeben; Linux-Client ohne --accept-routes; Richtlinie erlaubt das Ziel nicht.
Verbindungen langsam, tailscale ping zeigt DERP Source-NAT-Regel mit statischem Port fehlt oder steht nicht oben; UDP 41641 wird vom Provider blockiert.
Namensauflösung der Firewall gestört Accept DNS ist aktiv – deaktivieren und Dienst neu starten.
Gerät nach Neuinstallation doppelt in der Konsole Alte Maschine in der Konsole löschen und neu mit Auth Key anmelden.

Nützliche Befehle in der Shell: tailscale status, tailscale netcheck, tailscale ping <gerät> und service tailscaled restart.

Unterstützung von m.a.x. it

Sie möchten Tailscale auf Ihren OPNsense-Firewalls einführen, Standorte koppeln oder den Zugriff Ihrer Mitarbeiter mit sauberen Richtlinien absichern? m.a.x. it unterstützt Sie als OPNsense-Partner mit OPNsense-Firewall-Services von m.a.x. it – von der Einrichtung bis zum Betrieb im Cluster.

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 „https://techcorner.max-it.de/index.php?title=OPNsense_-_Tailscale-Plugin&oldid=5183“