DNS Forwarder bei Dual WAN im Failover

EyeTap

Hallo Leute,

Nachdem ich in den letzten Jahren von der Cisco SOHO Schiene doch deutlich enttäuscht wurde, bin ich gerade dabei meine erste pfSense einzurichten - de Facto noch in einer Testumgebung - aber recht nahe am Echtbetrieb, zumindest bzgl des IP setups.

Leider bin ich dabei auf ein Problem gestossen, bei dem ich nicht mehr weiter weiss - was ich dazu im Forum gefunden habe ist doch schon deutlich in die Jahre gekommen und hat mir leider auch nicht wirklich weiter geholfen.

Konkret ist die Situation diese, dass ich 2 WAN Leitungen habe, eine mit einer statischen IP Adresse (WAN 1), die andere (WAN 2) mit einer quasi statischen - d.h. ich bekomme stets die gleiche (inkl. DNS Servern) per DHCP zugewiesen.
Die Konfiguration des Failovers schein prinzipiell soweit zu funktionieren - die pfSense schaltet brav auf die WAN 2 Leitung wenn WAN 1 abgesteckt wird, und auch wieder zurück wenn WAN 1 wieder verfügbar ist.

Das LAN besteht aus 2 VLAN's - das dürfte abe keine Rolle spielen, da es hier nur um das "Default-LAN" geht. Dieses ist ein 192.168.xx.0/24 Netzwerk. Die pfSense spielt DHCP.

Aus Geschwindigkeitsgründen, habe ich aber den DNS Resolver deaktiviert und statt dessen mit dem DNS Forwarder gearbeitet - der war doch um den Faktor 10 oder mehr schneller (wobei ich zugegeben muss, dass ich nicht ausschliessen kann, dass das an der Testumgebung mit einem G5 Router liegt).

Dazu habe ich im General Setup auch ein paar DNS Server eingetragen - je 4 pro WAN Leitung (zb 8.8.8.8 für WAN 1, 8.8.4.4 für WAN 2) - in der Annahme, dass bei Ausfall einer WAN Leitung diese dann über die andere WAN Leitung geroutet würden.
Im "Regelbetrieb" mit 2 aktiven WAN Leitungen hat soweit alles bestens funktioniert.

Nun wollte ich heute schnell etwas testen, und habe dazu aber nur WAN 2 (also eigentlich die DHCP "versorgte" Backup Leitung) angeschlossen.
Darauf ging einmal nicht mehr viel - und nach einigem Nachforschen, warum denn auch kein Ping auf 8.8.8.8 mehr funktionierte, habe ich fesgetstellt, dass die pfSense offenbar für alle DNS Server, welche unter General Setup konfiguriert sind, statische Routen anlegt (entsprechend den zugewiesenen Interfaces) - und das ping auf die 8.8.4.4 hat dann auch funktioniert.

Diese statischen Routen werden scheinbar auch nicht geändert, wenn eines der Interfaces down ist.

Resultat scheint dann zu sein, dass

a) kein Ping mehr an die Adressen welche über das inaktive Interface geroutet werden sollten erfolgreich ist
b) die pfSense in etliche Timeouts bei den mit dem inaktiven Interface assoziierten DNS Servern läuft - und das dauert deutlich länger als irgendetwas anderes warten will.

Frage ist jetzt natürlich - lässt es sich irgendwie vernünftig bewerkstelligen, dass im Dual WAN Betrieb mit dem DNS Forwarder vernünftig gearbeitet werden kann- oder gibt es - neben dem rein rekursiven DNS Resolver Betrieb - noch eine andere sinnvolle Vorgangsweise...?

Wenn eine Leitung ausfällt, und das verursacht dann auch gleich auf der pfSense massive Probleme wäre das ganze WAN Failover ja nicht wirklich brauchbar...

Vielen lieben Dank für euren Input!

viragomann

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Aus Geschwindigkeitsgründen, habe ich aber den DNS Resolver deaktiviert und statt dessen mit dem DNS Forwarder gearbeitet - der war doch um den Faktor 10 oder mehr schneller

Ist mir noch gar nicht aufgefallen.

nach einigem Nachforschen, warum denn auch kein Ping auf 8.8.8.8 mehr funktionierte, habe ich fesgetstellt, dass die pfSense offenbar für alle DNS Server, welche unter General Setup konfiguriert sind, statische Routen anlegt (entsprechend den zugewiesenen Interfaces) - und das ping auf die 8.8.4.4 hat dann auch funktioniert.

