Zwei Häuser per VPN verbinden: Tailscale oder WireGuard im Router?

Die Ausgangslage ist konkret: zwei Häuser in verschiedenen Städten, in jedem stehen mehrere Rechner, und die sollen sich gegenseitig direkt erreichen. Aktuell läuft dafür Tailscale auf jeder Maschine. Weil einer der beiden Anschlüsse eine öffentliche und statische IP vom Provider hat, kommen die Geräte bisher auch mit direkten Tailscale-Verbindungen zurecht.

Die Frage dahinter ist eine andere: Muss auf jedem Gerät ein eigener Client laufen, oder übernimmt der Router die Verbindung für das ganze Netz? Der Fragesteller will seine vorhandene Hardware auslasten und mag keine Geräte, die nur als Client herumliegen. Genau diese Haltung weist hier die Richtung.

Die kurze Antwort vorweg: Mit einer statischen öffentlichen IP an einem der beiden Standorte ist ein WireGuard-Site-to-Site-VPN auf Router-Ebene der sauberere Weg. Es deckt alle Geräte beider Netze ab, ohne dass auf jeder Maschine ein Client läuft, und kommt ohne die zentrale Vermittlungsstelle von Tailscale aus. Tailscale bleibt sinnvoll für Geräte, die das Haus verlassen, und für den Fall, dass keine Seite eine öffentliche IP hat. Was hinter dieser Einschätzung steckt, erklärt der Rest des Artikels.

Inhaltsverzeichnis

• Was die beiden Ansätze unterscheidet
• Warum die statische IP die Entscheidung bestimmt
• WireGuard im Router: Site-to-Site einrichten
• Tailscale mit Subnet-Routern: die Zwischenstufe
• Beide Ansätze im Vergleich
• Tests und Fehlerbehebung
• FAQ
• Fazit

Kurzantwort

Zwei Häuser per VPN verbinden: Tailscale auf jedem Gerät oder WireGuard im Router? Mit Konfiguration, Tests und einer klaren Entscheidungshilfe. Kurz gesagt: ki tools praxis ist vor allem dann relevant, wenn du schnell verstehen willst, was konkret dahinter steckt, welche Grenzen es gibt und welche Entscheidung daraus folgt. Die Details, Quellen und Einschränkungen stehen in den folgenden Abschnitten.

Was die beiden Ansätze unterscheidet

WireGuard ist ein VPN-Tunnel, der auf jeder Plattform gleich funktioniert. Es legt eine Netzwerkschnittstelle an, üblicherweise wg0, und verbindet zwei Endpunkte über verschlüsselte UDP-Pakete. Die Konfiguration besteht aus einem privaten Schlüssel und einer Liste von Peers, die je einen öffentlichen Schlüssel und erlaubte IP-Adressen mitbringen. WireGuard selbst nennt das „Cryptokey Routing": Der öffentliche Schlüssel ist an die IP-Adressen gebunden, die dieser Peer senden darf. Beim Senden wirkt die Liste der erlaubten Adressen wie eine Routing-Tabelle, beim Empfangen wie eine Zugriffsliste 1.

Wichtig für den Vergleich: WireGuard kennt keine zentrale Instanz. Es gibt keinen Server, der Verbindungen verwaltet, und keinen Daemon, der Zustände pflegt. Zwei Peers tauschen ihre öffentlichen Schlüssel aus, so wie man SSH-Keys tauscht, und danach können sie Pakete durch die Schnittstelle schicken. Der Standardport ist UDP 51820 1.

