Gateway
Ein Gateway ist der nächste Knotenpunkt, an den ein Gerät Pakete schickt, wenn es das Ziel nicht direkt im eigenen Netz findet.
Technische Hintergründe
Diese Seite behandelt tiefergehende Themen, die über die Grundlagen hinausgehen. Hier geht es nicht mehr nur darum, was WireGuard ist, sondern darum, warum komplexere Setups manchmal funktionieren, manchmal halb funktionieren und manchmal scheinbar ohne klaren Grund ausfallen.
Die einzelnen Themen sind als eigene Blöcke aufgebaut. Sie müssen nicht alle direkt zusammenhängen, sondern erklären jeweils ein abgeschlossenes Problemfeld.
Einordnung
Die Grundlagen-Seite erklärt die wichtigsten Begriffe und Zusammenhänge. Diese Seite geht tiefer und behandelt einzelne technische Themen ausführlicher.
Die Themen müssen hier nicht alle direkt zusammenhängen. Es geht eher darum, bestimmte Problemstellen aus echten Setups genauer zu erklären.
Besonders Routing, Firewall, Rückwege, statische Routen und mehrere Subnetze werden schnell komplex. Genau deshalb bekommen solche Themen hier einen eigenen Bereich.
Thema 1
Dieses Thema erklärt, wie Datenpakete ihren Weg durch ein Netzwerk finden, warum der Rückweg genauso wichtig ist wie der Hinweg und weshalb komplexe Setups oft genau an dieser Stelle scheitern.
Die folgenden Blöcke gehören zusammen und behandeln einzelne Bausteine dieses Themas.
Routing verstehen
Routing bedeutet vereinfacht: Ein Gerät muss wissen, wohin es ein Paket schicken soll.
Ein Paket hat dabei immer mindestens eine Quelle und ein Ziel. Zum Beispiel:
Quelle: 10.0.0.2 Ziel: 192.168.178.1
Das Gerät fragt dann sinngemäß: „Kenne ich dieses Ziel direkt? Wenn nicht, an welchen Router oder welches Gateway muss ich das Paket weitergeben?“
Ein Gateway ist der nächste Knotenpunkt, an den ein Gerät Pakete schickt, wenn es das Ziel nicht direkt im eigenen Netz findet.
Eine Routing-Tabelle ist wie eine Wegliste. Darin steht, welches Zielnetz über welchen nächsten Knoten erreichbar ist.
Die Default Route ist der Standardweg, wenn keine passendere Route gefunden wird. Im Heimnetz ist das meistens die Fritzbox oder ein anderer Router.
Menschlich erklärt
Stell dir ein Netzwerkpaket wie einen kleinen Brief vor. Dieser Brief trägt wichtige Informationen mit sich:
Beispiel:
Ich bin ein Paket. Ich komme von: 10.0.0.2 Ich möchte zu: 192.168.178.1 Ich komme über: wg0 Mein Ziel liegt im Netz: 192.168.178.0/24
Das Paket trifft jetzt auf einen Router oder eine Firewall und fragt sinngemäß:
Kennst du den Weg zu 192.168.178.1?
Der Router schaut in seine Routing-Tabelle.
Wenn dort eine passende Route steht, wird das Paket weitergeleitet. Wenn keine passende Route vorhanden ist, wird es entweder über die Default Route geschickt oder verworfen.
Der Router sagt sinngemäß: „Ja, dieses Netz kenne ich. Das Paket muss über diesen nächsten Knoten weiter.“
Der Router sagt sinngemäß: „Ich kenne dieses Ziel nicht.“ Dann landet das Paket auf dem Standardweg oder wird verworfen.
Wichtigster Denkfehler
Einer der häufigsten Fehler in komplexeren Setups ist: Die Anfrage kommt an, aber die Antwort findet nicht zurück.
Das sieht dann so aus:
Client → Zielsystem funktioniert Zielsystem → Client funktioniert nicht
Für den Nutzer wirkt das wie:
VPN aktiv ✔ Handshake vorhanden ✔ Ping oder Zugriff geht trotzdem nicht ❌
Der Grund ist oft nicht der WireGuard-Tunnel selbst, sondern ein fehlender Rückweg.
Ein WireGuard-Client mit 10.0.0.2 fragt ein Gerät im Heimnetz an,
zum Beispiel 192.168.178.1.
Das Gerät sieht eine Anfrage von 10.0.0.2.
Wenn es aber keinen Weg zurück zu 10.0.0.2 kennt,
kann es nicht sinnvoll antworten.
Deshalb ist Routing nicht nur für den Weg zum Ziel wichtig, sondern auch für den Rückweg vom Ziel zurück zum Absender.
Statische Routen
Eine statische Route sagt einem Router: „Wenn du zu diesem Zielnetz willst, schick die Pakete an diesen nächsten Knoten.“
Beispiel:
Zielnetz: 10.0.0.0/24 Gateway: 192.168.178.10
Das bedeutet:
Wenn ein Gerät im Netz 192.168.178.0/24 zu einer WireGuard-Adresse
wie 10.0.0.2 antworten will, muss der Router wissen,
dass dieses Netz über 192.168.178.10 erreichbar ist.
Ein Paket fragt die Fritzbox:
„Ich möchte zu 10.0.0.2. Kennst du dieses Netz?“
Wenn die Fritzbox eine passende statische Route hat, sagt sie:
„Ja. Für 10.0.0.0/24 musst du zu 192.168.178.10.“
Wenn diese Route fehlt, weiß die Fritzbox nicht, wohin mit der Antwort.
Genau deshalb funktionieren viele Setups erst dann sauber, wenn nicht nur WireGuard selbst richtig konfiguriert ist, sondern auch die beteiligten Router die relevanten Zielnetze kennen.
Komplexeres Beispiel
Besonders spannend wird es, wenn hinter der Fritzbox noch eine zusätzliche Firewall wie OPNsense steht und dahinter weitere Netze liegen.
Beispiel-Struktur:
Internet ↓ Fritzbox ↓ OPNsense ↓ interne Netze / VLANs
In so einem Setup muss klar sein:
Wenn ein Gerät in einem internen Netz auf einen WireGuard-Client antworten soll, muss der Rückweg bekannt sein.
„Ich bin ein Paket. Ich komme aus dem internen Netz
10.10.20.0/24. Ich möchte zurück zu einem WireGuard-Client
10.0.0.2.“
Das Paket fragt seinen nächsten Router:
„Kennst du den Weg zu 10.0.0.2?“
Wenn der Router eine Route zum WireGuard-Netz kennt, wird weitergeleitet. Wenn nicht, landet das Paket falsch oder wird verworfen.
Daraus entsteht eine wichtige Regel: In komplexeren Netzwerken muss nicht nur der Tunnel korrekt sein. Auch die Router und Firewalls müssen wissen, wo die Netze liegen.
Wichtige Entscheidung
Manchmal wird NAT genutzt, damit Antworten einfacher zurückfinden. Dabei wird die Quelladresse ersetzt, zum Beispiel durch die Adresse des Routers oder Servers.
Das kann Setups vereinfachen, hat aber Nachteile: Das Zielsystem sieht dann nicht mehr die echte ursprüngliche Client-Adresse, sondern nur noch die Adresse des NAT-Geräts.
Einfacher für Rückwege, aber weniger transparent. Das Ziel sieht oft nicht mehr die echte Quelle.
Sauberer und transparenter, aber alle beteiligten Router müssen die Rückwege kennen.
Für saubere Netzwerke ist echtes Routing oft besser. Für einfache oder schnelle Setups kann NAT aber manchmal die pragmatischere Lösung sein.
Zusammenfassung
Wenn ein Zugriff nicht funktioniert, sollte man deshalb nie nur auf WireGuard schauen. Man muss immer prüfen:
1. Tunnel aktiv? 2. AllowedIPs korrekt? 3. Hinweg bekannt? 4. Rückweg bekannt? 5. Firewall erlaubt beide Richtungen? 6. Zielsystem erreichbar?