WireGuard Site-to-Site-VPN: zwei Netzwerke verbinden (2026)

Affiliate-Hinweis — Dieser Artikel enthält Contabo-Affiliate-Links. Wenn Sie über sie einen VPS bestellen, erhalten wir eine Provision ohne Mehrkosten für Sie. Alle Befehle und Konfigurationen unten sind aus den offiziellen WireGuard-Quellen dokumentiert und so geschrieben, dass sie auf Ihren eigenen Maschinen reproduzierbar sind.

Ein Site-to-Site-VPN verbindet zwei ganze Netzwerke, sodass sie sich wie eines verhalten. Jeder Host im Büro-LAN erreicht jeden Host im Heim-LAN — Ihr NAS, einen Drucker, einen Hypervisor, eine Datenbank — ohne auf jedem Gerät einen VPN-Client zu installieren. WireGuard macht das schlank und schnell: ein einziger UDP-Port, eine Handvoll Konfigurationszeilen, Kryptografie im Kernel-Space. Diese Anleitung baut einen funktionierenden WireGuard-Site-to-Site-Tunnel von Grund auf und erklärt dann die drei Dinge, die Leute immer falsch machen: AllowedIPs, IP-Forwarding und Host-Routing.

Wir nutzen eine konkrete, häufige Topologie: Standort A ist ein Heim- oder Büro-LAN hinter NAT (keine nutzbare öffentliche IP), und Standort B ist ein VPS mit öffentlicher IPv4 als stets aktiver Hub. Dieselbe Konfiguration verbindet auch zwei Wohnungen, zwei Büros oder zwei Rechenzentren — nur die Subnetze ändern sich.

Site-to-Site vs Road-Warrior: was sich wirklich ändert

Wenn Sie WireGuard schon einmal für einen Laptop eingerichtet haben, sind 90 % davon vertraut. Der Denkwechsel ist klein, aber entscheidend:

Road-Warrior (Remote-Zugriff): Ein Gerät tritt dem Netzwerk bei. Sein Peer kündigt eine einzelne Tunnel-Adresse an — AllowedIPs = 10.66.66.2/32.
Site-to-Site: Ein ganzes Netzwerk tritt bei. Der Peer kündigt das dahinterliegende LAN-Subnetz an — AllowedIPs = 10.66.66.2/32, 192.168.10.0/24 — und die WireGuard-Box leitet für jeden Host dieses LANs weiter.

Alles andere — Schlüssel, Handshake, UDP-Port — ist identisch. Schlägt Ihr Handshake nie an, sind die Ursachen dieselben wie bei jedem Tunnel; arbeiten Sie die WireGuard-Handshake-Fehlerliste durch, bevor Sie den Site-to-Site-Teil verdächtigen.

Ein dichtes Bündel blauer, grüner, gelber und roter Ethernet-Patchkabel, gesteckt in einen Netzwerk-Switch in einem Rack

Planen Sie zuerst den Adressraum (5 Minuten, die Stunden sparen)

Bevor Sie eine Konfiguration anfassen, notieren Sie drei Bereiche. Das hier falsch zu machen ist die häufigste Ursache für einen Tunnel, der sich verbindet, aber keinen Host-Verkehr trägt.

Bereich	Beispiel	Regel
Tunnel-Subnetz	`10.66.66.0/24`	VPN-eigen, darf mit keinem LAN kollidieren
LAN Standort A	`192.168.10.0/24`	Das Heim-/Büronetz
LAN Standort B	`192.168.20.0/24`	Das entfernte Netz — muss von Standort A abweichen

Die harte Regel: Die beiden LANs dürfen sich nicht überlappen. Nutzen beide Seiten heute 192.168.1.0/24, nummerieren Sie jetzt eines um. Ein Host kann nicht zu einem entfernten Subnetz routen, das identisch zu seinem eigenen aussieht — er behandelt die Adresse als lokal und übergibt das Paket nie an WireGuard. Falls Ihnen die Subnetz-Mathematik unklar ist: unsere Erklärung, was ein Subnetz ist, behandelt CIDR verständlich.

Schritt 1 — Den Hub bereitstellen (Standort B, der VPS)

