3
DNS-Request bei WireGuard u. OPNsense als DNS-Server
Hallo,
ich habe wahrscheinlich ein Layer 8 Problem, woran ich echt am verzweifeln bin.
Folgendes Problem:
DNS-Requests werden im Netzwerk wie folgt behandelt: Client -> AdGuard Home:53 -> OPNsense router:5353 -> QuadDNS über Forwarding (AdGuard Home & WireGuard sind als Dienst in OPNsense installiert). So lassen sich eigene Unbound DNS-Einträge für das Heimnetz betreiben und unerwünschte Anfrage direkt blockieren. Das funktioniert im Netzwerk soweit ganz gut.
Doch sobald eine WireGuard-Verbindung etabliert wird, funktioniert dies für den WG-Client nicht mehr.
Gemäß AdGuard-Log wurde die Anfrage bearbeitet. Im Livelog der OPNsense Firewall wurde nichts geblockt. Daher vermute ich dennoch, das wahrscheinlich entweder ein routingfehler besteht oder die Firewall die Antwort des DNS-Request nicht an den Client über VPN richtig zurück sendet. Die Dienste lassen sich über die IP jedoch problemlos erreichen.
Hier die WireGuard Client Config:
Hat jemand eine Idee, was ich hätte vllt noch einstellen müssen?
Die Bilder zeigen alle Settings mal auf. Sollte aber noch weitere Informationen benötigt werden, so kann ich diese nachreichen.
Lg
ich habe wahrscheinlich ein Layer 8 Problem, woran ich echt am verzweifeln bin.
Folgendes Problem:
DNS-Requests werden im Netzwerk wie folgt behandelt: Client -> AdGuard Home:53 -> OPNsense router:5353 -> QuadDNS über Forwarding (AdGuard Home & WireGuard sind als Dienst in OPNsense installiert). So lassen sich eigene Unbound DNS-Einträge für das Heimnetz betreiben und unerwünschte Anfrage direkt blockieren. Das funktioniert im Netzwerk soweit ganz gut.
Doch sobald eine WireGuard-Verbindung etabliert wird, funktioniert dies für den WG-Client nicht mehr.
Gemäß AdGuard-Log wurde die Anfrage bearbeitet. Im Livelog der OPNsense Firewall wurde nichts geblockt. Daher vermute ich dennoch, das wahrscheinlich entweder ein routingfehler besteht oder die Firewall die Antwort des DNS-Request nicht an den Client über VPN richtig zurück sendet. Die Dienste lassen sich über die IP jedoch problemlos erreichen.
Hier die WireGuard Client Config:
[Interface]
PrivateKey =
Address = 10.11.11.2/32
DNS = 192.168.0.1
[Peer]
PublicKey =
AllowedIPs = 192.168.0.0/25
Endpoint = domain.de:123
PersistentKeepalive = 25Hat jemand eine Idee, was ich hätte vllt noch einstellen müssen?
Die Bilder zeigen alle Settings mal auf. Sollte aber noch weitere Informationen benötigt werden, so kann ich diese nachreichen.
Lg
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6900924632
Url: https://administrator.de/forum/dns-request-bei-wireguard-u-opnsense-als-dns-server-6900924632.html
Ausgedruckt am: 22.04.2025 um 12:04 Uhr
3 Kommentare
Neuester Kommentar
Zuerst einmal solltest du deinen Kardinalsfehler in der Wireguard IP Adressierung und in den Allowed IPs korrigieren. Die ist komplett falsch.
Die interne Wireguard IP Adresse hat niemals einen 32er Hostprefix sondern immer die Maske die du intern vergeben hast. Zum zweiten fehlt in den Allowed IPs die Wireguard Server IP! Hier kommt dann wieder deine 32er Hostmaske ins Spiel.
Dadurch schlägt bei dir das Crypto Routing fehl was dann vermutlich die DNS Folgefehler triggert.
Einmal das hiesige Wireguard Tutorial wirkklich lesen und verstehen, dann sollten solche groben Anfängerfehler nicht passieren.
Wie die korrekte Wireguard Konfig bei pfSense und OPNsense, insbesondere die Interface und Routen Zuweisung, auszusehen hat kannst du HIER und auch HIER nachlesen.
Der dritte Fehler ist die Vergabe von 5353 als DNS Port. Solche fest reservierten IANA Ports zu wählen sind nicht gerade intelligent, ganz besonders nicht 5353, denn das wird im Netz von mDNS / Bonjour genutzt was dann weitere DNS Probleme triggert.
Sinnvoll ist hier immer die freien Ephemeral Ports zu verwenden zwischen 49152 und 65535. Also z.B. 53535!
Der 4te Fehler ist die für VPN Betrieb nicht besonders intelligent gewählte IP Adressierung. Mit dem Allerweltsnetz 192.168.0.0 wirst du sehr schnell Schiffbruch erleiden. Warum das so ist kannst du HIER nachlesen!
Wenn du all diese grundlegenden Fehler bereinigt hast kannst du dein DNS Verhalten im Wireguard Client testen mit den klassischen Tools nslookup oder dig. Hatten wir erst kürzlich hier...
Wenn dein Wireguard Tunnel aktiv ist fragst du einen DNS Namen ab wie z.B. nslookup www.heise.de. nslookup zeigt dir dann welchen Server es fragt und wie das Ergebnis ist.
Du kannst auch die Abfrage bei einem dedizierten Server erzwingen. nslookup www.heise.de 9.9.9.9 erzwingt z.B. die Abfrage bei Quad9.
Du kannst damit dann die Abfrage bei deinem DNS Server mit nslookup www.heise.de <wg_tunnel-ip_opnsense> erreichen. Statt der WG Tunnel IP kannst du natürlich auch die LAN IP nehmen.
Die interne Wireguard IP Adresse hat niemals einen 32er Hostprefix sondern immer die Maske die du intern vergeben hast. Zum zweiten fehlt in den Allowed IPs die Wireguard Server IP! Hier kommt dann wieder deine 32er Hostmaske ins Spiel.
Dadurch schlägt bei dir das Crypto Routing fehl was dann vermutlich die DNS Folgefehler triggert.
Einmal das hiesige Wireguard Tutorial wirkklich lesen und verstehen, dann sollten solche groben Anfängerfehler nicht passieren.
Wie die korrekte Wireguard Konfig bei pfSense und OPNsense, insbesondere die Interface und Routen Zuweisung, auszusehen hat kannst du HIER und auch HIER nachlesen.
Der dritte Fehler ist die Vergabe von 5353 als DNS Port. Solche fest reservierten IANA Ports zu wählen sind nicht gerade intelligent, ganz besonders nicht 5353, denn das wird im Netz von mDNS / Bonjour genutzt was dann weitere DNS Probleme triggert.
Sinnvoll ist hier immer die freien Ephemeral Ports zu verwenden zwischen 49152 und 65535. Also z.B. 53535!
Der 4te Fehler ist die für VPN Betrieb nicht besonders intelligent gewählte IP Adressierung. Mit dem Allerweltsnetz 192.168.0.0 wirst du sehr schnell Schiffbruch erleiden. Warum das so ist kannst du HIER nachlesen!
Wenn du all diese grundlegenden Fehler bereinigt hast kannst du dein DNS Verhalten im Wireguard Client testen mit den klassischen Tools nslookup oder dig. Hatten wir erst kürzlich hier...
Wenn dein Wireguard Tunnel aktiv ist fragst du einen DNS Namen ab wie z.B. nslookup www.heise.de. nslookup zeigt dir dann welchen Server es fragt und wie das Ergebnis ist.
Du kannst auch die Abfrage bei einem dedizierten Server erzwingen. nslookup www.heise.de 9.9.9.9 erzwingt z.B. die Abfrage bei Quad9.
Du kannst damit dann die Abfrage bei deinem DNS Server mit nslookup www.heise.de <wg_tunnel-ip_opnsense> erreichen. Statt der WG Tunnel IP kannst du natürlich auch die LAN IP nehmen.
Zitat von @aqui:
Zuerst einmal solltest du deinen Kardinalsfehler in der Wireguard IP Adressierung und in den Allowed IPs korrigieren. Die ist komplett falsch.
Die interne Wireguard IP Adresse hat niemals einen 32er Hostprefix sondern immer die Maske die du intern vergeben hast. Zum zweiten fehlt in den Allowed IPs die Wireguard Server IP! Hier kommt dann wieder deine 32er Hostmaske ins Spiel.
Dadurch schlägt bei dir das Crypto Routing fehl was dann vermutlich die DNS Folgefehler triggert.
Einmal das hiesige Wireguard Tutorial wirkklich lesen und verstehen, dann sollten solche groben Anfängerfehler nicht passieren.
Wie die korrekte Wireguard Konfig bei pfSense und OPNsense, insbesondere die Interface und Routen Zuweisung, auszusehen hat kannst du HIER und auch HIER nachlesen.
Danke für die Links, diese hatte ich mir auch angeschaut gehabt und soweit möglich gefolgt. Leider gab es in der Doku ein paar ungereimtheiten. So zB die 100.64.64.100/32 auf der Serverseite, bei der "windows server" dann nur 100.64.64.0/24 angezeigt wurde. Das ist leicht verwirrend (woher die 100 am ende?)Zuerst einmal solltest du deinen Kardinalsfehler in der Wireguard IP Adressierung und in den Allowed IPs korrigieren. Die ist komplett falsch.
Die interne Wireguard IP Adresse hat niemals einen 32er Hostprefix sondern immer die Maske die du intern vergeben hast. Zum zweiten fehlt in den Allowed IPs die Wireguard Server IP! Hier kommt dann wieder deine 32er Hostmaske ins Spiel.
Dadurch schlägt bei dir das Crypto Routing fehl was dann vermutlich die DNS Folgefehler triggert.
Einmal das hiesige Wireguard Tutorial wirkklich lesen und verstehen, dann sollten solche groben Anfängerfehler nicht passieren.
Wie die korrekte Wireguard Konfig bei pfSense und OPNsense, insbesondere die Interface und Routen Zuweisung, auszusehen hat kannst du HIER und auch HIER nachlesen.
Der dritte Fehler ist die Vergabe von 5353 als DNS Port. Solche fest reservierten IANA Ports zu wählen sind nicht gerade intelligent, ganz besonders nicht 5353, denn das wird im Netz von mDNS / Bonjour genutzt was dann weitere DNS Probleme triggert.
Sinnvoll ist hier immer die freien Ephemeral Ports zu verwenden zwischen 49152 und 65535. Also z.B. 53535!
Abgesehen davon, das dass im Netz so ohne weiteres funktioniert hat, hat es als ergebnis grundlegend nichts geändert. Jedoch vielen dank für den Hinweis, auch wenn 5353 im netz so nicht verwendet wird.Sinnvoll ist hier immer die freien Ephemeral Ports zu verwenden zwischen 49152 und 65535. Also z.B. 53535!
Der 4te Fehler ist die für VPN Betrieb nicht besonders intelligent gewählte IP Adressierung. Mit dem Allerweltsnetz 192.168.0.0 wirst du sehr schnell Schiffbruch erleiden. Warum das so ist kannst du HIER nachlesen!
Du hast da vollkommen Recht, auch wenn die 192.168.0.0/24 bei mir nur als Beispiel angegeben ist und dies zum Fehler garnichts beiträgt, da der Client aktuell z.B. in einem 192.168.1.0/24 netz hängt. Aber dieser einwand berechtigt und hätte durchaus auch ein grund des fehlers sein können.Wenn du all diese grundlegenden Fehler bereinigt hast kannst du dein DNS Verhalten im Wireguard Client testen mit den klassischen Tools nslookup oder dig. Hatten wir erst kürzlich hier...
Wenn dein Wireguard Tunnel aktiv ist fragst du einen DNS Namen ab wie z.B. nslookup www.heise.de. nslookup zeigt dir dann welchen Server es fragt und wie das Ergebnis ist.
Du kannst auch die Abfrage bei einem dedizierten Server erzwingen. nslookup www.heise.de 9.9.9.9 erzwingt z.B. die Abfrage bei Quad9.
Du kannst damit dann die Abfrage bei deinem DNS Server mit nslookup www.heise.de <wg_tunnel-ip_opnsense> erreichen. Statt der WG Tunnel IP kannst du natürlich auch die LAN IP nehmen.
Habe ich getestet gehabt und über den WG-Tunnel kann der DNS-Server nicht erreicht werden (welch Ironie da ich ja Zeitgleich über IP auf OPNsense zugreifen konnte)Wenn dein Wireguard Tunnel aktiv ist fragst du einen DNS Namen ab wie z.B. nslookup www.heise.de. nslookup zeigt dir dann welchen Server es fragt und wie das Ergebnis ist.
Du kannst auch die Abfrage bei einem dedizierten Server erzwingen. nslookup www.heise.de 9.9.9.9 erzwingt z.B. die Abfrage bei Quad9.
Du kannst damit dann die Abfrage bei deinem DNS Server mit nslookup www.heise.de <wg_tunnel-ip_opnsense> erreichen. Statt der WG Tunnel IP kannst du natürlich auch die LAN IP nehmen.
!!! Letzendlich fand ich den Fehler. Dieser lag daran, das ich der wg-interface keine IP zugewiesen hatte. Das passiert sehr schnell, wenn man Dokus doch blind folgt (Gemäß offizieller Doku sollte bei IPv4 none stehen siehe hier. Dank aber den denkanstößen zum konnte ich den Fehler doch finden und es funktioniert jetzt.
Daher vielen dank für die Unterstützung
Das ist leicht verwirrend (woher die 100 am ende?)
Dafür gibt es eine einfache und logische Erklärung... 😉Das interne WG Netz ist ein /24 Netz, sprich also mit möglichen Hostadressen von .1 bis .254.
Der Übersicht halber wurde der Server auf die .1 gesetzt und die Clients fangen bei 100 an um sie schön durchnummerierbar anhand ihrer IP Adressen .101 bis .1XY zu erkennen und identifizieren zu können. Das war die Intention dabei... Etwas "Adress Kosmetik" erleichtert immer das Admin Leben.
Danke für den Hinweis! Wird im Tutorial verbessert um das zu klären!
Gemäß offizieller Doku sollte bei IPv4 none stehen
Nicht wenn man die deutlich bessere Doku der pfSense zum Vergleich liest. Sollte einem aber auch der IT Verstand sagen da es bei Wireguard ja immer ein internes Interface gibt so das man dies zwingend im Interface Assignment auch hinzufügt und adressiert! Siehe dazu auch HIER.https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/assign.html
konnte ich den Fehler doch finden und es funktioniert jetzt.
👍
