OPNsense – DNS Anfragen an eigenen Resolver umleiten

J

junantaiso

New member
Hallo zusammen,
ich eröffne mal einen Thread mit Problemen für die tolle Anleitung von tiermutter und an dieser Stelle nochmal einen herzlichen Dank für das Teilen solcher hilfreichen Informationen 😊

Einleitung
Nun aber zu einem Problem, wo ich aktuell nicht weiter weiß und gerne mal das Wissen von anderen mit einfließen lassen würde, da es sich laut Recherche im Internet nicht um einen Einzelfall handelt. Ich habe mich größtenteils an die Anleitung gehalten, jedoch befindet sich AdGuard separiert in einem Docker Container im LAN, also muss der Redirect nicht auf die lokale Firewall zeigen, sondern auf den Server.

Übersicht
Hier mal kurz die Daten von den Beteiligten System.
GerätBeschreibungIP
FirewallOPNsense192.168.1.1
DNS ServerAdguard Home192.168.1.10
ClientAlpine Linux192.168.1.100

Bei dem Aufbau verwendet Adguard die OPNsense als Upstream Server, wobei diese selbst als Resolver fungiert, da Unbound mit Hyperlocal-Root betrieben wird. Dies funktioniert auch soweit Adguard bei den anderen Systemen im Netzwerk als DNS-Server konfiguriert ist und für alle anderen Geräte im LAN, wo dies nicht eingestellt werden kann, soll der DNS halt über die Firewall umgebogen werden.

Konfiguration
Hier mal die Einstellung vom Port Forwarding auf der Firewall.
InterfaceProtoAddressPortsAddressPortsIPPortsDescription
LANTCP/UDP! 192.168.1.10*! 192.168.1.1053 (DNS)
192.168.1.10
53 (DNS)Redirect DNS

Test mit Redirect
DNS-Abfrage vom Client wird ausgeführt.
Code: 
nslookup heimnetz.de 9.9.9.9

Log der Firewall zeigt den Redirect sauber an.
InterfaceTimeSourceDestinationProtoLabel
lan2024-01-16T07:51:25192.168.1.100:35959192.168.1.10:53udpRedirect DNS
lan2024-01-16T07:51:25192.168.1.100:359599.9.9.9:53udprdr rule

tcpdump auf den Client zeigt es ebenfalls ordnungsgemäß an.
07:51:34.007003 IP 192.168.1.100.35959 > dns9.quad9.net.53: 30512+ A? heimnetz.de. (29)
07:51:34.007038 IP 192.168.1.100.35959 > dns9.quad9.net.53: 31748+ AAAA? heimnetz.de. (29)
07:51:34.007727 IP 192.168.1.10.53 > 192.168.1.100.35959: 31748 0/1/0 (135)
07:51:34.036347 IP 192.168.1.10.53 > 192.168.1.100.35959: 30512 1/0/0 A 185.59.13.10 (45)

Am Client erhalte ich jedoch keine Antwort für die DNS-Abfrage.
Code: 
;; connection timed out; no servers could be reached

Test ohne Redirect
DNS-Abfrage vom Client wird ausgeführt.
Code: 
nslookup heimnetz.de 192.168.1.10

Log der Firewall zeigt natürlich nichts an, da kein Redirect erfolgt.

tcpdump auf den Client zeigt wieder alles korrekt an.
08:10:25.369332 IP 192.168.1.100.59788 > 192.168.1.10.53: 46978+ A? heimnetz.de. (29)
08:10:25.369398 IP 192.168.1.100.59788 > 192.168.1.10.53: 48499+ AAAA? heimnetz.de. (29)
08:10:25.369854 IP 192.168.1.10.53 > 192.168.1.100.59788: 48499 0/1/0 (135)
08:10:25.369855 IP 192.168.1.10.53 > 192.168.1.100.59788: 46978 1/0/0 A 185.59.13.10 (45)

Am Client erhalte ich nun auch die richtige Antwort für die DNS-Abfrage.
Code: 
Server:         192.168.1.10
Address:        192.168.1.10:53

Non-authoritative answer:

Non-authoritative answer:
Name:   heimnetz.de
Address: 185.59.13.10

Ergebnis
Also die Ausgabe vom tcpdump ist bei beiden Tests identisch, also natürlich abgesehen von der Uhrzeit und den angefragten DNS-Server und auch sonst scheint alles ordnungsgemäß konfiguriert zu sein. Ich kann mir einfach nicht erklären, warum die Anfrage nicht sauber aufgelöst wird bei dem Redirect. Denn man sieht im tcpdump auch schön, dass die korrekte Paketnummer beantwortet wird, also sollte dem Client auch nicht interessieren, dass diese von einem anderen Server kommt, da die ID eigentlich nur entscheidend ist. Das müsste auch identisch zu dem Aufbau sein, wenn Adguard direkt auf der OPNsense läuft, denn da würde die Antwort auch nicht von Quad9 kommen oder wie sieht das bei Euch aus?
 