Genau dafür ist die Gateway Option gedacht.
Die Option macht eher Sinn, wenn du DNS Server des Internet Providers verwendest, welche dann nur Anfragen der eigenen Klienten beantworten. Eine Abfrage vom "fremden" WAN würde fehlschlagen.

In deinem Fall, wenn du einfach externe DNS verwenden möchtest, kannst du aber die Interfaces auf "none" belassen.

EyeTap

@viragomann said in DNS Forwarder bei Dual WAN im Failover:

Aus Geschwindigkeitsgründen, habe ich aber den DNS Resolver deaktiviert und statt dessen mit dem DNS Forwarder gearbeitet - der war doch um den Faktor 10 oder mehr schneller

Ist mir noch gar nicht aufgefallen.

Ich habe bei der Verwendung des Resolvers im rekursiven Modus bei neuen Abfragen meist Response Zeiten im Bereich von 120+ ms gehabt, teils auch erheblich mehr.
Wie gesagt, ich kann aber nicht ausschließen, dass das auch an der Testumgebung liegt.
Mit dem DNS Forwarder waren die Antwortzeiten von 127.0.0.1 i.A. um die 20 - 30 ms.
(Unter Diagnose, DNS Query)

Der Resolver im Forwarding-Modus war vergleichbar mit dem DNS Forwarder, Unterschiede waren geringfügig bis esoterischer Natur.

@viragomann said in DNS Forwarder bei Dual WAN im Failover:

Die Option macht eher Sinn, wenn du DNS Server des Internet Providers verwendest, welche dann nur Anfragen der eigenen Klienten beantworten. Eine Abfrage vom "fremden" WAN würde fehlschlagen.

Nun ja, solche hatte bzw habe ich schon auch eingetragen.
Was mir aber aufgefallen ist, ist dass die Provider (und damit WAN-Interface bzw gatewayspezifischen) DNS Server - möglicherweise nach einiger Zeit - tatsächlich nicht mehr antworten.
Nachdem meine Testumgebung aber mit einem Mobil-Router eines 3. Providers arbeitet, vermute ich einmal, dass das der Grund sein könnte.

Dass aber solche DNS Server, welche einem bestimmten Gateway zugewiesen sind, auch Timeouts erzeugen, wenn das zugehörige Gateway down ist, erschliesst sich mir nicht.
Sollten diese DNS Server dann nicht zumindest einfach ignoriert werden?

Ich habe gestern diesbezüglich noch einiges in der pfSense Doku (https://docs.netgate.com/pfsense/en/latest/multiwan/interfaces-and-dns.html) gelesen, allerdings ist das Thema dort nicht sehr umfassend behandelt - oder ich konnte die relevanten Stellen nicht finden.

@viragomann said in DNS Forwarder bei Dual WAN im Failover:

In deinem Fall, wenn du einfach externe DNS verwenden möchtest, kannst du aber die Interfaces auf "none" belassen.

Das ist wirklich ein super Tip, das war mir überhaupt nicht klar. Ich dachte wenn das zugehörige Interface / Gateway auf "none" steht würden die nicht mehr befragt werden....

Ich werde mir das in den kommenden Tagen noch genauer ansehen, und melde ich dann wieder.

Auf jeden Fall aber vielen herzlichen Dank für das bereits sehr hilfreiche Feedback!

viragomann

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Dass aber solche DNS Server, welche einem bestimmten Gateway zugewiesen sind, auch Timeouts erzeugen, wenn das zugehörige Gateway down ist, erschliesst sich mir nicht.

Das liegt wohl an der statischen Route, die dann nicht mehr funktioniert.

Sollten diese DNS Server dann nicht zumindest einfach ignoriert werden?

Aus Sicht des DNS Clients würde ich das auch so verstehen. Server antwortet nicht, versuch den nächsten.
Welchen Einfluss da nun die Route darauf hat, kann ich mir auch nicht erklären.

Das ist wirklich ein super Tip, das war mir überhaupt nicht klar. Ich dachte wenn das zugehörige Interface / Gateway auf "none" steht würden die nicht mehr befragt werden....

Musst halt noch die pfSense Sprache lernen. ;-) "None" heißt im Falle von Gateways, das Default Gateway. Ist in den Firewall-Regeln auch so.
Ich muss aber beipflichten, dass die Hints zu den DNS-Einstellungen in den Gereral Settings eher suggerieren, jedem WAN seine eigenen DNS Server einzurichten, wie du es gemacht hast.