Standort B braucht eine öffentliche IPv4 und einen offenen UDP-Port. Wir nutzen einen Contabo Cloud VPS 10 (4 vCPU, 8 GB RAM, 75 GB NVMe) für 5,50 €/Monat bei 12 Monaten Laufzeit — überdimensioniert für einen Tunnel, komfortabel, wenn er auch andere Dienste betreibt. Falls Sie noch keinen VPS haben, holen Sie sich den Contabo Cloud VPS 10; wählen Sie eine Region nahe dem Standort mit dem meisten Verkehr. Für eine saubere WireGuard-Installation darauf folgen Sie der Schritt-für-Schritt-Anleitung Contabo + WireGuard und kommen dann für das Site-to-Site-Routing hierher zurück.

Installieren Sie WireGuard und erzeugen Sie die Schlüssel auf dem VPS:

sudo apt update && sudo apt install -y wireguard
umask 077
wg genkey | tee siteB.key | wg pubkey > siteB.pub

Schritt 2 — Den WireGuard-Router an Standort A einrichten

Die WireGuard-Box an Standort A ist eine beliebige stets eingeschaltete Linux-Maschine im LAN — ein Raspberry Pi, eine kleine VM, ein alter Laptop. Sie braucht keine öffentliche IP; sie wählt zum VPS hinaus. Erzeugen Sie ihre Schlüssel genauso:

wg genkey | tee siteA.key | wg pubkey > siteA.pub

Diese Maschine wird zum Gateway für das entfernte Subnetz und muss daher Pakete zwischen ihrer LAN-Schnittstelle und der WireGuard-Schnittstelle weiterleiten.

Schritt 3 — Die beiden Konfigurationen

Hier ist der ganze Tunnel. Beachten Sie, wie das AllowedIPs jeder Seite das LAN des anderen Standorts auflistet — diese Zeile macht aus einer Punkt-zu-Punkt-Verbindung eine Netz-zu-Netz-Verbindung.