Tailscale baut auf dem WireGuard-Protokoll auf, fügt aber eine Koordinations- und Vermittlungsschicht hinzu. Es gibt einen zentralen Koordinationsserver für Schlüsselaustausch und Zugriffsregeln sowie eine Flotte von Relays, die Tailscale DERP nennt („Detoured Encrypted Routing Protocol"). Diese Relays springen ein, wenn eine direkte Verbindung durch NAT nicht zustande kommt. Tailscale schätzt selbst, dass in über 90 Prozent der Fälle eine direkte Verbindung gelingt und die Relays für den Rest die Erreichbarkeit absichern 4.

Daraus folgt der strukturelle Unterschied. Tailscale ist ein Mesh auf Geräteebene: Jede Maschine bekommt eine eigene Adresse und spricht direkt mit jeder anderen Maschine. Router-WireGuard ist ein Tunnel zwischen zwei Netzen: Der Router verbindet das komplette lokale Subnetz mit dem Subnetz am anderen Ende, und die einzelnen Geräte müssen von der VPN-Technik nichts wissen.

Der Adressbereich macht den Unterschied greifbar. Tailscale vergibt jedem Gerät eine Adresse aus dem reservierten CGNAT-Bereich 100.64.0.0/10; diese Adressen existieren nur innerhalb des Tailnets 2. Beim Router-WireGuard behalten die Geräte dagegen ihre normalen LAN-Adressen. Ein NAS ist in beiden Häusern unter seiner gewohnten IP erreichbar, ohne dass ein Client die Adresse umschreibt. Das ist ein praktischer Vorteil, wenn Dienste mit fest eingetragenen Adressen arbeiten oder Firewall-Regeln auf die LAN-IPs verweisen.

Warum die statische IP die Entscheidung bestimmt

Der entscheidende Punkt in der geschilderten Ausgangslage ist nicht die Zahl der Geräte, sondern die statische öffentliche IP. Ein klassisches Site-to-Site-WireGuard braucht mindestens einen erreichbaren Endpunkt: eine öffentliche Adresse, an der ein Router auf UDP 51820 lauscht und zu der der andere Router den Tunnel aufbauen kann 1, 5. Genau das ist hier vorhanden.

Damit fällt der größte Vorteil von Tailscale in diesem Szenario weg. Tailscales Kernleistung ist, dass es Verbindungen auch dann herstellt, wenn keine Seite eine öffentliche IP hat: NAT-Traversal, und wenn das scheitert, der Weg über DERP-Relays 4. Wer hinter CGNAT sitzt oder keinen Port weiterleiten kann, bekommt mit reinem WireGuard keinen direkten Tunnel zustande. Wer eine statische IP hat, braucht diese Maschinerie nicht.

Der Umkehrschluss gilt ebenso: Hätte keiner der beiden Anschlüsse eine öffentliche IP, wäre Router-WireGuard deutlich mühsamer. Dann bräuchte es DynDNS, einen externen Vermittler oder eben Tailscale. Die statische IP ist also der Faktor, der aus einem „Tailscale ist einfacher" ein „WireGuard im Router passt besser" macht.

Hinzu kommt der geäußerte Wunsch, vorhandene Hardware auszulasten. Der Router läuft ohnehin durchgehend. Er kann die Tunnelverbindung dauerhaft halten, während einzelne Clients an- und ausgehen. Ein Site-to-Site-VPN nutzt genau das Gerät, das für Netzaufgaben gedacht ist, statt jeder Maschine einen Client aufzubürden.

WireGuard im Router: Site-to-Site einrichten

Der Aufbau ist symmetrisch: Jeder Router hat ein eigenes Schlüsselpaar und konfiguriert den jeweils anderen als Peer. Beide Seiten sind zugleich Server und Client füreinander. Die Seite mit statischer IP lässt den Endpunkt im Peer-Eintrag weg; die Gegenseite ohne öffentliche IP trägt den Endpunkt der statischen IP ein und baut die Verbindung aktiv auf 1, 5.

Die OpenWrt-Dokumentation nennt als Voraussetzungen: die WireGuard-Pakete installieren, IPv6 konfigurieren und bei dynamischer IP einen DDNS-Client einrichten. Bei statischer IP entfällt der DDNS-Schritt. Die Anleitung ist mit OpenWrt 23.05 getestet und nutzt den Standardport 51820 5.

Der Kern der Konfiguration auf Router A (statische IP) sieht so aus:

[Interface]
PrivateKey = <private-key-a>
ListenPort = 51820

[Peer]
PublicKey = <public-key-b>
AllowedIPs = 192.168.2.0/24

Auf Router B (ohne öffentliche IP) entsprechend mit dem Endpunkt von A:

[Interface]
PrivateKey = <private-key-b>
ListenPort = 51820

[Peer]
PublicKey = <public-key-a>
Endpoint = <statische-ip-a>:51820
AllowedIPs = 192.168.1.0/24
PersistentKeepalive = 25

Der zusätzliche Eintrag PersistentKeepalive = 25 auf der Seite hinter NAT ist wichtig. Er schickt alle 25 Sekunden ein kleines Paket, hält so die NAT-Zuordnung offen und verhindert, dass der Tunnel einschläft, wenn längere Zeit kein Verkehr fließt. Ohne ihn kann die Gegenseite die Verbindung nicht mehr aufbauen, sobald die NAT-Tabelle den Eintrag vergessen hat.

Der Eintrag AllowedIPs ist die zentrale Stellschraube. Er sagt dem Router, welche Adressen über den Tunnel laufen: auf jeder Seite das LAN-Subnetz des jeweils anderen Standorts 1. Drei Dinge müssen zusätzlich stimmen, sonst kommt trotz Handshake nichts durch:

1. IP-Forwarding muss aktiv sein, damit der Router Pakete zwischen LAN und Tunnel weiterreicht.
2. Die Firewall muss UDP 51820 am WAN-Interface erlauben und den Verkehr zwischen LAN- und VPN-Zone freigeben 5.
3. Die LAN-Subnetze beider Häuser dürfen sich nicht überlappen. Beide auf 192.168.1.0/24 funktioniert nicht, weil der Router nicht weiß, welches Netz gemeint ist.

Dasselbe Prinzip gilt auf anderen Routern. MikroTik RouterOS 7 bringt WireGuard nativ mit; OPNsense und pfSense liefern WireGuard als integriertes Paket beziehungsweise Plugin aus. Auf der Fritz!Box ist WireGuard seit FRITZ!OS 7.50 integriert, dort ist der Einsatzzweck aber eher der Einwahlzugang einzelner Geräte von unterwegs als ein symmetrischer Tunnel zwischen zwei Routern 7.

Tailscale mit Subnet-Routern: die Zwischenstufe

Wer die Vorteile von Tailscale behalten will, aber nicht auf jedem Gerät einen Client installieren möchte, nimmt den Mittelweg: einen Subnet-Router pro Standort. Dabei läuft Tailscale auf genau einer Maschine je Haus, üblicherweise dem Router oder einem kleinen Always-on-Rechner, und dieser stellt das lokale Subnetz für den Rest des Tailnets bereit 2, 3.

Die Voraussetzungen sind überschaubar. Der Subnet-Router muss unter Linux laufen, IP-Forwarding aktiviert haben und die Route zum lokalen Subnetz ankündigen. Der relevante Befehl für ein Haus mit dem Netz 192.168.1.0/24 lautet:

tailscale up --advertise-routes=192.168.1.0/24 --snat-subnet-routes=false --accept-routes

--snat-subnet-routes=false sorgt dafür, dass Geräte am anderen Ende die echte Quell-IP sehen statt der Adresse des Subnet-Routers. --accept-routes lässt den Router die Routen der Gegenseite übernehmen 2. Zusätzlich empfiehlt die Dokumentation, die MSS an die MTU anzupassen, damit große TCP-Verbindungen durch den Tunnel nicht an Paketgrößen scheitern 2.

Danach folgt Verwaltung in der Tailscale-Konsole: Der Subnet-Router muss dort freigeschaltet und die Zugriffsregeln müssen ergänzt werden. Für eine Verbindung zwischen zwei Subnetzen braucht es zwei Regeln, je eine Richtung, etwa als grants in der Access-Control-Policy 2.

Am Ende müssen die Geräte in jedem Netz noch wissen, dass sie für das fremde Subnetz den Subnet-Router ansprechen sollen. Ist der Subnet-Router bereits das Standard-Gateway, passiert das automatisch. Sonst hilft eine statische Route, zum Beispiel:

ip route add 192.168.2.0/24 via <subnet-router-ip>

Der Effekt: Drucker, Fernseher oder NAS ohne Tailscale-Client sind erreichbar, und man behält zugleich NAT-Traversal und die zentrale Zugriffskontrolle von Tailscale 2, 3. Eine wichtige Einschränkung bleibt: Identische CIDR-Bereiche an beiden Standorten sind ausgeschlossen. Überlappende Bereiche mit unterschiedlicher Prefix-Länge löst Tailscale dagegen per Longest-Prefix-Match auf 2.

Beide Ansätze im Vergleich

Die drei Varianten lassen sich an wenigen Kriterien festmachen.

Für den geschilderten Fall spricht am meisten für Router-WireGuard, dass die statische IP vorhanden ist und keine fremde Kontrollebene gewünscht ist. Wer Laptops oder Smartphones hat, die unterwegs auf beide Häuser zugreifen sollen, ergänzt dafür separate Clients. Das können WireGuard-Clients auf den Mobilgeräten sein oder ein parallel laufendes Tailscale. Beides schließt sich nicht aus.

Für Tailscale je Gerät spricht die niedrige Einrichtungshürde und die eingebaute Zugriffsregelung. Der kostenlose Personal-Tarif deckt eine begrenzte Zahl von Nutzern und Geräten ab, laut aktueller Tailscale-Dokumentation bis zu sechs Nutzer pro Tailnet 6. Wer viele Geräte in beiden Häusern hat und zugleich keine öffentliche IP besitzt, ist mit Tailscale oder der Subnet-Router-Variante am schnellsten am Ziel.

Die Subnet-Router-Variante ist die richtige Wahl, wenn die Netze verbunden sein sollen, eine öffentliche IP fehlt und man trotzdem nicht jeden Drucker mit einem Client ausstatten will.

Tests und Fehlerbehebung

Der erste Test ist immer derselbe: Von einem Gerät in Haus A ein ping auf ein Gerät in Haus B absetzen und umgekehrt. Funktioniert der Ping nicht, hilft die Reihenfolge aus den häufigen Ursachen.

Beim Router-WireGuard zeigt wg show auf beiden Seiten, ob ein Handshake zustande kommt. Fehlt der Handshake, stimmt entweder der Endpunkt nicht, der Port ist in der Firewall zu, oder die Schlüssel passen nicht zusammen. Ein aktueller Handshake mit kleinen Übertragungswerten, aber ausbleibendem Ping deutet fast immer auf ein Routing- oder Firewall-Problem zwischen LAN- und VPN-Zone hin 1, 5.

Die drei häufigsten Fallen, geordnet nach Häufigkeit:

1. Gleiche Subnetze an beiden Standorten. 192.168.1.0/24 zweimal macht jede Route mehrdeutig. Ein Netz muss umnummeriert werden.
2. AllowedIPs zu eng gefasst. Fehlt das fremde Subnetz im Peer-Eintrag, verwirft der Router die Pakete dorthin 1.
3. MTU-Probleme bei großen Übertragungen. Kleine Pings laufen, Downloads hängen. Dann die MSS klemmen, wie es auch die Tailscale-Doku für Subnet-Router empfiehlt 2.

Beim Tailscale-Subnet-Router prüfen tailscale status und die Route-Anzeige, ob die Subnetz-Routen angekündigt und übernommen wurden. Scheitert der Zugriff auf ein Gerät ohne Client, fehlt meist die Route auf diesem Gerät oder die Freigabe in der Access-Control-Policy 2, 3.

Ein zweiter sinnvoller Test ist ein größerer Datentransfer, etwa ein scp einer ISO-Datei, statt nur Ping. Damit fallen MTU- und Durchsatzprobleme auf, die ein einzelnes ICMP-Paket nicht zeigt.

FAQ

Braucht WireGuard einen eigenen Server? Nein. WireGuard ist reines Peer-to-Peer ohne zentrale Instanz. Für ein Site-to-Site-VPN reichen zwei Router, die ihre öffentlichen Schlüssel tauschen 1.

Was ist DERP bei Tailscale? DERP steht für „Detoured Encrypted Routing Protocol". Es sind Relays, die Tailscale einsetzt, wenn NAT-Traversal keine direkte Verbindung herstellt. Sie sichern Erreichbarkeit, sind aber langsamer als eine direkte Verbindung 4.

Muss die zweite Seite auch eine öffentliche IP haben? Nein. Es genügt, wenn eine Seite einen erreichbaren Endpunkt hat. Die andere Seite ohne öffentliche IP baut den Tunnel aktiv auf 1.

Kann ich WireGuard und Tailscale gleichzeitig betreiben? Ja. Sie stören sich nicht. Ein übliches Muster ist Router-WireGuard für die beiden Standorte plus Tailscale oder WireGuard-Clients für mobile Geräte.

Was ist mit Geräten, die keinen Tailscale-Client können? Dafür gibt es Subnet-Router. Ein Gerät im Netz kündigt das Subnetz an, und Geräte ohne Client werden über diese Route erreichbar 2, 3.

Was kostet das Ganze? WireGuard und die Router-Lösung kosten nichts, sie sind Open Source. Tailscale hat einen kostenlosen Personal-Tarif mit begrenzter Nutzer- und Gerätezahl 6.

Beide Häuser nutzen 192.168.1.0/24. Geht das? Nein, nicht mit identischen Bereichen. Ein Standort muss auf einen anderen Adressbereich umgestellt werden. Überlappende Bereiche mit unterschiedlicher Prefix-Länge kann Tailscale dagegen per Longest-Prefix-Match auflösen 2.

Brauche ich bei statischer IP noch DynDNS? Nein. DynDNS ist nur nötig, wenn sich die öffentliche Adresse ändert. Bei statischer IP kann der Endpunkt fest eingetragen werden 5.

Unterstützt meine Fritz!Box WireGuard? Seit FRITZ!OS 7.50 ja. Der Einsatzzweck ist dort vor allem der Einwahlzugang einzelner Geräte, weniger ein symmetrischer Tunnel zwischen zwei Routern 7.

Ist Tailscale langsamer als reines WireGuard? Bei direkter Verbindung nicht, denn Tailscale nutzt ebenfalls WireGuard als Tunnelprotokoll. Läuft der Verkehr über ein DERP-Relay, weil keine direkte Verbindung möglich ist, wird er spürbar langsamer 4. Mit der statischen IP in diesem Szenario bleibt die Verbindung direkt.

Fazit

Die Frage „Tailscale auf jeder Maschine oder WireGuard im Router?" hat keine universelle Antwort, aber für die geschilderte Ausgangslage eine klare. Wer zwei Standorte verbinden will, an einem davon eine statische öffentliche IP hat und keine dauerhaft laufenden Clients auf jeder Maschine möchte, ist mit WireGuard im Router besser bedient. Es nutzt die vorhandene Hardware, deckt alle Geräte beider Netze ab und kommt ohne fremde Kontrollebene aus.

Tailscale verliert in diesem konkreten Fall seinen wichtigsten Vorteil, die NAT-Überwindung ohne öffentliche IP. Es bleibt die bequemere Wahl für Geräte, die mobil sind, und für Netze, in denen keine Seite erreichbar ist. Wer beide Welten will, nimmt Subnet-Router und bekommt die Router-Abdeckung mit Tailscales Komfort.

Die Entscheidung hängt also an zwei Fragen: Gibt es an einem Standort eine öffentliche IP, und verlassen die Geräte das Haus? Wer beide mit Ja und Nein beantwortet, kann sich den Client auf jeder Maschine sparen.

Passende Produktrecherchen

Wenn du die praktische Seite vertiefen möchtest, findest du hier passende Suchpfade zum Vergleichen. Keine Kaufpflicht, keine Rangliste, sondern thematisch passende Produktrecherchen:

• GL.iNet Router für Testnetze und Reise-VPNs ansehen
• Datenschutzfreundliche Android-Phones vergleichen
• Mini-PCs für Homelab und Security-Lab vergleichen
• Raspberry Pi und Mini-PCs vergleichen
• NAS-Festplatten und Backup-Zubehör ansehen

Hinweis: Als Amazon-Partner verdient kalika.de an qualifizierten Verkäufen. Für dich ändert sich der Preis nicht.

Quellen

[1] https://www.wireguard.com/ — WireGuard, offizielle Projektseite: Funktionsweise, Cryptokey Routing, Konfigurationsformat

[2] https://tailscale.com/docs/features/site-to-site — Site-to-site networking, Tailscale-Dokumentation

[3] https://tailscale.com/docs/features/subnet-routers/how-to/setup — Configure a subnet router, Tailscale-Dokumentation

[4] https://tailscale.com/blog/how-nat-traversal-works — How NAT traversal works, Tailscale-Blog (DERP-Relays, Koordinationsserver)

[5] https://openwrt.org/docs/guide-user/services/vpn/wireguard/site-to-site — WireGuard site-to-site automated, OpenWrt-Wiki

[6] https://tailscale.com/docs/account/manage-plans/free-plans-discounts — Free pricing plans and discounts, Tailscale-Dokumentation

[7] https://fritz.com/apps/knowledge-base/FRITZ-Box-7490/3685_WireGuard-VPN-zur-FRITZ-Box-am-Computer-einrichten/ — WireGuard-VPN zur FRITZ!Box, AVM-Wissensdatenbank

Weiterführende Artikel

• KI-Tools in der Praxis: Open-Source Voice Changer für Linux: Stimme anonymisieren mit lokalen Modellen
• Asus ZenWifi Mesh: Neueres Modell ergänzen oder bei bewährten AX-Geräten bleiben?
• Von VMware zu Proxmox wechseln: Lohnt sich der Umstieg für Profis?
• Proxmox GPU Passthrough mit Nvidia: Kompletter Guide 2026 (IOMMU, vGPU, KI-Workloads)
• Datenlecks erkennen: So findest du heraus, wo deine Daten abfließen

Transparenzhinweis

Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz erstellt und automatisiert auf Quellen, Fakten und Qualitätskriterien geprüft.