JeGr

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Aus Geschwindigkeitsgründen, habe ich aber den DNS Resolver deaktiviert und statt dessen mit dem DNS Forwarder gearbeitet - der war doch um den Faktor 10 oder mehr schneller (wobei ich zugegeben muss, dass ich nicht ausschliessen kann, dass das an der Testumgebung mit einem G5 Router liegt).

Sehr unwahrscheinlich. Zumal der Resolver maximal beim ersten Zugriff langsamer ist als ein Forwarder, danach aber komplett aus seinem Cache bedienen kann und annähernd 0ms dafür braucht. Da sollte man nochmals nachtesten :)

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Dazu habe ich im General Setup auch ein paar DNS Server eingetragen - je 4 pro WAN Leitung (zb 8.8.8.8 für WAN 1, 8.8.4.4 für WAN 2) - in der Annahme, dass bei Ausfall einer WAN Leitung diese dann über die andere WAN Leitung geroutet würden.

4 Pro Leitung?
Das ist schon etwas Overkill.

Im Normalfall reichen 1-2 pro WAN mehr als deutlich.

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Diese statischen Routen werden scheinbar auch nicht geändert, wenn eines der Interfaces down ist.

Über welche pfSense Version reden wir da? Seit 2.5.x werden für GW Monitorings IMHO keinerlei static routes im Hintergrund mehr eingetragen. Kann ich hier auch in der Routingtabelle keine sehen. Sind die ggf. wegen GW Monitoring eingetragen worden? Das ist dann ne andere Baustelle. Man sollte dann schon aufpassen, dass - sofern man DNSe spezifischen GWs zuweist - man nicht versehentlich den DNS dann einem anderen Interface als GW Monitoring zuschustert. Sonst läuft das alles ziemlich schief über Kreuz.

Generell ist es aber eh sinnvoller, eine Failover GW Gruppe zu erstellen mit dem WAN, was primär genutzt werden soll, die als Default GW reinzupacken und den DNS Resolver zu nutzen statt irgendwelcher Forwarder. Dazu den Resolver mit etwas mehr Cache und TTL Zeiten aufbrezeln und die Zugriffszeiten dürften mehr als angenehm sein.

BTW: Die Zeiten sind eh komplett überbewertet. Selbst mit einem DNS, der statt 12ms oder 25ms mit 250ms antwortet kann man problemlos gut arbeiten denn da springt dann überall wieder das Caching dazwischen. Ja der erste Hit mag dann langsamer sein, aber wenn man sich Techniken wie ODNS oder DoHoT anschaut und welche Delays die mit reinbringen könnte man meinen, dass danach nichts mehr funktioniert. Praktisch hat es aber kaum Auswirkungen sobald es mal ein paar Stunden läuft :)

Cheers

EyeTap

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Aus Geschwindigkeitsgründen, habe ich aber den DNS Resolver deaktiviert und statt dessen mit dem DNS Forwarder gearbeitet - der war doch um den Faktor 10 oder mehr schneller (wobei ich zugegeben muss, dass ich nicht ausschliessen kann, dass das an der Testumgebung mit einem G5 Router liegt).

Sehr unwahrscheinlich. Zumal der Resolver maximal beim ersten Zugriff langsamer ist als ein Forwarder, danach aber komplett aus seinem Cache bedienen kann und annähernd 0ms dafür braucht. Da sollte man nochmals nachtesten :)

