Beantwortet: pfsense+PP -> plötzlich "ERR_NAME_RESOLUTION_FAILED"

Wall-E

Active Member
Hallo!
Ich nutze seit drei, vier Jahren Perfect Privacy auf pfsense.
Vor einigen wenigen Wochen war plötzlich normales surfen (mit dem Browser) nicht mehr möglich, je nach Browser kam: "ERR_NAME_RESOLUTION_FAILED".
Ich prüfte das Übliche:
Internetzugang ok; PP ok; "alter Router am Netz" ok; ich änderte mal die DNS Server in pfsense... keine Veränderung; machte ein Update auf 2.4.4-RELEASE-p1, spielte ein Backup ein... und nach einigen Wochen mit meinem "Notfall-Router" - ich hatte keine Zeit mich drum zu kümmern - machte ich mich heute daran, pfsense von Grund auf mit der aktuellen Version und der Anleitung von PP neu zu installieren... (natürlich funktionierte pfsense nach der Neuinstallation und ohne PP einwandfrei!).

Nun habe ich gerade mal den ersten PP-Server konfiguriert, neu gestartet und was kommt....... "ERR_NAME_RESOLUTION_FAILED". In pfsense stehen alle Verbindungen und alles sieht einwandfrei aus, so dass es an dem besagten Problem liegen muss.

Hat jemand irgend eine Ahnung, was sich da plöltzlich geändert haben könnte?
Würde ja mit einer älteren pfsense Version testen - über "Dritte" - bekommt man die sicher noch (pfsense selbst stellt keine früheren Versionen mehr zu Verfügung), aber ich glaube nicht, dass das etwas bringt.

