Steht ein WireGuard-Tunnel, sind aber nur einzelne Geräte oder Netze erreichbar, sollten zuerst die Allowed IPs geprüft werden. Diese Einträge legen fest, welche Zieladressen über den Tunnel laufen und welche Antworten der Client wieder annimmt.
Die gute Nachricht: In vielen Fällen ist kein Defekt vorhanden, sondern nur eine unvollständige oder zu enge Routenangabe. Wer Allowed IPs sauber prüft, findet die Ursache meist schnell – und danach funktionieren die fehlenden Geräte wieder wie erwartet.
Was Allowed IPs in WireGuard wirklich steuern
Allowed IPs sind in WireGuard doppelt wichtig. Einerseits legen sie fest, welche Zielnetze über den Tunnel geschickt werden. Andererseits bestimmen sie auf der Gegenseite, welche Quelladressen ein Peer überhaupt senden darf. Genau das sorgt für Verwirrung, weil dieselbe Einstellung also Routing und Zugriffsregeln beeinflusst.
Wenn nur manche Geräte erreichbar sind, ist das meist ein Zeichen dafür, dass zwar der Tunnel selbst steht, aber das Zielnetz nicht vollständig in den Allowed IPs auftaucht. Dann wird ein Teil des Verkehrs korrekt umgeleitet, ein anderer Teil bleibt draußen und läuft weiter über das normale Netz. Das Ergebnis wirkt auf den ersten Blick seltsam: Ein NAS antwortet, ein Drucker bleibt still, und ein interner Webdienst ist plötzlich nur unter einer bestimmten IP erreichbar.
Besonders häufig tritt das auf, wenn statt eines kompletten Subnetzes nur die einzelne Host-Adresse eingetragen wurde. Ein Eintrag wie 192.168.178.10/32 erlaubt eben nur diesen einen Host, nicht das ganze Heimnetz. Wer mehrere Geräte erreichen will, muss meist das gesamte Zielnetz oder mehrere passende Teilnetze eintragen.
Die erste Diagnose: Tunnel steht, aber Ziele fehlen
Der wichtigste Gedanke ist einfach: Erst prüfen, ob das Problem beim Routing, bei der Firewall oder bei den Allowed IPs sitzt. Ein stabil aufgebauter WireGuard-Handshake sagt noch nichts darüber aus, ob das gewünschte Zielnetz korrekt erreicht wird. Viele verwechseln diese beiden Ebenen und suchen dann an der falschen Stelle.
Hilfreich ist eine kurze Prüf-Reihenfolge. Zuerst den Tunnelstatus ansehen. Dann die Routing-Tabelle prüfen. Danach testen, ob das fehlende Gerät innerhalb desselben Subnetzes liegt wie die funktionierenden Ziele. Erst wenn diese drei Punkte klar sind, lohnt sich der Blick auf Firewallregeln oder NAT.
- Handshake vorhanden, aber nur einzelne Hosts erreichbar: Allowed IPs oder Routing sind verdächtig.
- Handshake vorhanden, Zielnetz vollständig unerreichbar: oft fehlt das Subnetz im Peer-Eintrag.
- Ein Gerät erreichbar, ein anderes im selben Netz nicht: häufig stimmt die Route, aber das Zielgerät oder die Gegenstelle blockiert.
Allowed IPs richtig lesen
Ein WireGuard-Eintrag mit Allowed IPs ist keine bloße Liste von Adressen, sondern eine Routing-Anweisung. Wenn dort 10.10.0.0/24 steht, soll der Verkehr zu diesem Netz über den Peer laufen. Wenn dort 10.10.0.5/32 steht, ist nur genau diese Adresse gemeint. Der Unterschied klingt klein, entscheidet aber oft darüber, ob zwei Geräte funktionieren oder nur eines.
Für den Zugriff auf ein komplettes Heimnetz ist daher meistens ein Subnetz sinnvoll, etwa 192.168.1.0/24. Für ein einzelnes Gerät, das aus Sicherheitsgründen nur gezielt angesprochen werden soll, ist eine Hostroute mit /32 passend. Wer beide Varianten vermischt, bekommt leicht eine halbe Lösung: Der Zugriff auf das NAS klappt, der Drucker mit anderer Adresse aber nicht.
Auch mehrere Netze sind möglich. Liegt etwa das interne Netz des Büros auf 10.0.0.0/24 und ein VLAN auf 10.0.20.0/24, müssen beide Netze in den Allowed IPs stehen, wenn der Client auf beide Bereiche zugreifen soll. Fehlt nur eines, bleibt genau dieser Bereich außen vor.
Typische Fehler in der Praxis
Ein häufiger Irrtum ist die Annahme, dass 0.0.0.0/0 automatisch die beste Wahl sei. Diese Angabe leitet zwar gesamten IPv4-Verkehr durch den Tunnel, ist aber für reine Teilzugriffe oft unnötig und verändert das Verhalten des Clients deutlich. Wer nur ein internes Netz erreichen will, sollte die Allowed IPs eng und sauber halten.
Ein weiterer Klassiker ist ein Adresskonflikt. Wenn das lokale WLAN denselben Adressbereich nutzt wie das entfernte Netz, weiß der Client nicht mehr, wohin er Pakete schicken soll. Dann sieht die Verbindung zwar aktiv aus, aber Anfragen landen im falschen Netz. Solche Überschneidungen sind tückisch, weil sie nicht immer sofort komplett ausfallen, sondern nur einzelne Ziele betreffen.
Auch ein falsches IPv6-Setup kann genau dieses Bild erzeugen. Viele Systeme haben IPv4 und IPv6 parallel aktiv, aber nur eine Seite wurde in den Allowed IPs gepflegt. Dann funktioniert der Zugriff auf einen Dienst über IPv4, während ein anderes Gerät nur über seine IPv6-Adresse erreichbar wäre und damit außen vor bleibt.
So prüfst du die Einträge systematisch
Am saubersten gehst du von außen nach innen vor. Zuerst klären, welche Zieladressen tatsächlich erreichbar sein sollen. Dann prüfen, welche Subnetze diese Geräte verwenden. Danach den Peer-Eintrag mit genau diesen Netzen abgleichen. Wenn die Zielgeräte in verschiedenen Netzen liegen, müssen alle relevanten Netze vorkommen.
Ein sinnvoller Ablauf sieht oft so aus:
- Die IP-Adresse des funktionierenden und des nicht funktionierenden Geräts vergleichen.
- Prüfen, ob beide Geräte im gleichen Subnetz liegen.
- Im WireGuard-Profil nachsehen, ob genau dieses Subnetz in Allowed IPs steht.
- Falls nötig, zusätzliche Netze ergänzen oder eine feiner abgestufte Route setzen.
- Danach die Verbindung neu laden und den Zugriff erneut testen.
Wenn du danach immer noch nur einzelne Geräte erreichst, ist der nächste Verdacht die Gegenseite. Dann kann zwar die Route stimmen, aber das entfernte Netzwerk lässt den Verkehr nicht zurück oder leitet ihn nicht korrekt weiter.
Was auf der Gegenseite oft übersehen wird
Allowed IPs auf dem Client reichen allein nicht immer aus. Auf dem Server oder Router muss der Peer ebenfalls so eingetragen sein, dass die Rückwege stimmen. WireGuard ist in dieser Hinsicht streng: Ein Client darf nur die Adressen senden, die auf der Gegenseite in seinen Allowed IPs erlaubt sind. Fehlt dort das richtige Quellnetz, kommt keine saubere Antwort zurück.
Gerade bei Site-to-Site-Aufbauten wird das schnell unübersichtlich. Der Heimrouter kennt dann vielleicht das interne Netz des Servers, aber der Server kennt das lokale Heimnetz des Clients nicht vollständig. Ohne korrekte Gegenrichtung geht die Anfrage zwar raus, die Antwort findet aber den Weg nicht sauber zurück.
Bei einem klassischen Remote-Zugriff auf das Heimnetz sollte die Gegenseite typischerweise das VPN-Adressnetz des Clients und das Heimnetz selbst kennen. Bei mehreren VLANs oder mehreren Standorten müssen alle beteiligten Netze berücksichtigt werden. Wer nur die sichtbare Oberfläche betrachtet, übersieht leicht die Rückroute, und genau dort steckt oft der eigentliche Fehler.
Wenn ein einzelnes Gerät stur bleibt
Manchmal ist nur ein bestimmtes Gerät nicht erreichbar, obwohl das restliche Netz funktioniert. Dann lohnt sich ein Blick auf die eigene IP-Konfiguration dieses Geräts. Ein NAS, ein Drucker oder ein Smart-Home-Hub kann eine statische Adresse haben, die zwar im gleichen Bereich liegt, aber durch eine andere Maske, ein anderes Gateway oder eine eigene Firewall aus dem Rahmen fällt.
Auch lokale Sicherheitsregeln spielen mit hinein. Ein Windows-PC kann Dateifreigaben im VPN blocken, ein Drucker akzeptiert nur bestimmte Subnetze, und ein NAS filtert Zugriffe nach Interface oder Quellnetz. Die Allowed IPs sind dann richtig, aber das Zielgerät selbst winkt den Verkehr ab.
Genau deshalb ist ein Test mit zwei Ebenen sinnvoll. Erst Ping oder DNS-Auflösung auf Netzwerkebene prüfen, dann den eigentlichen Dienst testen, also etwa Weboberfläche, SMB-Freigabe oder Verwaltungsport. Erreichbarkeit im Netz und Zugriff auf den Dienst sind zwei verschiedene Dinge.
Wenn DNS mitspielt, aber das Gerät trotzdem fehlt
Ein funktionierender Name bedeutet noch nicht, dass die Route stimmt. Wenn ein Hostname aufgelöst wird, der Zugriff aber scheitert, ist DNS zwar im Spiel, aber die Transportebene bleibt verdächtig. Dann lohnt es sich, dieselbe Zieladresse direkt per IP anzusprechen. So lässt sich trennen, ob Namensauflösung oder Routing den Fehler verursacht.
Umgekehrt kann ein Gerät per IP erreichbar sein, während der Name nicht funktioniert. Das wirkt dann ähnlich wie ein Routingproblem, ist aber oft ein DNS-Thema im Tunnel oder im Heimnetz. Besonders bei mehreren Netzen, internen Domänen oder Pi-hole-ähnlichen Setups entstehen solche Mischbilder recht leicht.
Wenn nur per Hostname Probleme bestehen, gehören die Allowed IPs nicht unbedingt auf die Anklagebank. Dann ist eher zu prüfen, welcher DNS-Server im VPN genutzt wird und ob der Client den internen Namensraum überhaupt kennt.
Unterschied zwischen Full-Tunnel und Split-Tunnel
Der Zugriff auf einzelne Geräte funktioniert oft in einem Split-Tunnel sauberer und nachvollziehbarer. Dabei werden nur bestimmte Netze über WireGuard geroutet. Das spart Fehlersuche, weil der restliche Internetverkehr unverändert bleibt und die Tunnelregeln klein und übersichtlich bleiben.
Beim Full-Tunnel wird dagegen alles durch den VPN-Tunnel geleitet. Das ist für manche Einsatzzwecke sinnvoll, kann aber die Diagnose erschweren. Wenn dann nur manche Geräte erreichbar sind, ist die Ursache oft in einer Mischung aus Allowed IPs, DNS und Gegenstellen-Routing zu finden.
Wer gerade mit WireGuard arbeitet und nur das Heimnetz erreichen will, fährt häufig mit einem klaren Split-Tunnel besser. Dann gehören nur die internen Netze in die Allowed IPs, etwa das Heimnetz, ein Servernetz und gegebenenfalls ein separates Verwaltungsnetz. Alles andere bleibt außen vor und macht die Fehlersuche leichter.
So findest du die passende Netzmaske
Die Netzmaske entscheidet darüber, wie groß der erlaubte Adressbereich ist. Eine /32 steht für genau eine IP-Adresse. Eine /24 deckt ein ganzes klassisches Heimnetz ab. Wer ein /24 einträgt, erlaubt also deutlich mehr als bei einer Einzeladresse.
Praktisch bedeutet das: Wenn dein NAS auf 192.168.178.50 liegt und der Drucker auf 192.168.178.60, dann reicht eine einzelne /32-Angabe nicht aus, um beide Geräte zu erreichen. Mit 192.168.178.0/24 wäre der komplette Bereich abgedeckt, sofern dieses Netz wirklich das Zielnetz ist.
Wichtig ist, nicht blind ein größeres Netz einzutragen, nur damit es wieder läuft. Ein zu breiter Bereich kann mehr freigeben als beabsichtigt. Gerade bei sensiblen Netzen lohnt sich ein genauer Blick auf die tatsächliche Adressierung im Heimnetz oder Firmennetz.
Wenn der Router der eigentliche Flaschenhals ist
Manche Setups laufen nicht direkt auf einem Server, sondern auf einem Router oder einer Firewall. Dann muss der Router den Verkehr nicht nur annehmen, sondern auch ins interne Netz weiterleiten. Fehlen dort statische Routen, NAT-Regeln oder Freigaben für das VPN-Subnetz, wirkt es wieder so, als wären nur manche Geräte erreichbar.
Besonders häufig passiert das bei mehreren internen Netzen. Der Router kennt dann zwar das Hauptnetz, aber nicht das VLAN für Kameras, nicht das Gastnetz oder nicht das Verwaltungsnetz. In so einem Fall sieht der WireGuard-Tunnel aus Anwendersicht aktiv aus, doch einzelne Bereiche bleiben trotzdem unerreichbar.
Bei Routern sollte außerdem geprüft werden, ob lokale Firewallregeln zwischen den Segmenten den Verkehr blockieren. Viele Geräte behandeln VPN-Verkehr wie Verkehr aus einem fremden Netz und greifen dann auf strenge Filterregeln zurück.
Wenn die Lösung in kleinen Schritten liegt
Oft reicht schon eine saubere Reihenfolge, um das Problem zu lösen. Erst die Zielnetze notieren, dann die tatsächlichen IP-Bereiche der Geräte vergleichen, anschließend die Allowed IPs anpassen und zuletzt die Gegenstelle kontrollieren. Danach den Tunnel neu aufbauen und testen, ob die fehlenden Geräte jetzt auftauchen.
Diese Reihenfolge klingt schlicht, spart aber viel Zeit. Wer erst am Client, dann am Server und dann wieder am Router wild herumändert, verliert leicht den Überblick. Mit einer klaren Abfolge bleibt nachvollziehbar, welche Änderung welche Wirkung hatte.
Ein sauberer Blick auf Sicherheit
Allowed IPs sind auch ein Sicherheitswerkzeug. Wer dort nur die wirklich benötigten Netze einträgt, begrenzt die Reichweite des Tunnels. Das ist oft besser als großzügige Sammelregeln, die zwar bequem wirken, aber deutlich mehr Vertrauen voraussetzen.
Gerade bei Zugriffen auf Heimnetz, Bürogeräte oder Verwaltungsoberflächen lohnt sich Zurückhaltung. Ein VPN soll ermöglichen, was gebraucht wird, und nicht automatisch das gesamte Netz öffnen. Wenn später ein weiteres Gerät benötigt wird, kann das passende Zielnetz gezielt ergänzt werden.
Wer mit mehreren Nutzern arbeitet, sollte außerdem Peer für Peer getrennt pflegen. Dann bleibt nachvollziehbar, welcher Zugriff für welches Gerät gilt. Das hilft nicht nur bei der Fehlersuche, sondern auch bei der späteren Pflege der Konfiguration.
Wenn nach der Korrektur noch etwas fehlt
Bleibt ein Gerät trotz passender Allowed IPs unerreichbar, ist der nächste Verdacht meist außerhalb von WireGuard. Dann geht es um die Firewall des Zielgeräts, um das Gateway, um DNS oder um eine fehlende Rückroute. Der Tunnel ist dann nur der Überbringer der schlechten Nachricht, nicht die eigentliche Ursache.
Auch MTU-Probleme können merkwürdige Teil-Ausfälle erzeugen. Kleine Pakete kommen an, größere Anfragen versanden. Das fällt oft erst auf, wenn Webseiten halb laden oder bestimmte Dienste nur sporadisch antworten. In solchen Fällen muss man die VPN-Einstellungen und die Netzpfade noch einmal genauer ansehen.
Die beste Strategie bleibt deshalb: erst den Adressbereich prüfen, dann Routing und Gegenstelle, danach Firewall und DNS. Mit dieser Reihenfolge trennst du die häufigsten Fehler sauber voneinander und kommst ohne Rätselraten ans Ziel.
Zwischenstand für die Fehlersuche
Wenn WireGuard verbindet, aber nur manche Geräte erreichbar sind, steckt sehr oft eine unvollständige Allowed-IP-Konfiguration dahinter. Die richtige Netzmaske, die passende Gegenroute und ein Blick auf Firewall und DNS lösen den Fall in vielen Setups schnell auf.
Wer Netze sauber trennt und die erlaubten Ziele eng, aber vollständig definiert, bekommt in der Regel ein stabiles Ergebnis. Genau dort liegt der Kern der Sache: nicht mehr Freigabe als nötig, aber auch nicht zu wenig für die Geräte, die wirklich erreichbar sein sollen.
Häufige Fragen
Warum erreicht der Tunnel nur einzelne Geräte im Zielnetz?
In vielen Fällen stimmt die Gegenroute nicht oder die Allowed IPs auf einer Seite sind zu eng gesetzt. Dann baut WireGuard die Verbindung zwar auf, leitet Verkehr aber nur für die Netze weiter, die tatsächlich eingetragen sind.
Woran erkenne ich, ob die Einträge auf dem Client zu knapp sind?
Ein Blick auf die konfigurierten Netze zeigt schnell, ob nur ein einzelner Host oder ein kleiner Adressbereich erlaubt wurde. Steht dort etwa nur eine /32-Route für ein Gerät, bleiben andere Systeme im selben Netz unerreichbar.
Welche Rolle spielt die Gegenseite bei der Erreichbarkeit?
Die entfernte Seite muss den Rückweg zum Tunnel kennen. Ohne passende Route oder Freigabe schickt sie Antworten an das falsche Interface zurück, und der Verbindungsaufbau wirkt nur halb fertig.
Wie prüfe ich die Allowed IPs systematisch?
Vergleiche zuerst das Zielnetz mit dem Eintrag in der WireGuard-Konfiguration. Danach kontrollierst du, ob auf beiden Seiten dieselben Netze gemeint sind und ob sich keine Subnetze überschneiden, die den Verkehr umlenken.
Was ist der Unterschied zwischen Host- und Netzfreigaben?
Ein Host-Eintrag erlaubt nur eine einzelne IP-Adresse, ein Netz-Eintrag mehrere Adressen innerhalb eines Subnetzes. Für ganze LANs brauchst du deshalb meist die Netzangabe und nicht nur ein einzelnes Ziel.
Welche Befehle helfen bei der Fehlersuche?
Mit einer Routenanzeige und einem Ping auf verschiedene Ziele lässt sich schnell eingrenzen, wo Pakete hängen bleiben. Ergänzend zeigen Protokolle der Firewall oder des Routers, ob Verbindungen ankommen und wieder herausgehen.
Warum funktioniert DNS, obwohl andere Geräte fehlen?
DNS löst nur Namen in Adressen auf und beweist noch keinen funktionierenden Weg zum Ziel. Es kann also sein, dass ein Name antwortet, die Route zum eigentlichen Gerät aber weiterhin fehlt.
Welche Fehler machen Router in solchen Setups häufig?
Oft fehlt dort eine statische Route zurück ins WireGuard-Netz oder eine Firewall-Regel blockiert das Weiterleiten. Auch doppelte Adressbereiche zwischen Heimnetz und VPN führen schnell zu unklaren Wegen.
Wie gehe ich vor, wenn nur ein einzelnes Gerät nicht erreichbar bleibt?
Prüfe zuerst, ob dieses Gerät eine eigene Firewall aktiviert hat oder in einem anderen VLAN sitzt. Danach kontrollierst du, ob seine IP-Adresse in den Allowed IPs der Gegenstelle wirklich enthalten ist und ob der Rückweg stimmt.
Wann lohnt sich ein Vergleich mit mehreren Geräten im selben Netz?
Sobald ein Teil der Clients erreichbar ist, lässt sich damit gut erkennen, ob das Problem an der Zieladresse oder am gesamten Netz liegt. Unterschiedliche Ergebnisse innerhalb desselben Subnetzes zeigen oft, dass nur ein Teil der Route oder der Freigaben passt.
Wie sichere ich die Konfiguration nach der Korrektur ab?
Nach jeder Änderung solltest du die Verbindung neu aufbauen und mehrere Ziele testen, nicht nur das eine erfolgreiche System. Erst wenn Ping, SSH oder die benötigte Anwendung über unterschiedliche Geräte hinweg funktionieren, ist die Freigabe sauber gesetzt.