Im "Normalbetrieb" funktioniert das auch tadellos, nur im Fehlerfall (wenn die "Primäre" Leitung ausfällt, und auf die "Backup" Leitung umgeschaltet wird kommt es zu diesem eigenartigen Verhalten - und hier rede ich nicht über 200ms sondern teils sogar bis über 1s.

Habe das jetzt aber gerade nochmal getestet und jetzt sind die Antwortzeiten von 127.0.0.1 absolut OK, auch im Failover-Status. Verstehen kann ich das nicht.
Das einzige was mir noch einfällt wäre, dass da Windows noch zusätzlich reingespuckt hätte weil die Netzlaufwerke nicht erreichbar waren...

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Über welche pfSense Version reden wir da? Seit 2.5.x werden für GW Monitorings IMHO keinerlei static routes im Hintergrund mehr eingetragen. Kann ich hier auch in der Routingtabelle keine sehen. Sind die ggf. wegen GW Monitoring eingetragen worden

2.5.2-RELEASE (amd64)
built on Fri Jul 02 15:33:00 EDT 2021
FreeBSD 12.2-STABLE

Nein, ich habe nur die jeweiligen Next Hops (also die Provider-Router) als Monitoring Adresse eingetragen (Wan1) - bzw wurde das automatisch eingetragen (Wan2).
Glücklich bin ich damit aber nur bedingt - solange aber nur eine IP Adresse zum Monitoring eingetragen werden kann ist das noch der vernünftigste Ansatz...

Ich habe das System jetzt mit dem Resolver im Forwarding Modus und unter General Setup nur mit den Google und Cloudflare DNS Adressen auf Gateway "none" konfiguriert (Ohne Allow DNS server list to be overridden by DHCP on WAN) - und so sind auch keine statischen Routen eingetragen.

Wenn ich Provider-DNS am jeweiligen Gateway eintrage werden auch statische Routen erstellt - und scheinbar bleiben die aktiv wenn das zugehörige Gateway down geht und sorgen (auch) für Timeouts - und die dauern dann ewig.

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Generell ist es aber eh sinnvoller, eine Failover GW Gruppe zu erstellen mit dem WAN, was primär genutzt werden soll, die als Default GW reinzupacken und den DNS Resolver zu nutzen statt irgendwelcher Forwarder.

Gut, ich denke, dass ich jetzt mit dem Resolver im Forwarding Modus sozusagen im Hybrid fahre.. :)

Jetzt muss ich dann aber doch noch eine Frage stellen - wieso können in der States Table Einträge mit "Established" auf WAN1 bestehen blieben wenn dieses Interface bzw Gateway down geht und "Flush all states when a gateway goes down" in den Advanced System Settings (Misc) gesetzt ist? Und hier handelt es sich um Adressen die definitiv nicht im Bereich der eigenen Netzwerke sind oder erreichbar wären (zB. Adressen von Kaspersky)....

JeGr

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Ich habe das System jetzt mit dem Resolver im Forwarding Modus und unter General Setup nur mit den Google und Cloudflare DNS Adressen auf Gateway "none" konfiguriert (Ohne Allow DNS server list to be overridden by DHCP on WAN) - und so sind auch keine statischen Routen eingetragen.

Das macht aber wenig Sinn. Warum den Resolver kastrieren auf Forwarding? Verstehe ich leider nicht.

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Wenn ich Provider-DNS am jeweiligen Gateway eintrage werden auch statische Routen erstellt - und scheinbar bleiben die aktiv wenn das zugehörige Gateway down geht und sorgen (auch) für Timeouts - und die dauern dann ewig.

Ist ja logisch wenn du sie fest zuweist, dann bleiben sie auch aktiv. Du zwingst ja die FW das GW zu benutzen also bleiben die natürlich aktiv.

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Gut, ich denke, dass ich jetzt mit dem Resolver im Forwarding Modus sozusagen im Hybrid fahre.. :)

Nein du machst Forwarding. Hybrid ist das nicht. Klar hast du Caching aber das hat jeder Forwarder/Resolver immer drin. Ich sehe das eben im Sinne von Zentralisierung eher kritisch. Zumal beim Forwarding - egal was du einstellst - kein DNSSec geprüft werden kann weil technisch nicht möglich. Das kann nur der Forwarder und da weiß man nicht so recht ob ers tut oder nicht.

Ich würde daher normales Resolving immer vorziehen, dann hat man auch das ganze Theater nicht, wenn mal ein Forwarder grad nicht geht. Gerade erst wieder waren die DNSe von 1&1 oder bspw. auch Vodafone fault oder down - großer Outage für die meisten weil dann nix mehr ging. Google oder AWS down - 8.8.8.8 geht nicht - was war das eine Welle. Da lös ich lieber selbst auf

EyeTap

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Das macht aber wenig Sinn. Warum den Resolver kastrieren auf Forwarding? Verstehe ich leider nicht.

Einfach nur in der Annahme, dass der Provider bzw Downstream DNS flotter ist als ich. Wäre ja eigentlich auch traurig wenn nicht.. :)

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Wenn ich Provider-DNS am jeweiligen Gateway eintrage werden auch statische Routen erstellt - und scheinbar bleiben die aktiv wenn das zugehörige Gateway down geht und sorgen (auch) für Timeouts - und die dauern dann ewig.