Zuletzt bearbeitet:
So, ich habe mal die OPNsense umgestellt, so das Unbound als normaler DNS-Server arbeitet und alle Anfragen an Cloudflare 1.1.1.1 weiterleitet. Kleiner Hinweis noch, das Hyperlocal-Root wurde ebenfalls deaktiviert, damit es keine Beeinträchtigungen gibt.

Konfiguration
Hier mal die Einstellung vom Port Forwarding auf der Firewall.
InterfaceProtoAddressPortsAddressPortsIPPortsDescription
LANTCP/UDP**! 192.168.1.153 (DNS)
192.168.1.1
53 (DNS)Redirect DNS

Test direkt über OPNsense
DNS-Abfrage vom Client wird ausgeführt.
Code: 
nslookup heimnetz.de 9.9.9.9

Log der Firewall zeigt den Redirect sauber an.
InterfaceTimeSourceDestinationProtoLabel
lan2024-01-16T09:49:48192.168.1.100:32849192.168.1.1:53udpRedirect DNS
lan2024-01-16T09:49:48192.168.1.100:328499.9.9.9:53udprdr rule

tcpdump auf den Client zeigt auch die entsprechenden Pakete an.
09:49:56.943034 IP 192.168.1.100.32849 > dns9.quad9.net.53: 32450+ A? heimnetz.de. (29)
09:49:56.943064 IP 192.168.1.100.32849 > dns9.quad9.net.53: 33745+ AAAA? heimnetz.de. (29)
09:49:56.943681 IP dns9.quad9.net.53 > 192.168.1.100.32849: 32450 1/0/0 A 185.59.13.10 (45)
09:49:56.943811 IP dns9.quad9.net.53 > 192.168.1.100.32849: 33745 1/0/0 AAAA 2a02:17f8:4001:1499::2 (57)

Am Client erhalte ich eine Antwort für die DNS-Abfrage.
Code: 
Server:         9.9.9.9
Address:        9.9.9.9:53

Non-authoritative answer:
Name:   heimnetz.de
Address: 185.59.13.10

Non-authoritative answer:
Name:   heimnetz.de
Address: 2a02:17f8:4001:1499::2

Ergebnis
Das ist ja doch sehr merkwürdig, denn laut den Ergebnissen kommt die Antwort bei der DNS-Abfrage vom Quad9 Server selbst und nicht von der OPNsense. Dies wäre natürlich nicht der gewünschte Weg oder schreibt die Firewall ihre eigene Adresse an den Client um und gibt sich als IP 9.9.9.9 aus? Könnte das bitte nochmal jemand prüfen, wie es bei der Konfiguration über einen lokalen Adguard läuft?
 