Standort B — der VPS-Hub (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.1/24
ListenPort = 51820
PrivateKey = <siteB.key>
# Forwarding + Masquerade, damit Standort-A-Hosts auch über den VPS ins Internet kommen
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# Standort A
PublicKey = <siteA.pub>
AllowedIPs = 10.66.66.2/32, 192.168.10.0/24

Standort A — der LAN-Router (/etc/wireguard/wg0.conf):

[Interface]
Address = 10.66.66.2/24
PrivateKey = <siteA.key>
PostUp = sysctl -w net.ipv4.ip_forward=1
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -A FORWARD -o wg0 -j ACCEPT

[Peer]
# Standort B (der VPS-Hub)
PublicKey = <siteB.pub>
Endpoint = 203.0.113.10:51820
AllowedIPs = 10.66.66.0/24, 192.168.20.0/24
PersistentKeepalive = 25

Zwei Details, auf die es ankommt:

PersistentKeepalive = 25 gehört auf die Seite hinter NAT (Standort A). Es schickt alle 25 Sekunden ein winziges Paket, damit der Heimrouter den UDP-Pfad offen hält und der VPS immer zurückfindet.
Endpoint erscheint nur im Peer-Block von Standort A — Standort A wählt den VPS an. Der VPS lernt die Adresse von Standort A, sobald das erste Paket eintrifft; sein Peer-Block hat daher kein Endpoint.

Bringen Sie beide Tunnel mit sudo wg-quick up wg0 hoch und prüfen Sie sudo wg show. Ein latest handshake jünger als zwei Minuten auf beiden Seiten bedeutet, die Verbindung lebt.

Schritt 4 — Der Schritt, den alle vergessen: das Host-Routing

Hier hängen die meisten Site-to-Site-Tunnel fest. Die Router pingen sich über 10.66.66.x, aber ein Laptop an Standort A erreicht ein NAS an Standort B trotzdem nicht. Warum? Weil die übrigen Hosts in jedem LAN nicht wissen, dass die WireGuard-Box die Tür zum entfernten Subnetz ist. Sie schicken das Paket an ihr Standard-Gateway, das keine Route für 192.168.20.0/24 hat, und es stirbt.

Sie haben zwei saubere Wege, das zu beheben:

Statische Route auf dem LAN-Gateway (am besten). Fügen Sie auf dem Hauptrouter von Standort A eine statische Route hinzu: Ziel 192.168.20.0/24, Gateway = die LAN-IP der WireGuard-Box von Standort A (z. B. 192.168.10.5). Spiegeln Sie das an Standort B. Nun erbt jeder Host die Route automatisch. Die meisten Heim- und Business-Router unterstützen statische Routen im Admin-Panel.
Statische Routen pro Host. Können Sie den Router nicht anfassen, fügen Sie auf jeder Maschine, die standortübergreifend zugreifen muss, eine Route hinzu:

# auf einem Standort-A-Host das Standort-B-LAN über die lokale WireGuard-Box erreichen
sudo ip route add 192.168.20.0/24 via 192.168.10.5

Ist die WireGuard-Box das Standard-Gateway Ihres LANs, können Sie dies ganz überspringen — sie leitet bereits weiter. Konzeptionell ist das ein Routing-Problem, kein VPN-Problem; dieselbe Logik wie Portweiterleitung, nur auf ein ganzes Subnetz statt einen einzelnen Port angewandt.

Schritt 5 — Firewall auf dem Forwarding-Pfad

Weiterleiten ohne Firewall-Regel heißt: entweder nichts oder alles geht durch. Seien Sie explizit. Auf dem VPS-Hub akzeptiert das obige PostUp bereits den von wg0 weitergeleiteten Verkehr; verschärfen Sie es, wenn nur bestimmte Subnetze reden sollen:

# nur LAN Standort A <-> LAN Standort B erlauben, Rest verwerfen
iptables -A FORWARD -s 192.168.10.0/24 -d 192.168.20.0/24 -i wg0 -j ACCEPT
iptables -A FORWARD -s 192.168.20.0/24 -d 192.168.10.0/24 -o wg0 -j ACCEPT

Machen Sie die Regeln dauerhaft (iptables-save oder netfilter-persistent save unter Debian/Ubuntu), damit sie einen Neustart überstehen. Der einzelne UDP-Port muss zudem vor dem VPS offen sein — siehe welchen Port WireGuard nutzt und wie man ihn öffnet, falls der Handshake nie startet.

Den kompletten Pfad prüfen

Führen Sie dies der Reihe nach aus und stoppen Sie beim ersten Fehler:

Tunnel aktiv? sudo wg show an beiden Enden → jüngster latest handshake, transfer ungleich null.
Router zu Router? Von der WireGuard-Box an Standort A: ping 10.66.66.1. Fehler → es ist ein Tunnel-Problem, kein Site-to-Site-Problem.
Router zum entfernten LAN? Von der Box an Standort A: ping 192.168.20.1. Fehler → AllowedIPs oder ip_forward an Standort B.
Host zu entferntem Host? Von einem Laptop an Standort A: ping 192.168.20.50. Hier Fehler, aber Schritt 3 lief → Host-Routing (Schritt 4).

Diese vierstufige Leiter isoliert in unter einer Minute die genau kaputte Schicht.

Wann weitere Standorte dazukommen — Hub-and-Spoke

Um drei oder mehr Netze zu verbinden, behalten Sie den VPS als zentralen Hub und fügen jedes neue LAN als Spoke-Peer hinzu. Jeder Spoke listet alle anderen LAN-Subnetze in seinem AllowedIPs (geroutet über den Hub), und der Hub listet das LAN jedes Spokes. Das bleibt bis zu einer Handvoll Standorten einfach. Darüber hinaus — oder wenn Sie automatische Schlüsselrotation, ACLs und NAT-Traversal ganz ohne öffentliche IP wollen — ist eine Mesh-Steuerebene wie Tailscale oder Headscale weniger Arbeit als das Peers-von-Hand-Editieren; wägen Sie das in unserem Vergleich Tailscale vs WireGuard selbst gehostet ab.

Warum den Hub selbst hosten statt eines Managed-Dienstes

Eine Site-to-Site-Verbindung ist genau der Punkt, an dem sich die eigene Box auszahlt: kein Preis pro Platz, kein Datenlimit, kein Dritter im Pfad zwischen Ihren beiden Netzen. Ein Contabo Cloud VPS 10 für 5,50 €/Monat bietet öffentliche IPv4, vollen Root-Zugriff, unbegrenzten Traffic (Fair Use) und die Freiheit, genau den einen UDP-Port zu öffnen, den Sie brauchen — der ideale stets aktive Hub, um Ihre Standorte zu verbinden. Einmal gebaut, läuft er jahrelang.

Weiterführend

Quellen und Referenzen:

Veröffentlicht am 2026-06-26. Topologie validiert auf Debian 12 und Ubuntu 24.04 mit einem Contabo-Cloud-VPS-10-Hub und einem Raspberry-Pi-LAN-Router. Ihre Subnetze, Routermodelle und das NAT-Verhalten Ihres ISP weichen ab — bestätigen Sie jede Schicht stets mit wg show, ping und ip route, bevor Sie ein Setup als final betrachten.

Hinweis: WireGuard zu betreiben und ein VPN selbst zu hosten ist in der EU, den USA, Kanada und den meisten demokratischen Ländern legal. VPNSmith veröffentlicht diese Inhalte zu Bildungszwecken.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200+ Mbps garantiert

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Was ist der Unterschied zwischen einer Site-to-Site- und einer Road-Warrior-Konfiguration?

Eine Road-Warrior-Konfiguration (Remote-Zugriff) verbindet ein einzelnes Gerät — Ihren Laptop, Ihr Smartphone — mit einem Netzwerk. Eine Site-to-Site-Konfiguration verbindet zwei ganze Netzwerke: Jede Maschine im LAN A erreicht jede Maschine im LAN B, transparent, ohne WireGuard auf jedem Gerät zu installieren. Der ganze Unterschied steckt in AllowedIPs und im Routing: Ein Road-Warrior-Peer kündigt eine einzelne Tunnel-IP als /32 an, ein Site-to-Site-Peer kündigt das entfernte LAN-Subnetz an (z. B. 192.168.20.0/24) und die Router leiten für die Hosts dahinter weiter.

Brauchen beide Standorte eine öffentliche IP?

Nein — nur eine Seite braucht eine erreichbare öffentliche IP und einen offenen UDP-Port. WireGuard ist Peer-to-Peer: Die Seite hinter NAT (ein Heimanschluss, eine mobile CGNAT-Verbindung) baut den Tunnel auf und hält ihn mit PersistentKeepalive offen. Das klassische Muster: ein günstiger VPS mit öffentlicher IPv4 als stets aktiver Hub, an den sich ein oder mehrere LANs anwählen. Hat kein Standort eine öffentliche IP, leiten Sie beide über einen VPS-Hub, statt sie direkt zu verbinden.

Wie lasse ich das entfernte LAN das lokale LAN über WireGuard erreichen?

Drei Dinge müssen zusammenpassen. (1) AllowedIPs an jedem Peer muss das entfernte LAN-Subnetz auflisten, nicht nur das /32 des Tunnels. (2) IP-Forwarding muss aktiv sein: net.ipv4.ip_forward=1. (3) Die Hosts in jedem LAN müssen wissen, dass sie den Verkehr für das entfernte Subnetz an ihren lokalen WireGuard-Router schicken — entweder per statischer Route auf jedem Host oder per statischer Route auf dem Standard-Gateway des LAN, die das entfernte Subnetz auf die WireGuard-Box zeigt. Schritt 3 zu überspringen ist die häufigste Ursache für einen Site-to-Site-Tunnel, der zwischen Routern „funktioniert“, aber bei dem sich kein Host pingen lässt.

Brechen überlappende Subnetze ein Site-to-Site-VPN?

Ja, und zwar gründlich. Nutzen beide LANs 192.168.1.0/24, kann ein Host nicht erkennen, ob 192.168.1.50 lokal oder entfernt ist, und schickt das Paket nie durch den Tunnel. Sie müssen eine Seite umnummerieren (z. B. ein LAN auf 192.168.20.0/24 verschieben) oder per 1:1-NAT das entfernte Subnetz auf einen nicht überlappenden Bereich abbilden. Planen Sie Ihren Adressraum vor dem Aufbau — ein laufendes Netzwerk nachträglich umzunummerieren ist mühsam.

Ist WireGuard Site-to-Site schneller als OpenVPN Site-to-Site?

WireGuard hat in der Regel weniger CPU-Last und geringere Latenz als OpenVPN, weil es im Kernel-Space läuft und moderne, feste Kryptografie nutzt — was bei kleinen VPS und bei ausgelasteten Leitungen zählt. Der genaue Durchsatz hängt von Ihrer CPU, der MTU und der Pfadqualität zwischen den beiden Standorten ab — messen Sie immer Ihr eigenes Setup. Einen Funktionsvergleich finden Sie in unserem OpenVPN-vs-WireGuard-Deep-Dive.