Noch ein Hinweis:
Wenn ich den DNS - Server im jeweiligen Gerät manuell eintrage, funktioniert die Verbindung; (d.h. bei Windows z.B. "IP-Adresse automatisch beziehen: JA, DNS-Server automatisch beziehen: NEIN (sondern manuell eingeben)".
Von daher weiß ich auch, dass die DNS-Server, dich in in pfsense eingetragen habe, funktionieren und als Fehlerquelle ausgeschlossen werden können.

Es wäre wirklich tot traurig, wenn PP nicht mehr über pfsense nutzbar wäre...
Mich wundert nur, dass ich sonstwo nix über das Problem gelesen habe :(

Vllt. weiß jemand Rat?

Danke!
 
Solution
Hallo. Ich habe das Problem in einer virtuellen pfsense nachvollziehen können und etwas Interessantes herausgefunden.

Wenn der auf dem VPN-Server für Trackstop eingesetzte powerdns-recursor die lokale Kopie der Root-Zone als Forwarder konfiguriert hat, antwortet er auf nicht-rekursive Queries mit "FORMERR". Das ist nicht richtig und ist ein Bug in powerdns, der in Debian noch nicht behoben ist. Im Monitoring fällt soetwas nicht auf, da dort rekursive Queries verwendet werden.

(die lokale Root-Zone haben wir, damit nicht sinnlose Queries für HansMeier-PC23.privat o.ä. durchs Internet gehen müssen)

Wenn powerdns wieder selber die Root-NS befragen darf, antwortet es korrekt mit "NOERROR".
unbound auf der pf-sense klagt zwar ein...
UPDATE: Habe jetzt - mit der absoluten Grundkonfiguration von pfsense/pp (d.h. exakt bis zum letzten Schritt der Anleitung, nicht mehr, nicht weniger) - beim herumspielen etwas herausgefunden:
Ich habe DNS-Auflösung deaktiviert und DNS-Weiterleitung aktiviert (letzteres zu aktivieren ging nur, wenn der Auflöser deaktiviert ist).
Jetzt geht auch ohne lokal konfiguriertem DNS - sondern "automatisch" - der Webseitenzugriff.
Ich weiß allerdings NICHT, ob das am Ende meiner Konfiguration (mehrere PP-Server, Fallback, eine Schnittstelle ohne PP...) das auch noch geht.
ich habe auch keine Ahnung, was die beiden Optionen bewirken, Vor- und Nachteile haben, etc.....
 
Nun habe ich gerade mal den ersten PP-Server konfiguriert, neu gestartet und was kommt....... "ERR_NAME_RESOLUTION_FAILED".
.
.
.
.
Mich wundert nur, dass ich sonstwo nix über das Problem gelesen habe :(

Ich habe mal in Google ERR_NAME_RESOLUTION_FAILED "vpn" eingegeben und viele Internetseiten gefunden, bei denen die Benutzer über diese Fehlermeldung in Verbindung mit VPN berichtet haben.
Es gab aber keine bestimmte Lösungen. In den meisten Fällen lag es am Netzwerk des Betriebssystems und nicht am VPN.

Noch ein Hinweis:
Wenn ich den DNS - Server im jeweiligen Gerät manuell eintrage, funktioniert die Verbindung; (d.h. bei Windows z.B. "IP-Adresse automatisch beziehen: JA, DNS-Server automatisch beziehen: NEIN (sondern manuell eingeben)".

Wie soll ich das verstehen? Hast du in Windows unter Netzwerkkonfiguration die DNS Server eingetragen?

Ansonsten, falls du Windows benutzt, dann würde ich die Option1 von dieser Anleitung versuchen.
 
Wie soll ich das verstehen? Hast du in Windows unter Netzwerkkonfiguration die DNS Server eingetragen?
Hallo, nein, ich hatte nur mal testweise in Windows den DNS direkt angegeben.
Hatte/habe lokale Geräte völlig unabhängig vom Betriebssystem bzw. von der Geräteart nicht konfiguriert, d.h. der pfsense-Router erledigt ansonsten alles (d.h. auf allen Geräten DHCP, sonst nichts).
 
Last edited:
Update 2:

Wenn ich unter Dienste / DNS-Auflösung folgende Option aktiviere:

DNS Abfrage Weiterleitung
Weiterleitungsmodus aktivieren
Wenn diese Option angewählt ist werden alle DNS Anfragen zu den Upstream DNS Server geschickt, die unter System > General Setup konfiguriert oder die über DHCP/PPP auf WAN erhalten wurden (Wenn DNS Server überschreiben dort aktiviert ist).

...gehen frei ausgewählte Webseiten, allerdings komme ich sowohl nicht mehr aufs PP-Forum noch auf die PP-Hauptseite, Meldung: "ERR_NAME_RESOLUTION_FAILED"..

 
...sodele, das Problem liegt an PPs "TrackStop".
Mir hat keine Ruhe gelassen, dass es 1. "plötzlich" kam und 2. definitiv nicht an pfsense liegen konnte.
Als ich mit dem Update 2 auf jede Webseite kam, nur nicht auf die von PP (Hauptseite/Forum), fiel mir ein, dass ich vor langer, langer Zeit im PP Mitgliedskonto unter Konfiguration was verändert hatte (weit vor dem hier beschriebenen Problem).... vielleicht blockte ja das PP Sicherheitsfeature die eigene Webseite? ;)

Nun, TrackStop deaktiviert, gewartet, alles wieder wie in der PP/pfsense-Anleitung eingestellt (d.h. DNS-Auflösung) - und zack... klappts auch wieder mit dem Internet.

Ich fände es allerdings schade, wenn ich TrackStop ausgeschaltet lassen müsste, obwohl ich bislang problemlos damit über die Runden kam... ggf. könnte man mal checken, wo das Problem jetzt bei TrackStop ist....
 
Das sollte eigentlich nicht passieren. Wir blocken uns jedenfalls nicht absichtlich selber ;) Auf welchem Server und mit welchen Trackstop-Filtern hast du das gesehen?
 
also, habe jetzt nochmal ein bisschen getestet und es ist so:
1. mit TrackStop (Filter Betrugs/Fraud und Fake News Filter) AN geht mit DNS Resolver gar nix mehr.
(d.h. das war die grundsätzlich Ursache für mein vor kurzem plötzlich aufgetretenes Problem).

2. in pfsense gibt es unter DNS Auflösen eben die Option "Weiterleitungsmodus aktivieren", die ich spaßeshalber mal aktiviert hatte (weil DNS Weiterleiten als Option eben funktioniert hat).
Da ist es so, dass zig wahllos getestete Seiten gehen, nur PP-Seiten (Forum/Homepage) nicht:
"Die Website ist nicht erreichbar (...) unter https://www.perfect-privacy.com/german/dns-leaktest/ ist (...) nicht verfügbar oder(...) verschoben.
ERR_NAME_RESOLUTION_FAILED".

Gehe ich dann über mein Handy nach PP und deaktivere TrackStop geht alles - also vor allem 1.) - wieder.
Bzgl. 2. kann ich nichts sagen, weil ich mich mit dem Gedöns auskenne.
Bzgl. 1. kann ich aber sagen, dass exakt die gleiche Konfiguration bis vor kurzem 100% funktioniert hat (mit TrackStop).
Ich vermute, so um den 24. Oktober herum (also ggf. ein paar Tage vorher), muss sich da hinter den Kulissen von TrackStop was geändert haben.....
 
Hallo. Ich habe das Problem in einer virtuellen pfsense nachvollziehen können und etwas Interessantes herausgefunden.

Wenn der auf dem VPN-Server für Trackstop eingesetzte powerdns-recursor die lokale Kopie der Root-Zone als Forwarder konfiguriert hat, antwortet er auf nicht-rekursive Queries mit "FORMERR". Das ist nicht richtig und ist ein Bug in powerdns, der in Debian noch nicht behoben ist. Im Monitoring fällt soetwas nicht auf, da dort rekursive Queries verwendet werden.

(die lokale Root-Zone haben wir, damit nicht sinnlose Queries für HansMeier-PC23.privat o.ä. durchs Internet gehen müssen)

Wenn powerdns wieder selber die Root-NS befragen darf, antwortet es korrekt mit "NOERROR".
unbound auf der pf-sense klagt zwar ein paar Mal erwartungsgemäß über "recursion lame server", fügt sich dann aber und funktioniert wieder.

Die Änderung sollte jetzt auf allen Servern aktiv sein.
 
Last edited:
Solution
Back
Top