Also ich bin bislang noch nicht dahintergekommen... irgendwie fehlt mir da wohl gerade etwas um das zu blicken :(
junantaiso schrieb:
Das ist ja doch sehr merkwürdig, denn laut den Ergebnissen kommt die Antwort bei der DNS-Abfrage vom Quad9 Server selbst und nicht von der OPNsense.
Zum Vergrößern anklicken....
Wie das zu bewerten ist, mag ich nicht beurteilen, bin mir aber sicher, dass hier nur der Schein trügt. Verwende statt 9.9.9.9 doch mal irgendwas Dummes, zB 10.20.80.90 und vergleiche das Ergebnis. Auch im Log des PiHole müsste zu sehen sein, dass er die Anfrage beantwortet.
 
An den Test mit einer Fake-IP hätte ich auch mal denken können 😵‍💫

Test mit Fake-DNS über OPNsense
DNS-Abfrage vom Client wird ausgeführt.
Code: 
nslookup heimnetz.de 10.20.80.90

Log der Firewall zeigt den Redirect sauber an.
InterfaceTimeSourceDestinationProtoLabel
lan2024-01-16T12:44:54192.168.1.100:41263192.168.1.1:53udpRedirect DNS
lan2024-01-16T12:44:54192.168.1.100:4126310.20.80.90:53udprdr rule

tcpdump auf den Client zeigt auch die entsprechenden Pakete an.
12:44:41.480897 IP 192.168.1.100.34824 > 10.20.80.90.53: 53612+ A? heimnetz.de. (29)
12:44:41.481591 IP 10.20.80.90.53 > 192.168.1.100.34824: 53612 1/0/0 A 185.59.13.10 (45)
12:44:41.481655 IP 192.168.1.100.34824 > 10.20.80.90.53: 54708+ AAAA? heimnetz.de. (29)
12:44:41.482486 IP 10.20.80.90.53 > 192.168.1.100.34824: 54708 1/0/0 AAAA 2a02:17f8:4001:1499::2 (57)

Am Client erhalte ich eine Antwort für die DNS-Abfrage.
Code: 
Server:         10.20.80.90
Address:        10.20.80.90:53

Non-authoritative answer:
Name:   heimnetz.de
Address: 185.59.13.10

Non-authoritative answer:
Name:   heimnetz.de
Address: 2a02:17f8:4001:1499::2

Ergebnis
Somit ist der Nachweis erbracht, dass die IP umgeschrieben wird von der OPNsense und das passiert bei einem externen DNS-Server nicht. Die Anfrage ist bei meinem Adguard Server jedoch auch sauber zu sehen und er gibt auch die korrekte IP zurück, was auch am tcpdump sauber erkannt wird. Weiß aber jemand, wie man das Problem lösen kann, wenn Adguard nicht auf der OPNsense läuft?

Ich frage mich auch, ob die Antwort direkt vom Adguard an den Client geschickt wird, da sich beide Systeme im gleichen Netz befinden und ob sich das Problem lösen lässt, wenn der Adguard Server in einem anderen Netzwerk steht und die Verbindung zwanghaft über die OPNsense läuft???
 
Also ich habe den Adguard Server mal in ein separates Netz geschoben und entsprechend alles auf der OPNsense eingerichtet.

Und siehe da, nun funktioniert alles ordnungsgemäß und die OPNsense fälscht auch die IP von den Antwortpaketen der DNS-Anfrage wieder. Also scheint der Grund wirklich zu sein, dass der Adguard Server im gleichen Netz wie die Clients steht und somit die Antwort nicht über die Firewall erfolgt, sondern direkt, was ja auch ein normales Verhalten ist.

Vielen Dank an tiermutter für den entscheidenen Hinweis 🤩
 
Hmm... Also das eigentliche Problem dass es mit nem redirect nicht klappt funktionierte ist damit auch behoben?
 
Genau, wenn sich der Adguard Server in einen eigenem Subnetz befindet, funktioniert der Redirect ohne Probleme, da der komplette Netzwerkverkehr über die Firewall geregelt wird und dadurch die IP des DNS-Servers umgeschrieben wird, damit der Client die Antworten akzeptiert. Denn innerhalb des gleichen Subnetz findet die Kommunikation direkt statt, also an der Firewall vorbei und der Adguard Server antwortet mit seiner IP 192.168.1.10 direkt auf die Anfragen des Clients 192.168.1.100, was dieser aber nicht akzeptiert, weil er eigentlich die Anfrage an die 9.9.9.9 geschickt hat und von da erwartet er auch die Antwort.
 
Ok... aber das ist ja auch eher ein Workaround... irgendwelche Ideen wie man das umsetzen kann ohne ein Subnetz zu verwenden?
 
Mir hat das Thema auch keine Ruhe gelassen, da ich es immer unbefriedigend finde, irgendwelche Sonderlösungen zu schaffen und nicht das eigentliche Problem zu lösen. Deshalb habe ich mich nochmal ran gesetzt und einige Dinge ausprobiert.

Es gibt eine brauchbare Lösung aus meiner Sicht, obwohl man dies natürlich auch als Workaround bezeichnen kann, aber auf jeden Fall ist man nicht auf ein zusätzliches Subnetz angewiesen. Wenn man die IP Konfiguration des Adguard Servers anpasst, damit eine 32er-Maske verwendet wird, können nach wie vor alle Clients den Server erreichen und der Netzwerkverkehr wird auch über die Firewall geleitet, wodurch die IP erfolgreich umgeschrieben werden kann. Also muss man in meinem Beispiel einfach folgende IP-Konfiguration auf dem Adguard Server vornehmen.
  • IP: 192.168.1.10
  • NETMASK: 255.255.255.255
  • GATEWAY: 192.168.1.1

Man muss dabei aber beachten, dass jeglicher Netzwerktraffic vom Adguard Server über die Firewall geroutet wird und nicht mehr direkt innerhalb des Subnetzes, also bei einem Backup-Server oder ähnlichen würde ich das nicht machen, um die OPNsense nicht unnötig zu belasten!
 
Naja, damit ist es ja auch ein anderes Subnetz, nur dass eben die IP Adresse zumindest optisch indentisch ist.
 
... aber in jedem Fall einfacher als ein komplett neues Netz einzurichten.
Ad hoc hätte ich auch gar keine andere Idee... die Umsetzung muss ja in jedem Fall am AGH erfolgen...
 
Vielleicht fällt ja noch jemand etwas ein und bei Gelegenheit gucke ich mal, ob man noch etwas einstellen kann am Adguard Server.
 
Vielleicht der Ansatz von 9axqe im Sense forum... Der ist noch aif Seite 3 gelandet bevor CJ, Du und ich aif Seite 4 geantwortet haben...
 
Wenn ich das aber richtig gelesen habe, hat er jetzt auch Adguard lokal auf der OPNsense installiert und nutzt es wie Du auch....
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Zurzeit aktive Besucher

Gesamt: 81 (Mitglieder: 6, Gäste: 75)

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
4.574
Beiträge
46.829
Mitglieder
4.208
Neuestes Mitglied
ramfresser

Teilen

Zurück
Oben