Ist ja logisch wenn du sie fest zuweist, dann bleiben sie auch aktiv. Du zwingst ja die FW das GW zu benutzen also bleiben die natürlich aktiv.

Nun ja - logisch dass die Routen bleiben - OK. Nicht logisch wenn die auch, wenn das zugewiesene Gateway down ist, auch aktiv weiter versucht werden zu verwenden und dann Timeouts liefern.

@jegr said in DNS Forwarder bei Dual WAN im Failover:

Ich würde daher normales Resolving immer vorziehen, dann hat man auch das ganze Theater nicht, wenn mal ein Forwarder grad nicht geht. Gerade erst wieder waren die DNSe von 1&1 oder bspw. auch Vodafone fault oder down - großer Outage für die meisten weil dann nix mehr ging.

Mit genug Forwardern wär das ja kein Thema.. ;-)

JeGr

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Nun ja - logisch dass die Routen bleiben - OK. Nicht logisch wenn die auch, wenn das zugewiesene Gateway down ist, auch aktiv weiter versucht werden zu verwenden und dann Timeouts liefern.

Durchaus logisch, denn sie werden fest konfiguriert über DIESE GWs zu gehen. Wenn du keine GW Zuweisung machst, gehen sie übers Default. Das ist aber auch in der Doku beschrieben :)

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Einfach nur in der Annahme, dass der Provider bzw Downstream DNS flotter ist als ich. Wäre ja eigentlich auch traurig wenn nicht.. :)

Was ist Geschwindigkeit ggü Zuverlässigkeit? ;) Zumal der Vorteil beim echten Resolver nur einmal besteht, danach greift Caching und der Rest ist dann egal. Zu viel Zentralisierung war leider gerade bei DNS noch nie zielführend :)

@eyetap said in DNS Forwarder bei Dual WAN im Failover:

Mit genug Forwardern wär das ja kein Thema.. ;-)

Doch, denn die meisten bleiben dann doch wieder bei den großen/größten Forwardern hängen. Und dann gibt es schlicht Abhängigkeit von ein paar großen DNS Schleudern, die dann lustig fröhlich ausliefern können was sie wollen. Worin das gipfelt zeigt sich gerade erst beim Prozess gegen die (jetzt schweizer) Betreiber von 9.9.9.9 die per Verfügung dazu genötigt werden (sollen), dass diverse Domains nicht mehr erreichbar / auflösbar sind über ihre Resolver. Allerdings soll das dann auch nur aus dem entsprechenden Land nicht auflösbar sein, etc. bla fasel. Es ist wieder kompletter Nonsense, weil die Leute DNS nicht verstehen und die Komplexität von "IP Adresse ist keine fixe Hausnummer in Deutschland" nicht begreifen. Da klebt in den Köpfen, dass man IPs festnageln kann auf ein Land (jeder der schon GeoIP gemacht oder genutzt hat weiß wie ungenau und doof solch eine Annahme ist). Und dann ist das ja einfach zu machen. Dass die Umsetzung extrem schwierig und schwammig wird und im Endeffekt nur dazu führt, dass die Leute andere Forwarder - oder wesentlich sinniger - einen eigenen Resolver nutzen, der auf irgendwelche Forwarder pfeift und die Domain einfach vom eingetragenen SOA Server der Domain holt ist in den Kleinhirnen leider nicht angekommen.

Aber an genau diesen Prozessen sowie den vergangenen Problemen mit irgendwelchen Forwardern von Betreibern sowie Happenings wie DNS Search Redirection, falschen IPs statt NXDOMAIN Antworten, DNS Umleitungen, Domain Parking DNS Redirection und was-weiß-ich-nicht-mehr-alles-für-anderen-Schmutz lernt man auf die harte Tour, dass man von zentralen Ansätzen lieber die Finger lässt.

Die Idee, einfach lokal bspw. 10 oder noch mehr Forwarder einzutragen ist BTW leider genauso unsinnig, da die Forwarder/Logik das gar nicht sinnvoll nutzen kann. Der korrekte Ansatz in der Richtig wäre dann tatsächlich ein Konzept wie ODNS oder DoHoT was zusammen mit dnscrypt als stub resolver und DNS "loadbalancer" inkl. selection mechanism gegen DNS bias einhergeht.

Damit könnte man dann so halbwegs was anfangen :)