Woran es meist liegt
Wenn der WireGuard-Tunnel verbunden ist, aber Namen über den Tunnel nicht aufgelöst werden, liegt das Problem fast immer an einer von drei Stellen: Der Client übernimmt den DNS-Server nicht, der VPN-Server verteilt keine passende Route oder der Name soll aufgelöst werden, wird aber ins falsche Netz geschickt. Am schnellsten prüfst du deshalb zuerst, ob die Verbindung nur bei einzelnen Namen scheitert oder ob der gesamte Zugriff auf interne Ziele fehlt. Danach sieht man meist sofort, ob der Fehler im DNS, in den Routen oder in der Gegenstelle steckt.
Wichtig ist die Unterscheidung zwischen Erreichbarkeit und Namenauflösung. Eine IP-Adresse kann über den Tunnel funktionieren, während der zugehörige Hostname scheitert. Genau dieser Unterschied spart viel Zeit, weil du dann nicht am Tunnel selbst suchst, sondern an der DNS-Zuweisung oder an den erlaubten Netzen.
Die erste Prüfung: IP statt Name testen
Beginne mit einem Ziel, das du sonst per Namen öffnest, und teste es zusätzlich über die IP-Adresse. Wenn die IP-Adresse funktioniert, der Name aber nicht, ist der Tunnel grundsätzlich brauchbar und der Fehler sitzt sehr wahrscheinlich bei DNS oder bei der Namensroute. Wenn weder Name noch IP gehen, prüfe zuerst die Tunnelroute, das lokale Netz und die Freigabe auf der Gegenseite.
So gehst du sauber vor:
- Verbinde den WireGuard-Client.
- Prüfe eine interne Adresse, zum Beispiel den Server, den du normalerweise per Hostname erreichst.
- Teste denselben Dienst einmal über den Namen und einmal über die IP-Adresse.
- Notiere, ob nur der Name scheitert oder auch der eigentliche Zugriff.
Diese Trennung ist wichtig, weil sie die nächsten Schritte bestimmt. Ein reines DNS-Problem braucht andere Maßnahmen als eine fehlende Route ins interne Netz.
DNS im WireGuard-Client richtig setzen
Bei vielen Setups reicht es nicht, den Tunnel nur zu verbinden. Der Client muss auch den gewünschten DNS-Server übernehmen. Das geschieht in der Regel über die DNS-Angabe im Peer- oder Tunnelprofil oder über die Systemkonfiguration des Geräts. Wenn der Client weiterhin den bisherigen DNS-Server nutzt, sucht er interne Namen oft am falschen Ort.
Prüfe im Profil des Tunnels, ob ein DNS-Server eingetragen ist, der die internen Namen kennt. Das ist meist dann nötig, wenn du im Heimnetz oder Firmennetz nicht öffentliche Namen, sondern lokale Hostnamen auflösen willst. Fehlt die DNS-Zuweisung, kann die Verbindung zwar stehen, aber der Client fragt weiterhin einen externen Resolver, der deine internen Namen nicht kennt.
Wenn du auf einem Gerät mehrere Netzwerke oder VPNs nutzt, kann zusätzlich die Reihenfolge der DNS-Quellen stören. Dann hilft es, nur einen passenden DNS-Server für den Tunnel zu setzen und andere automatische Vorgaben testweise zu reduzieren. So erkennst du, ob der Tunnel-DNS übernommen wird oder ob das System eine andere Quelle bevorzugt.
Routen prüfen: Wohin der Name überhaupt aufgelöst werden soll
DNS und Routing hängen eng zusammen. Selbst wenn der richtige DNS-Server antwortet, muss der Weg zu diesem Server auch über den Tunnel laufen. Ist die Route zum internen DNS-Server oder zum internen Netz nicht eingetragen, landet die Anfrage außerhalb des Tunnels und scheitert dort.
Für die Prüfung sind zwei Fragen wichtig: Soll der DNS-Server selbst über den Tunnel erreichbar sein, und soll auch das Zielnetz, in dem die internen Dienste liegen, durch den Tunnel gehen? Bei Split-Tunneling muss beides gezielt erlaubt sein. Fehlt nur die Route zum DNS-Server, lösen Namen nicht auf. Fehlt die Route zum Zielnetz, kann der Name vielleicht noch aufgelöst werden, aber der eigentliche Zugriff bricht danach ab.
Achte deshalb auf diese Punkte:
- Ist der interne DNS-Server als erreichbares Ziel im Tunnel vorgesehen?
- Ist das Netz mit den internen Diensten in den erlaubten Routen enthalten?
- Wird der gesamte Verkehr oder nur ein Teilverkehr über den Tunnel geleitet?
- Gibt es eine alternative Route, die den DNS-Verkehr am Tunnel vorbeischickt?
Typische Fehler in der WireGuard-Konfiguration
Ein häufiger Fehler ist ein zu enger Allowed-IPs-Eintrag. Dann weiß der Client zwar, dass der Tunnel existiert, aber nicht, welche Netze darüber erreichbar sein sollen. Das betrifft oft sowohl interne Dienste als auch den DNS-Server selbst. Ebenso problematisch ist ein Profil, das nur die Gegenstelle selbst enthält, aber nicht das eigentliche LAN oder Subnetz dahinter.
Ein weiterer Klassiker ist eine Namensauflösung, die zwar im Tunnelnetz funktionieren sollte, aber auf dem Server nicht weitergereicht wird. Dann antwortet der DNS-Server selbst nur auf einen Teil der Anfragen oder kennt das interne Namensschema nicht. In solchen Fällen hilft es, zu prüfen, ob der verwendete DNS-Server für interne Zonen zuständig ist und ob der Client wirklich genau diesen Server fragt.
Auch ein Mischbetrieb aus IPv4 und IPv6 kann stören. Wenn der Name bevorzugt als IPv6-Adresse aufgelöst wird, die Route dafür aber fehlt, wirkt der Zugriff fehlerhaft, obwohl der Tunnel an sich läuft. Deshalb lohnt sich die Prüfung beider Protokolle getrennt. So erkennst du, ob nur eine Adressfamilie betroffen ist.
Schrittfolge zur Eingrenzung
Wenn du das Problem zügig eingrenzen willst, arbeite in dieser Reihenfolge. So vermeidest du, mehrere Stellschrauben gleichzeitig zu verändern und das Ergebnis unklar zu machen.
- Tunnelstatus prüfen: Ist die Verbindung aktiv und werden Senden und Empfangen gezählt?
- IP-Test durchführen: Funktioniert derselbe interne Dienst über die Adresse?
- DNS-Server kontrollieren: Nutzt der Client wirklich den DNS des Tunnels?
- Route prüfen: Ist das interne Netz über den Tunnel erreichbar?
- Namensraum testen: Löst nur der interne Name nicht auf oder scheitert auch die Weiterleitung?
- IPv4 und IPv6 vergleichen: Tritt der Fehler nur bei einer Protokollfamilie auf?
Diese Reihenfolge hat einen Vorteil: Du findest meist schon nach den ersten drei Schritten heraus, ob ein lokales DNS-Problem vorliegt oder ob die Route zur Gegenstelle fehlt. Dann musst du nicht an allen Parametern gleichzeitig drehen.
So prüfst du den Server oder die Gegenstelle
Auf der Gegenseite muss der DNS-Server die internen Namen tatsächlich kennen. Ein allgemeiner Resolver reicht dafür nicht aus. Wenn der Tunnel ins Heimnetz führt, muss der Router oder ein lokaler DNS-Dienst die internen Namen auflösen können. Bei einem Firmennetz muss die DNS-Zone zu den internen Systemen passen und der Server Anfragen aus dem VPN annehmen.
Ebenso wichtig ist die Freigabe der Rückroute. Selbst wenn der Client die Anfrage richtig sendet, muss die Antwort den Weg zurück durch den Tunnel finden. Fehlt diese Rückroute oder wird das Quellnetz nicht akzeptiert, sieht es aus wie ein DNS-Problem, obwohl die Antwort unterwegs verworfen wird. Prüfe deshalb nicht nur den DNS-Server selbst, sondern auch, ob er Anfragen aus dem VPN-Netz beantworten darf.
Wenn mehrere Netze beteiligt sind, kann es sinnvoll sein, vorübergehend nur ein einziges internes Ziel zu testen. So siehst du schneller, ob die Gegenstelle sauber antwortet oder ob nur einzelne Subnetze fehlen. Das macht die Fehlersuche deutlich übersichtlicher.
Checkliste für einen sauberen Tunnelbetrieb
Bevor du an mehreren Stellen zugleich etwas änderst, lohnt sich diese kurze Kontrolle. Sie verhindert, dass ein funktionierender Teil des Setups versehentlich mitverändert wird.
- Der WireGuard-Tunnel ist aktiv und stabil verbunden.
- Der Client nutzt den DNS-Server, der interne Namen kennt.
- Der interne DNS-Server ist über die Tunnelroute erreichbar.
- Das Zielnetz liegt in den erlaubten Routen.
- IPv4 und IPv6 sind getrennt geprüft.
- Die Gegenstelle beantwortet Anfragen aus dem VPN-Netz.
Was du bei Teilproblemen tun solltest
Wenn nur ein einzelner Name scheitert, liegt der Fehler oft nicht im gesamten Tunnel, sondern in der Namenszone. Dann hilft es, den Namen auf Tippfehler, falsche Endung oder eine fehlende interne Zone zu prüfen. Wenn mehrere interne Namen ausfallen, ist eher der DNS-Server oder die Client-Zuweisung betroffen.
Wenn IP-Verbindungen gehen, aber Namen nicht, ändere zuerst die DNS-Zuweisung und nicht sofort die Tunnelparameter. Wenn dagegen auch die IP-Verbindungen über den Tunnel scheitern, prüfe die Routen und die Erlaubnis der Netze. So arbeitest du von der wahrscheinlichsten Ursache zur aufwendigeren Prüfung, ohne unnötig Einstellungen zu zerstören.
Ein kompletter Rückbau ist meist nicht nötig. In vielen Fällen reicht eine saubere Kombination aus DNS-Server, Route und erlaubtem Zielnetz. Erst wenn diese drei Punkte stimmen und die Auflösung trotzdem scheitert, lohnt sich der Blick auf Spezialfälle wie Split-DNS, IPv6-only-Namen oder eine abweichende Namenszone.
Häufige Fragen zu WireGuard-DNS und fehlender Namensauflösung
Warum funktioniert die Verbindung per IP-Adresse, aber nicht per Hostname?
Dann steht der Tunnel meist grundsätzlich, aber die Namensauflösung läuft über den falschen DNS-Server oder über eine Route, die nicht durch den Tunnel führt. Prüfe zuerst, ob der Hostname nur intern gültig ist und ob dein WireGuard-Profil genau diesen internen DNS-Server verwendet.
Wo trage ich den DNS-Server für WireGuard überhaupt ein?
Das hängt vom Client und vom Betriebssystem ab, aber entscheidend ist immer die Stelle, an der das Profil die Netzwerkinformationen für den Tunnel erhält. Suche nach dem Feld für DNS oder Namensserver im Tunnelprofil und prüfe danach, ob das Gerät die Änderung wirklich übernommen hat.
Kann ein falscher Allowed-IPs-Eintrag die DNS-Auflösung stören?
Ja, denn Allowed IPs bestimmen, welche Netze über den Tunnel geroutet werden. Ist der interne DNS-Server oder das Zielnetz nicht enthalten, verlässt die Anfrage den Tunnel und läuft ins Leere oder zum falschen Netz.
Warum scheitern nur manche interne Namen, andere aber nicht?
Dann liegt das Problem oft an unterschiedlichen Namenszonen oder an IPv4 und IPv6, die nicht gleich behandelt werden. Es kann auch sein, dass nur ein Teil der internen DNS-Zone korrekt eingerichtet ist und andere Namen gar nicht bekannt sind.
Ist Split-Tunneling bei WireGuard ein häufiger Grund für DNS-Probleme?
Ja, weil bei Split-Tunneling nicht automatisch alles durch den Tunnel läuft. Dann musst du den DNS-Server und das Zielnetz gezielt freigeben, sonst bleibt die Namensauflösung außerhalb des VPNs und kennt die internen Namen nicht.
Kann IPv6 die DNS-Suche im Tunnel stören?
Das ist möglich, wenn ein Name bevorzugt als IPv6-Adresse aufgelöst wird, die Route dafür aber fehlt. Teste deshalb IPv4 und IPv6 getrennt, damit du siehst, ob nur eine Adressfamilie betroffen ist.
Wie erkenne ich, ob mein interner DNS-Server überhaupt aus dem VPN erreichbar ist?
Wenn der Hostname nicht aufgelöst wird, die IP des DNS-Servers aber im Tunnel erreichbar sein sollte, liegt meist ein Routingproblem vor. Prüfe, ob die Route zum DNS-Server gesetzt ist und ob der Server Anfragen aus dem VPN-Netz annimmt.
Wann sollte ich die WireGuard-Konfiguration neu anlegen statt weiter zu suchen?
Eine neue Konfiguration lohnt sich erst, wenn DNS, Routen und Zielnetze sauber geprüft wurden und der Fehler trotzdem bleibt. Vorher ist gezieltes Nachbessern sinnvoller, weil ein kompletter Neuaufbau bestehende Zugänge, eigene DNS-Einträge und weitere Tunnelregeln unnötig zurückwerfen kann.
