Moin ich habe AdGuardHome als plugin in meiner OpnSense installiert und es scheint soweit alles zu laufen.
Mein Problem ist aber UnboundDNS das musste ich deaktivieren weil AdGuard auf dem selben Port läuft.
Man kann beides zusammen laufen lassen aber da verstehe ich die einstellungen nicht oder ich mache da was falsch:
Das Video habe ich genommen
https://www.youtube.com/watch?v=_JhQn30mqCw (https://www.youtube.com/watch?v=_JhQn30mqCw)
Hier noch eine weitere erklärung
https://0x2142.com/how-to-set-up-adguard-on-opnsense/ (https://0x2142.com/how-to-set-up-adguard-on-opnsense/)
in den Videos wird zwar auch beschrieben was man machen muss damit beides läuft aber das geht wohl nicht bei mir ( warum ? )
die datei bearbeiten und den port 53 von Adguard auf z.b. 53053 ändern
/usr/local/AdGuardHome/AdGuardHome.yaml
dns:
bind_hosts: meine IP-adressen der VLans
port: 53 ( diesen ändern auf 53053
Dann Services > Unbound DNS > Query Forwarding
einen neuen server angeben da wo Adguard läuft meine Opnsense läuft auf der 10.6.4.10 das ist also meine server IP.
der ServerPort ist aus der yaml datei port 53053 ).
der Port 53 bleibt bei Unbound DNS so eingestellt wie er ist.
alles speichern und neu starten aber da ändert sich nichts.
was versprichst du dir von Tandem Adguard/Unbound?
ich nutze Adguard als Docker image und wüsste nicht wofür ich Unbound nachschalten sollte.
Gibt doch nur Probleme... so wie bei dir...
AdGuard Home braucht zwingend einen rekursiven Upstream-Server. Dafür nehme ich meinen lokalen Unbound? Was schlägst du sonst vor?
@loaded
Bei mir ist Unbound der Default-Nameserver auf Port 53 überall. AdGuard Home liegt auf 127.0.0.1:53530 und hat 127.0.0.1:53 als einzigen Upstream.
Auf allen Interface, bei denen ich will, dass die Clients AGH benutzen, habe ich eine NAT Port Forward Regel von TCP/UDP, Destination: this firewall:53 nach 127.0.0.1:53530.
Klappt ausgezeichnet. Statische Overrides und Registrierungen vom DHCPd in Unbound funktionieren auch.
Unbound braucht auch einen externen DNS Server wie Adguard auch, ich nutze quad9 oder auch cloudflare als tls port 853
port 53 ist nur intern erlaubt.
Wieso das denn? Natürlich braucht Unbound keinen upstream Server. Noch nie.
für die lokale Auflösung nicht, aber ob der TE an lokaler Namensauflösung oder eher an DNS Filterung interessiert ist?
Unbound ist ein rekursiver DNS Server.
Der artikel erklärt den unterschied zwischen forwarder und rekursion recht gut:
https://docs.pi-hole.net/guides/dns/unbound/
@Monviech
Danke.
und nun auf Deutsch von Cloudflare:
Was ist ein rekursives DNS?
Bei einem rekursiven DNS-Lookup kommuniziert ein DNS-Server mit mehreren anderen DNS-Servern, um eine IP-Adresse zu finden und an den Client zurückzugeben. Dies steht im Gegensatz zu einer iterativen DNS-Abfrage, bei der der Client direkt mit jedem an der Suche beteiligten DNS-Server kommuniziert. Auch wenn das eine sehr technische Definition ist, sollte ein genauerer Blick auf das DNS-System und den Unterschied zwischen Rekursion und Iteration helfen, etwas Licht ins Dunkel zu bringen.
Was die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Es funktioniert auch so.
ich habe DNS auf NAS und Forwarde zum Adguard, einfach aus dem Grund das ich manche DNS Zonen lieber von NAS
auflöse und Rest zum Adguard leite.
Nur weil einer Blödsinn auf seiner Seite postet und erklärt das man Adguard unbedingt zum Unbound leinen muss?
Muss nicht! es funktioniert auch so hervorragend.
....und wenn man unbedingt dhcp Clients dynamisch bei dns registrieren will auch gut, eventuell dann Ubound>Adguard forwarden.
Quote from: Zapad on October 04, 2024, 08:37:14 AM
Was die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Auflösung lokaler Hostnamen z.b., wenn Unbound auf der OPNSense läuft funktioniert das grossartig.
an den TE:
- Adguard vor Unbound auf Port 53
- Unbound auf Port 53053 (z.b.) hinter Adguard
- entsprechend in Adguard konfigurieren, das er an Unbound weiterleitet.
Funktioniert so bei mir seit 2 Jahren problemlos, Konfig kann ich gerne nachreichen, musst dann aber bis heute abend warten.
Quote from: Zapad on October 04, 2024, 08:37:14 AM
Was die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Weil man seine DNS-Anfragen nicht einem US-Konzern geben will?
Quote from: Tuxtom007 on October 04, 2024, 08:59:30 AMQuote from: Zapad on October 04, 2024, 08:37:14 AMWas die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Auflösung lokaler Hostnamen z.b., wenn Unbound auf der OPNSense läuft funktioniert das grossartig.
an den TE:
- Adguard vor Unbound auf Port 53
- Unbound auf Port 53053 (z.b.) hinter Adguard
- entsprechend in Adguard konfigurieren, das er an Unbound weiterleitet.
Funktioniert so bei mir seit 2 Jahren problemlos, Konfig kann ich gerne nachreichen, musst dann aber bis heute abend warten.
Hi @Tuxtom007
wärst du so nett und listest mal deine Einstellungen auf.
Ich kriege das irgendwie nicht so recht hin...
Wenn ich die zwei Dinger in Kombination schalte, dann funktionieren bei mir die lokalen hostnamen nicht mehr und mein voip über die Fritzbox (als Client hinter der Opnsense) macht auch Probleme, obwohl ich hier direkt auf der Fritzbox die o2 eigenen DNS Server eingetragen hab. Die registriert ihre Rufnummer nur, wenn ich adguard deaktiviere und unbound mit stock settings laufen lasse.
Wirklich geändert habe ich an den stock settings nichts, außer, dass eben unbound auf port 53053 läuft und eben diesen habe ich dann als upstream server bei adguard eingetragen.
Ich verstehe leider gar nicht so recht wie das mit den lokalen hostnames bei opnsense funktioniert, dachte das läuft out of the box einfach, aber dem ist scheinbar nicht so :(
Und was die Fritzbox für Probleme hat, obwohl sie ihre eigenen DNS Server eingetragen hat verstehe ich auch nicht...
Quote from: cottec on March 30, 2025, 01:15:05 PMwärst du so nett und listest mal deine Einstellungen auf.
Kannst haben - hier AdGuard DNS-Settings:
Upstream-DNS-Server
[/local/]127.0.0.1:53053
[/MEINEDOMAIN.net/]127.0.0.1:53053
[/0.10.in-addr.arpa/]127.0.0.1:53053
127.0.0.1:53053
[::1]:53053
Fallback-DNS-Server
1.1.1.1
9.9.9.9
Bootstrap-DNS-Server
9.9.9.10
149.112.112.10
2620:fe::10
2620:fe::fe:10
Private inverse DNS-Server
127.0.0.1:53053
[::1]:53053
Unbound siehe Screenshot, der Rest ist Default
(https://ibb.co/2BGn9Yg)
Quote from: Patrick M. Hausen on October 04, 2024, 09:08:59 AMQuote from: Zapad on October 04, 2024, 08:37:14 AMWas die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Weil man seine DNS-Anfragen nicht einem US-Konzern geben will?
Naja, es hat auch den Vorteil DNS beliebig manipulieren zu können und seinen Pool an Geräten mit passenden Namen zu versorgen - das gilt jetzt nicht nur für Unbound, passt aber so in diesen Kontext.
Quote from: trixter on March 31, 2025, 02:25:56 PMQuote from: Patrick M. Hausen on October 04, 2024, 09:08:59 AMQuote from: Zapad on October 04, 2024, 08:37:14 AMWas die Frage nicht beantwortet, warum sollte man Unbound dem Adguard nachschalten?
Weil man seine DNS-Anfragen nicht einem US-Konzern geben will?
Naja, es hat auch den Vorteil DNS beliebig manipulieren zu können und seinen Pool an Geräten mit passenden Namen zu versorgen - das gilt jetzt nicht nur für Unbound, passt aber so in diesen Kontext.
AGH braucht zwingend einen rekursiven Server als Upstream. Also weshalb nicht Unbound? Keine Ahnung, was der Zapad eigentlich will.
Quote from: Tuxtom007 on March 31, 2025, 12:45:23 PMQuote from: cottec on March 30, 2025, 01:15:05 PMwärst du so nett und listest mal deine Einstellungen auf.
Kannst haben - hier AdGuard DNS-Settings:
Upstream-DNS-Server
[/local/]127.0.0.1:53053
[/MEINEDOMAIN.net/]127.0.0.1:53053
[/0.10.in-addr.arpa/]127.0.0.1:53053
127.0.0.1:53053
[::1]:53053
Fallback-DNS-Server
1.1.1.1
9.9.9.9
Bootstrap-DNS-Server
9.9.9.10
149.112.112.10
2620:fe::10
2620:fe::fe:10
Private inverse DNS-Server
127.0.0.1:53053
[::1]:53053
Unbound siehe Screenshot, der Rest ist Default
(https://ibb.co/2BGn9Yg)
Danke!
Kannst du mir kurz helfen, wie ich das für meinen Zweck richtig nutze?
Ich habe meine opnsense mit der IP 10.10.10.1 und ich habe 3 Interfaces, an denen die Clients hängen: 10.10.100.1, 10.10.110.1, 10.10.120.1
Reicht das als grundlegenstes Setup, wenn ich bei Upstream und bei Private inverse einfach nur "127.0.0.1:53053" reinschreibe und fertig?
Der standard Domainname in OPNsense ist localdomain, passt für mich.
Muss ich den explizit in die Klammern davor schreiben oder ist es ohne die Klammern einfach für alle Anfragen gültig?
[/localdomain/]127.0.0.1:53053
Wenn ich das richtig verstanden habe, dann kann ich die Namen ohne das Präfix erreichen, weil sie eh nicht mehrfach unter verschiedenen Domains existieren, oder?
Sorry, bin ein blutiger Noob in dem Bereich....
[::1]:53053 ist der v6 loopback, oder?
Quote from: cottec on March 31, 2025, 03:11:44 PMKannst du mir kurz helfen, wie ich das für meinen Zweck richtig nutze?
Ich habe meine opnsense mit der IP 10.10.10.1 und ich habe 3 Interfaces, an denen die Clients hängen: 10.10.100.1, 10.10.110.1, 10.10.120.1
Reicht das als grundlegenstes Setup, wenn ich bei Upstream und bei Private inverse einfach nur "127.0.0.1:53053" reinschreibe und fertig?
ja sollte reichen, aber für Privat Inverse braucht es dahinter noch den Umbound, welche die lokalen Adressen dann auflöst.
Der Screenshot ist zwar verlinkt aber wird nicht angezeigt.
QuoteDer standard Domainname in OPNsense ist localdomain, passt für mich.
Muss ich den explizit in die Klammern davor schreiben oder ist es ohne die Klammern einfach für alle Anfragen gültig?
[/localdomain/]127.0.0.1:53053
Wenn ich das richtig verstanden habe, dann kann ich die Namen ohne das Präfix erreichen, weil sie eh nicht mehrfach unter verschiedenen Domains existieren, oder?
Sorry, bin ein blutiger Noob in dem Bereich....
Die Syntax ist schon so vor gegeben, am besten mal in die AdGuard Doku schauen.
Quote[::1]:53053 ist der v6 loopback, oder?
Korrektur: ja zum Unbound für IPv6 - wenn nicht in Benutzung, einfach weglassen
Beim Unbound muss du auf jeden Fall den Port 53053 eintragen und " Register ISC DHCP4 Leases" sowie "Register DHCP Static Mappings" aktivieren ( unter General ), der Rest ist Standardeinstellung bei mir
Ja passt, die Einstellungen hatte ich auch genau so.
Hostnamen funktionieren jetzt ganz gut, das ist schon mal sehr gut, dann kann ich die SMB Shares in Unraid wiederbeleben :)
Ein großes Problem hab ich aber noch, die Fritzbox zickt beim registrieren der Rufnummer noch rum.
Ohne Adguard und Unbound funktioniert alles.
Es braucht lediglich die DNS Server von o2.
Da ich Unbound noch nicht weiter konfiguriert habe udn die Serverliste in OPNsense auch leer ist, werden die o2 DSN Server angezogen.
Ich habe aber eh in der Fritzbox noch die DNS Server eingestellt.
Klappt ja auch ohne Adguard/Unbound.
Mit den beiden an meldet sie aber DNS Fehler, verstehe ich absolut nicht...
In OPNsense:
Interfaces: Diagnostics: DNS Lookup
Hostname or IP
sip.alice-voip.de
Response
Type Answer Server Query time
A sip.alice-voip.de. 1478 IN A 62.52.28.195 62.109.121.2 6 msec
wenn ich das ganze vom PC (am gleichen Interface wie die Fritzbox) mache:
nslookup sip.alice-voip.de
Server: UnKnown
Address: 10.10.100.1
Name: sip.alice-voip.de
Mit Server gehts natürlich:
nslookup sip.alice-voip.de 62.109.121.1
Server: dns3.telefonica.de
Address: 62.109.121.1
Nicht autorisierende Antwort:
Name: sip.alice-voip.de
Address: 62.52.28.195
nslookup sip.alice-voip.de 62.109.121.2
Server: dns4.telefonica.de
Address: 62.109.121.2
Nicht autorisierende Antwort:
Name: sip.alice-voip.de
Address: 62.52.28.195
versteh ich a) nicht, warum er hier nicht den richtigen DNS Server für die Anfrage nimmt, wenn das doch der einzig verfügbare ist und b) warum die Fritzbox Probleme macht, obwohl sie die DNS Server extra nochmal hinterlegt hat.
In adguard hab ich zum testen noch zwei Filter geschrieben, die bringen aber auch nur so viel, dass ich in der Anfragenliste sehe, dass Adguard sie genehmigt anstatt nur verarbeitet (Ergebnis sollte eh das selbe sein: An den Upstream schicken)
@@||*^$client='fritzbox'$important
@@||sip.alice-voip.de^$important
Quote from: cottec on March 31, 2025, 11:17:02 PMHostnamen funktionieren jetzt ganz gut, das ist schon mal sehr gut, dann kann ich die SMB Shares in Unraid wiederbeleben :)
Ein großes Problem hab ich aber noch, die Fritzbox zickt beim registrieren der Rufnummer noch rum.
Ohne Adguard und Unbound funktioniert alles.
Es braucht lediglich die DNS Server von o2.
Da ich Unbound noch nicht weiter konfiguriert habe udn die Serverliste in OPNsense auch leer ist, werden die o2 DSN Server angezogen.
Ich habe aber eh in der Fritzbox noch die DNS Server eingestellt.
Klappt ja auch ohne Adguard/Unbound.
Mit den beiden an meldet sie aber DNS Fehler, verstehe ich absolut nicht...
Unraid kann ich dir nicht bei helfen, kenne ich nicht
FritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?
Quote from: Tuxtom007 on April 01, 2025, 08:10:35 PMFritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?
Ah ne in Unraid ist alles okay, da hab ich keine Sorge.
Die Fritzbox ist als Client hinter der OPNsense.
Nochmal in aller Deutlichkeit: Wenn ich Unbound und Adguard deaktiviere, dann geht es sofort mit der VoIP Registrierung
Quote from: cottec on April 01, 2025, 10:59:33 PMQuote from: Tuxtom007 on April 01, 2025, 08:10:35 PMFritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?
Ah ne in Unraid ist alles okay, da hab ich keine Sorge.
Die Fritzbox ist als Client hinter der OPNsense.
Nochmal in aller Deutlichkeit: Wenn ich Unbound und Adguard deaktiviere, dann geht es sofort mit der VoIP Registrierung
In meiner Konfiguration habe ich bei DNS Server v4 vom Internetanbieter... eingestellt.
hast du denn auch adguard und unbound am laufen?
Hast du noch einen Port an der Sense frei oder ein separates Vlan? Dann hänge die Fritte dort an und spare dir die Mühe mit AdGuard. Wenn es ein dedizierter NIC ist, hast du da eben eine DMZ. Habe ich auch so gemacht. AdGuard ist dort nicht aktiv und aus die Maus. Fällt natürlich das Wlan der Fritte weg. Aber vielleicht ist ja ein entsprechender Wlan-AP besser?
Ansonsten müsstest du sehen, ob du die Systeme für VOIP als Withelisting bei ADG einträgst.
Alle meine Clients werfen ihre Requests an AGH und der an den lokalen Unbound. Letzterer hat keinen Upstream Server sondern macht die Rekursion selbst.
DNS und DoT nach außen ist blockiert, DoH ist per Blockliste im AGH so weit blockiert wie das möglich ist.
Eine Fritzbox 7510 hinter der OPNsense, die SIP, DECT und Smart Home macht, funktioniert einwandfrei.
Quote from: kruemelmonster on April 02, 2025, 03:37:08 PMHast du noch einen Port an der Sense frei oder ein separates Vlan? Dann hänge die Fritte dort an und spare dir die Mühe mit AdGuard. Wenn es ein dedizierter NIC ist, hast du da eben eine DMZ. Habe ich auch so gemacht. AdGuard ist dort nicht aktiv und aus die Maus. Fällt natürlich das Wlan der Fritte weg. Aber vielleicht ist ja ein entsprechender Wlan-AP besser?
Wäre zwar frei, aber ich hab da auch ein bisschen Smarthome per DECT laufen.
Quote from: kruemelmonster on April 02, 2025, 03:37:08 PMAnsonsten müsstest du sehen, ob du die Systeme für VOIP als Withelisting bei ADG einträgst.
Es wird ja nichts geblockt, ich verstehe es einfach nicht...Ich habe den ganzen Client ausgefiltert(siehe oben)
Quote from: Patrick M. Hausen on April 02, 2025, 03:38:58 PMAlle meine Clients werfen ihre Requests an AGH und der an den lokalen Unbound. Letzterer hat keinen Upstream Server sondern macht die Rekursion selbst.
DNS und DoT nach außen ist blockiert, DoH ist per Blockliste im AGH so weit blockiert wie das möglich ist.
Eine Fritzbox 7510 hinter der OPNsense, die SIP, DECT und Smart Home macht, funktioniert einwandfrei.
So mach ich das doch auch, wenn ich nichts weiter konfiguriert habe, oder?!
Hast du ne Idee wie ich checken kann, warum meine Clients keine o2 DNS Server kriegen, diese aber ja scheinbar benutzt werden, wenn ich normal ins Internet komme?!
Ich weiß ja nicht, was du mit "nichts weiter" meinst? Natürlich musst du den AGH auf Port 53 einstellen und den Unbound z.B. auf 53530. Und dann im AGH den Unbound explizit als Upstream eintragen: 127.0.0.1:53530.
Das ist etwas mehr als "nichts".
Wenn du das so hast, dann landet doch jeder Request im AGH Logfile, da kannst du dir das doch über das UI im Detail angucken, was da schief geht ...
Quote from: cottec on April 02, 2025, 11:02:31 AMhast du denn auch adguard und unbound am laufen?
Ja, habe ich.
Allerdings habe ich die FB in einem separaten VLAN, da die Stabilität der SIP Verbindungen durch das "Geschnatter" aller im Netz befindlichen Geräte empfindlich gestört war. Erst mit der Separierung der FritzBox gab es keine Unterbrechungen mehr bei der Verbindung.
WLAN realisiere ich durch separate AP, da auch die eingeschränkte Funktionalität der FB nicht mehr reichte um Netze zu separieren. Gleiches gilt für SmartHome.
Quote from: RES217AIII on April 02, 2025, 10:13:15 AMQuote from: cottec on April 01, 2025, 10:59:33 PMQuote from: Tuxtom007 on April 01, 2025, 08:10:35 PMFritzBox: wie hasst du die den angeschlossen, hinter der OPNSense als Client oder davor ?
Ah ne in Unraid ist alles okay, da hab ich keine Sorge.
Die Fritzbox ist als Client hinter der OPNsense.
Nochmal in aller Deutlichkeit: Wenn ich Unbound und Adguard deaktiviere, dann geht es sofort mit der VoIP Registrierung
In meiner Konfiguration habe ich bei DNS Server v4 vom Internetanbieter... eingestellt.
Damit ist die OPNsense der DNS Server: AdGuard -> Unbound. Abhängig von deiner Firewalleinstellung verhindert der "fremde" DNS Server bei aktivem AdGuard und Unbound eine Verbindung, weil die OPNsense diese blockiert
Schaltest Du Adguard und Unbound aus, wird der Zugriff auf den "fremden" DNS Server nicht mehr blockiert.
Quote from: Patrick M. Hausen on April 02, 2025, 04:58:02 PMIch weiß ja nicht, was du mit "nichts weiter" meinst? Natürlich musst du den AGH auf Port 53 einstellen und den Unbound z.B. auf 53530. Und dann im AGH den Unbound explizit als Upstream eintragen: 127.0.0.1:53530.
Das ist etwas mehr als "nichts".
Wenn du das so hast, dann landet doch jeder Request im AGH Logfile, da kannst du dir das doch über das UI im Detail angucken, was da schief geht ...
Ja hast recht, mehr als nichts, aber nichts exotisches, oder?
Und im AGH seh ich ja das Weiterleiten der DNS anfrage an die 127.0.0.1:53530
An einem anderen Client kann ich die Adresse von o2 ja auch nicht auflösen, direkt in der Opnsense aber schon.
Das wird also defintiv ein Konfigurationsproblem irgendwo in AGH oder Unbound sein, ich weiß nur nicht, wie ich das rauskriegen kann :(
Quote from: RES217AIII on April 03, 2025, 06:14:48 AMQuote from: cottec on April 02, 2025, 11:02:31 AMhast du denn auch adguard und unbound am laufen?
Ja, habe ich.
Allerdings habe ich die FB in einem separaten VLAN, da die Stabilität der SIP Verbindungen durch das "Geschnatter" aller im Netz befindlichen Geräte empfindlich gestört war. Erst mit der Separierung der FritzBox gab es keine Unterbrechungen mehr bei der Verbindung.
WLAN realisiere ich durch separate AP, da auch die eingeschränkte Funktionalität der FB nicht mehr reichte um Netze zu separieren. Gleiches gilt für SmartHome.
Das kann ja nicht die Lösung sein, ich meine ich kanns ausprobieren, aber ich fänds seltsam...
Quote from: RES217AIII on April 03, 2025, 06:39:58 AMDamit ist die OPNsense der DNS Server: AdGuard -> Unbound. Abhängig von deiner Firewalleinstellung verhindert der "fremde" DNS Server bei aktivem AdGuard und Unbound eine Verbindung, weil die OPNsense diese blockiert
Schaltest Du Adguard und Unbound aus, wird der Zugriff auf den "fremden" DNS Server nicht mehr blockiert.
Hast nen Tipp wie ich das systematisch angehen kann?
Quote from: cottec on April 03, 2025, 11:16:09 AMDas wird also defintiv ein Konfigurationsproblem irgendwo in AGH oder Unbound sein, ich weiß nur nicht, wie ich das rauskriegen kann :(
Was zeigt der AGH denn im Query-Log? Siehe Screenshot - da sieht man doch immer im Detail, was er tut.
Quote from: Patrick M. Hausen on April 03, 2025, 12:04:17 PMWas zeigt der AGH denn im Query-Log? Siehe Screenshot - da sieht man doch immer im Detail, was er tut.
Einmal die Anfragen der Fritzbox und einmal nslookup vom PC aus
Du hast da eine Filterregel drauf - mach die doch mal weg ...
die sagen ja nur: nichts blocken.
egal, hier ohne:
Nochmal Fritzbox und PC
Das sieht doch alles einwandfrei aus. Schneid mal eine Abfrage mit tcpdump mit.
Kannst du damit was anfangen?
Quote from: cottec on April 03, 2025, 05:37:16 PMKannst du damit was anfangen?
Auch wenn ich nicht gemeint bin und Patrick der sicherlich sehr viel bessere Helfer ist, möchte ich mich doch in einer Interpretation versuchen, auch um mitzulernen:
Da Adguard scheinbar funktioniert, aber in den tcdump Mitschnitt ein nxdomain auftaucht, kann das Problem in unbound und seiner Konfiguration liegen
Die NXDOMAIN-Antwort bezieht auf auf den FQDN mit angehängtem .localdomain - das ist vollkommen richtig so, das gibt es nicht.
Ich habe einen Verdacht, aber dazu brauche ich einen Mitschnitt einer Abfrage.
achso, meinst du das pcap file dazu?
Ich hatte eigentlich einfach den Text einer tcpdump-Session gemeint, damit wir hier drüber reden können. Etwa so:
33 164.773239 10.10.100.20 10.10.100.1 DNS 77 Standard query 0x027b AAAA sip.alice-voip.de
34 164.773376 10.10.100.1 10.10.100.20 DNS 156 Standard query response 0x027b AAAA sip.alice-voip.de SOA ns1.telefonica.de
35 164.773666 10.10.100.20 10.10.100.1 DNS 77 Standard query 0x98f7 A sip.alice-voip.de
36 164.773775 10.10.100.1 10.10.100.20 DNS 156 Standard query response 0x98f7 A sip.alice-voip.de SOA ns1.telefonica.de
Das sind die Anfragen auf dem internen Netz? Zwischen dem Client und dem AGH? Ich frag mich, weshalb da nur der SOA zurückkommt und kein AAAA oder A ...
1 0.000000 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
2 0.201723 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
3 5.023511 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
4 11.390696 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0xc558 A fritzbox.local, "QM" question
5 11.391079 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
6 15.022460 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
7 25.033630 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
8 26.089213 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
9 35.040288 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
10 45.047046 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
11 55.055307 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
12 71.415765 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0xf123 A fritzbox.local, "QM" question
13 71.416155 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
14 86.189287 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
15 109.111021 10.10.100.20 10.10.100.1 DNS 104 Dynamic update 0x9404 SOA myfritz.net A 10.10.100.20
16 109.111526 10.10.100.1 10.10.100.20 DNS 104 Dynamic update response 0x9404 Not implemented SOA myfritz.net A 10.10.100.20
17 109.111980 10.10.100.20 10.10.100.1 ICMP 132 Destination unreachable (Port unreachable)
18 114.118526 AVM_a5:1d:82 Protectli_f:0f:0c ARP 60 Who has 10.10.100.1? Tell 10.10.100.20
19 114.118535 Protectli_f:0f:0c AVM_a5:1d:82 ARP 42 10.10.100.1 is at 64:62:66:2f:0f:0c
20 125.040630 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
21 125.240948 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
22 130.054588 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
23 131.439897 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0xf85c A fritzbox.local, "QM" question
24 131.440277 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
25 140.054351 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
26 146.289370 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
27 150.062437 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
28 160.069346 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
29 164.770944 10.10.100.20 10.10.100.1 DNS 77 Standard query 0x3f6f NAPTR sip.alice-voip.de
30 164.771261 10.10.100.1 10.10.100.20 DNS 156 Standard query response 0x3f6f NAPTR sip.alice-voip.de SOA ns1.telefonica.de
31 164.772240 10.10.100.20 10.10.100.1 DNS 87 Standard query 0x2d94 SRV _sip._udp.sip.alice-voip.de
32 164.772388 10.10.100.1 10.10.100.20 DNS 166 Standard query response 0x2d94 No such name SRV _sip._udp.sip.alice-voip.de SOA ns1.telefonica.de
33 164.773239 10.10.100.20 10.10.100.1 DNS 77 Standard query 0x027b AAAA sip.alice-voip.de
34 164.773376 10.10.100.1 10.10.100.20 DNS 156 Standard query response 0x027b AAAA sip.alice-voip.de SOA ns1.telefonica.de
35 164.773666 10.10.100.20 10.10.100.1 DNS 77 Standard query 0x98f7 A sip.alice-voip.de
36 164.773775 10.10.100.1 10.10.100.20 DNS 156 Standard query response 0x98f7 A sip.alice-voip.de SOA ns1.telefonica.de
37 169.778536 AVM_a5:1d:82 Protectli_f:0f:0c ARP 60 Who has 10.10.100.1? Tell 10.10.100.20
38 169.778545 Protectli_f:0f:0c AVM_a5:1d:82 ARP 42 10.10.100.1 is at 64:62:66:2f:0f:0c
39 170.079954 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
40 179.739040 10.10.100.20 195.71.45.248 NTP 90 NTP Version 4, client
41 179.750915 195.71.45.248 10.10.100.20 NTP 90 NTP Version 4, server
42 180.090637 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
43 191.464756 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0xfdd5 A fritzbox.local, "QM" question
44 191.465148 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
45 206.389238 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
46 235.734145 10.10.100.20 239.255.255.250 SSDP 330 NOTIFY * HTTP/1.1
47 235.736166 10.10.100.20 239.255.255.250 SSDP 340 NOTIFY * HTTP/1.1
48 235.738153 10.10.100.20 239.255.255.250 SSDP 376 NOTIFY * HTTP/1.1
49 235.746880 10.10.100.20 239.255.255.250 SSDP 376 NOTIFY * HTTP/1.1
50 250.066649 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
51 250.267941 10.10.100.20 255.255.255.255 UDP 60 53805 → 53805 Len=12
52 251.489360 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0x4da7 A fritzbox.local, "QM" question
53 251.489749 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
54 255.079776 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
55 265.080169 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
56 266.489244 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
57 275.088756 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
58 285.099165 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
59 287.008011 10.10.100.20 239.255.255.250 SSDP 329 NOTIFY * HTTP/1.1
60 287.009046 10.10.100.20 239.255.255.250 SSDP 338 NOTIFY * HTTP/1.1
61 287.009709 10.10.100.20 239.255.255.250 SSDP 401 NOTIFY * HTTP/1.1
62 287.035468 10.10.100.20 239.255.255.250 SSDP 338 NOTIFY * HTTP/1.1
63 287.037643 10.10.100.20 239.255.255.250 SSDP 377 NOTIFY * HTTP/1.1
64 287.061186 10.10.100.20 239.255.255.250 SSDP 338 NOTIFY * HTTP/1.1
65 287.063356 10.10.100.20 239.255.255.250 SSDP 397 NOTIFY * HTTP/1.1
66 287.074955 10.10.100.20 239.255.255.250 SSDP 365 NOTIFY * HTTP/1.1
67 287.090581 10.10.100.20 239.255.255.250 SSDP 409 NOTIFY * HTTP/1.1
68 287.104045 10.10.100.20 239.255.255.250 SSDP 393 NOTIFY * HTTP/1.1
69 287.117775 10.10.100.20 239.255.255.250 SSDP 391 NOTIFY * HTTP/1.1
70 287.128322 10.10.100.20 239.255.255.250 SSDP 405 NOTIFY * HTTP/1.1
71 288.687143 10.10.100.20 239.255.255.250 SSDP 328 NOTIFY * HTTP/1.1
72 288.687569 10.10.100.20 239.255.255.250 SSDP 337 NOTIFY * HTTP/1.1
73 288.688009 10.10.100.20 239.255.255.250 SSDP 400 NOTIFY * HTTP/1.1
74 288.717483 10.10.100.20 239.255.255.250 SSDP 337 NOTIFY * HTTP/1.1
75 288.719132 10.10.100.20 239.255.255.250 SSDP 376 NOTIFY * HTTP/1.1
76 288.742637 10.10.100.20 239.255.255.250 SSDP 337 NOTIFY * HTTP/1.1
77 288.744786 10.10.100.20 239.255.255.250 SSDP 396 NOTIFY * HTTP/1.1
78 288.758590 10.10.100.20 239.255.255.250 SSDP 364 NOTIFY * HTTP/1.1
79 288.772502 10.10.100.20 239.255.255.250 SSDP 408 NOTIFY * HTTP/1.1
80 288.787224 10.10.100.20 239.255.255.250 SSDP 392 NOTIFY * HTTP/1.1
81 288.798500 10.10.100.20 239.255.255.250 SSDP 390 NOTIFY * HTTP/1.1
82 288.814559 10.10.100.20 239.255.255.250 SSDP 404 NOTIFY * HTTP/1.1
83 295.109941 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
84 305.120657 10.10.100.20 239.255.255.250 SSDP 167 M-SEARCH * HTTP/1.1
85 311.514116 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0xb86a A fritzbox.local, "QM" question
86 311.514537 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
87 326.589326 10.10.100.20 10.10.100.255 BROWSER 251 Host Announcement FRITZBOX, Server
88 326.648395 10.10.100.20 239.255.255.250 SSDP 339 NOTIFY * HTTP/1.1
89 326.650682 10.10.100.20 239.255.255.250 SSDP 348 NOTIFY * HTTP/1.1
90 326.652670 10.10.100.20 239.255.255.250 SSDP 391 NOTIFY * HTTP/1.1
91 326.656719 10.10.100.20 239.255.255.250 SSDP 403 NOTIFY * HTTP/1.1
92 326.660953 10.10.100.20 239.255.255.250 SSDP 405 NOTIFY * HTTP/1.1
93 326.664974 10.10.100.20 239.255.255.250 SSDP 419 NOTIFY * HTTP/1.1
94 326.669288 10.10.100.20 239.255.255.250 SSDP 383 NOTIFY * HTTP/1.1
95 340.356798 10.10.100.20 195.71.234.176 NTP 90 NTP Version 4, client
96 345.358533 AVM_a5:1d:82 Protectli_f:0f:0c ARP 60 Who has 10.10.100.1? Tell 10.10.100.20
97 345.358542 Protectli_f:0f:0c AVM_a5:1d:82 ARP 42 10.10.100.1 is at 64:62:66:2f:0f:0c
98 371.539729 10.10.100.20 224.0.0.251 MDNS 74 Standard query 0x7e7a A fritzbox.local, "QM" question
99 371.540137 10.10.100.20 224.0.0.251 MDNS 216 Standard query response 0x0000 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20 AAAA fd00::3681:c4ff:fea5:1d82 AAAA fe80::3681:c4ff:fea5:1d82 A 10.10.100.20
Nochmal: sind das die Anfragen auf dem internen Netz? Dann mach mal Trace auf dem lo0, um zu sehen, was der Unbound dem AGH schickt, und dann auf dem externen, was der Unbound im Internet einsammelt.
ja das sind die Anfragen der Clients bis zur OPNsense.
Also das sieht alles richtig aus, ja?
Sorry, ich mach die anderen traces gleich, ich musste erst mal verstehen was ich überhaupt zu tun hab, sorry :D
tcpdump -v -i lo0 -n port 53
tcpdump -v -i <wan interface> -n port 53
Und nein, das sieht eben nicht normal aus. Da sollte eigentlich eine Antwort mit einer IPv6- oder IPv4-Adresse zurück an den Client gehen, tut es aber nicht.
Ich mach die Abfragen gerade mit dem package caputure aus den OPNsense diagnostics, das tcpdump finde ich nicht für Windows.
Windump gäbe es da wohl noch, wenn ich das richtig sehe?!
Aber ich glaube die settings wie du sie beschreibst kriege ich auch in Opnsense rein, mach ich gleich
Auf der OPNsense tcpdump ausführen ... wir brauchen doch den Trace vom externen Interface der Sense - was willst du da auf dem Windows?
okay auf lo0 bleibt das logfile leer
auf wan gibts (ich hab am Client jetzt mal keine Abfrage gestartet. Das was hier im Log ist müsste die Fritzbox sein)
1 0.000000 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a 2001:668:1f:11::105 DNS 94 Standard query 0x15a5 A telefonica.de OPT
2 0.000001 XXX.XXX.98.73 195.243.137.26 DNS 74 Standard query 0x750f A telefonica.de OPT
3 0.000036 XXX.XXX.98.73 194.0.0.53 DNS 74 Standard query 0x416a A telefonica.de OPT
4 0.000042 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a 2001:67c:1011:1::53 DNS 94 Standard query 0x379a A telefonica.de OPT
5 0.000070 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a 2a02:568:0:2::53 DNS 94 Standard query 0x0f1f A telefonica.de OPT
6 0.010749 2a02:568:0:2::53 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a DNS 695 Standard query response 0x0f1f A telefonica.de NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de NSEC3 NSEC3 RRSIG RRSIG A 62.52.156.92 A 213.191.76.196 A 62.52.156.84 OPT
7 0.010862 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0x515a A ns3.telefonica.de OPT
8 0.011981 2001:67c:1011:1::53 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a DNS 695 Standard query response 0x379a A telefonica.de NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de NSEC3 RRSIG NSEC3 RRSIG A 62.52.156.92 A 213.191.76.196 A 62.52.156.84 OPT
9 0.012075 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0x836f A ns1.telefonica.de OPT
10 0.012097 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0xc42d A ns3.telefonica.de OPT
11 0.015486 195.243.137.26 XXX.XXX.98.73 DNS 675 Standard query response 0x750f A telefonica.de NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de NSEC3 NSEC3 RRSIG RRSIG A 62.52.156.92 A 213.191.76.196 A 62.52.156.84 OPT
12 0.015550 XXX.XXX.98.73 213.191.76.196 DNS 78 Standard query 0x426b A ns2.telefonica.de OPT
13 0.017729 194.0.0.53 XXX.XXX.98.73 DNS 675 Standard query response 0x416a A telefonica.de NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de NSEC3 NSEC3 RRSIG RRSIG A 62.52.156.92 A 213.191.76.196 A 62.52.156.84 OPT
14 0.017788 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0x242e A ns1.telefonica.de OPT
15 0.018088 2001:668:1f:11::105 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a DNS 695 Standard query response 0x15a5 A telefonica.de NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de NSEC3 NSEC3 RRSIG RRSIG A 62.52.156.92 A 213.191.76.196 A 62.52.156.84 OPT
16 0.018145 XXX.XXX.98.73 213.191.76.196 DNS 78 Standard query 0x0d29 A ns2.telefonica.de OPT
17 0.022472 62.52.156.92 XXX.XXX.98.73 DNS 176 Standard query response 0x836f A ns1.telefonica.de A 62.52.156.92 NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de A 213.191.76.196 A 62.52.156.84 OPT
18 0.022606 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0xed7c A sip.alice-voip.de OPT
19 0.022951 62.52.156.92 XXX.XXX.98.73 DNS 176 Standard query response 0x515a A ns3.telefonica.de A 62.52.156.84 NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de A 62.52.156.92 A 213.191.76.196 OPT
20 0.023028 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0x13dd A sip.alice-voip.de OPT
21 0.024208 62.52.156.92 XXX.XXX.98.73 DNS 176 Standard query response 0xc42d A ns3.telefonica.de A 62.52.156.84 NS ns2.telefonica.de NS ns3.telefonica.de NS ns1.telefonica.de A 213.191.76.196 A 62.52.156.92 OPT
22 0.029458 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0x13dd A sip.alice-voip.de SOA ns1.telefonica.de OPT
23 0.029519 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0xd483 NAPTR sip.alice-voip.de OPT
24 0.031466 62.52.156.92 XXX.XXX.98.73 DNS 176 Standard query response 0x242e A ns1.telefonica.de A 62.52.156.92 NS ns2.telefonica.de NS ns3.telefonica.de NS ns1.telefonica.de A 213.191.76.196 A 62.52.156.84 OPT
25 0.032700 62.52.156.92 XXX.XXX.98.73 DNS 157 Standard query response 0xed7c A sip.alice-voip.de SOA ns1.telefonica.de OPT
26 0.032760 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0x0595 NAPTR sip.alice-voip.de OPT
27 0.034968 213.191.76.196 XXX.XXX.98.73 DNS 176 Standard query response 0x426b A ns2.telefonica.de A 213.191.76.196 NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de A 62.52.156.92 A 62.52.156.84 OPT
28 0.035953 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0xd483 NAPTR sip.alice-voip.de SOA ns1.telefonica.de OPT
29 0.036205 213.191.76.196 XXX.XXX.98.73 DNS 176 Standard query response 0x0d29 A ns2.telefonica.de A 213.191.76.196 NS ns1.telefonica.de NS ns2.telefonica.de NS ns3.telefonica.de A 62.52.156.92 A 62.52.156.84 OPT
30 0.037717 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0xac10 A sip.alice-voip.de OPT
31 0.037767 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0x8425 A sip.alice-voip.de OPT
32 0.039463 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0x0595 NAPTR sip.alice-voip.de SOA ns1.telefonica.de OPT
33 0.044480 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0x8425 A sip.alice-voip.de SOA ns1.telefonica.de OPT
34 0.044616 XXX.XXX.98.73 213.191.76.196 DNS 83 Standard query 0xfeb0 A _udp.sip.alice-voip.de OPT
35 0.044680 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0xac10 A sip.alice-voip.de SOA ns1.telefonica.de OPT
36 0.044738 XXX.XXX.98.73 213.191.76.196 DNS 83 Standard query 0x56df A _udp.sip.alice-voip.de OPT
37 0.062468 213.191.76.196 XXX.XXX.98.73 DNS 162 Standard query response 0x56df No such name A _udp.sip.alice-voip.de SOA ns1.telefonica.de OPT
38 0.062475 213.191.76.196 XXX.XXX.98.73 DNS 162 Standard query response 0xfeb0 No such name A _udp.sip.alice-voip.de SOA ns1.telefonica.de OPT
39 0.062542 XXX.XXX.98.73 62.52.156.84 DNS 88 Standard query 0x4326 SRV _sip._udp.sip.alice-voip.de OPT
40 0.062543 XXX.XXX.98.73 62.52.156.84 DNS 88 Standard query 0x76d3 SRV _sip._udp.sip.alice-voip.de OPT
41 0.069059 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a 2001:4860:4802:38::a DNS 95 Standard query 0x107a A www.google.com OPT
42 0.069102 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a 2001:4860:4802:36::a DNS 95 Standard query 0x3db2 A www.google.com OPT
43 0.069270 62.52.156.84 XXX.XXX.98.73 DNS 167 Standard query response 0x4326 No such name SRV _sip._udp.sip.alice-voip.de SOA ns1.telefonica.de OPT
44 0.069280 62.52.156.84 XXX.XXX.98.73 DNS 167 Standard query response 0x76d3 No such name SRV _sip._udp.sip.alice-voip.de SOA ns1.telefonica.de OPT
45 0.070777 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0x701a A sip.alice-voip.de OPT
46 0.070826 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0xf183 A sip.alice-voip.de OPT
47 0.071050 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0x12e0 A sip.alice-voip.de OPT
48 0.077206 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0xf183 A sip.alice-voip.de SOA ns1.telefonica.de OPT
49 0.077277 XXX.XXX.98.73 62.52.156.92 DNS 78 Standard query 0x725d AAAA sip.alice-voip.de OPT
50 0.077461 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0x12e0 A sip.alice-voip.de SOA ns1.telefonica.de OPT
51 0.082951 2001:4860:4802:38::a 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a DNS 111 Standard query response 0x107a A www.google.com A 142.250.185.228 OPT
52 0.084712 62.52.156.92 XXX.XXX.98.73 DNS 157 Standard query response 0x701a A sip.alice-voip.de SOA ns1.telefonica.de OPT
53 0.084788 XXX.XXX.98.73 62.52.156.84 DNS 78 Standard query 0x4d07 AAAA sip.alice-voip.de OPT
54 0.087716 2001:4860:4802:36::a 2a02:3100:3203:4c12:6662:66ff:fe2f:f0a DNS 111 Standard query response 0x3db2 A www.google.com A 142.250.185.228 OPT
55 0.091215 62.52.156.92 XXX.XXX.98.73 DNS 157 Standard query response 0x725d AAAA sip.alice-voip.de SOA ns1.telefonica.de OPT
56 0.091450 62.52.156.84 XXX.XXX.98.73 DNS 157 Standard query response 0x4d07 AAAA sip.alice-voip.de SOA ns1.telefonica.de OPT
57 21.705023 XXX.XXX.98.73 23.211.133.67 DNS 81 Standard query 0x50a1 A s-overseer.avcdn.net OPT
58 21.705059 XXX.XXX.98.73 23.211.133.67 DNS 81 Standard query 0x8d13 A s-overseer.avcdn.net OPT
War mein Fehler mit dem tcpdump beim lo0 - da hätte natürlich der Port rein gehört, auf dem du deinen Unbound lauschen hast, und nicht 53.
Aber wie man an dem trace sieht, geht das ja extern schon schief. Also hab ich mir das mal bei mir lokal angeguckt und siehe da:
root@opnsense:~ # drill @ns1.telefonica.de alice-voip.de ns
[...]
;; ANSWER SECTION:
alice-voip.de. 345600 IN NS ns3.telefonica.de.
alice-voip.de. 345600 IN NS ns1.telefonica.de.
alice-voip.de. 345600 IN NS ns2.telefonica.de.
Aber:
root@opnsense:~ # drill @ns1.telefonica.de sip.alice-voip.de a
[...]
;; ANSWER SECTION:
;; AUTHORITY SECTION:
alice-voip.de. 345600 IN SOA ns1.telefonica.de. hostmaster\.de.telefonica.com. 2017032874 28800 7200 1814400 345600
Also man bekommt von den authoritativen (!) Nameservern von Telefonica von extern einfach eine leere Antwort zurück. Anscheinend bekommt man die Adressen des SIP-Gateways nur, wenn man auch die rekursiven DNS-Server von Telefonica nutzt.
Das kann man aber im Unbound recht einfach konfigurieren, indem man ein Query-Forwarding definiert, etwa so:
(https://forum.opnsense.org/index.php?action=dlattach;attach=43910;image)
Die Adressen, die ich benutzt habe, sind dns3.telefonica.de und dns4.telefonica.de.
Gruß, HTH,
Patrick
Ach krass, das funktioniert einfach 😮
Dank dir !!!!!!!
Kannst du mir verraten woran du das erkannt hast?!?!
Und was ich nach wie vor nicht verstehe, die DNS Server sind ja in der Fritzbox eingetragen, warum gehen die verloren unterwegs?
Daran, dass ich die Adressen per drill (s.o.) von den authoritativen DNS-Servern für die Domain nicht bekommen habe. Steht doch alles im letzten Post. Die Adressen der rekursiven Server von Telefonica hab ich aus deinen Dumps.
Zur Fritzbox: hast du vielleicht ein "fang DNS Requests ein" per NAT Port Forward auf deiner OPNsense?
Quote from: Patrick M. Hausen on April 02, 2025, 03:38:58 PMDNS und DoT nach außen ist blockiert, DoH ist per Blockliste im AGH so weit blockiert wie das möglich ist.
Hallo,
über welche Blockliste lässt sich denn DoH hier blockieren?
Danke und beste Grüße
https://github.com/hagezi/dns-blocklists?tab=readme-ov-file#bypass
Quote from: Patrick M. Hausen on April 05, 2025, 06:04:47 PMDaran, dass ich die Adressen per drill (s.o.) von den authoritativen DNS-Servern für die Domain nicht bekommen habe. Steht doch alles im letzten Post. Die Adressen der rekursiven Server von Telefonica hab ich aus deinen Dumps.
Zur Fritzbox: hast du vielleicht ein "fang DNS Requests ein" per NAT Port Forward auf deiner OPNsense?
ich hab kein port forwards außer dieser automatischen LAN anti lockout Regel.
Für die Fritz ansonsten nur ein Outbound NAT:
nat.JPG
Regeln sind für das Interface noch auf allow any
@Patrick M. Hausen - danke :)
Quote from: Patrick M. Hausen on April 02, 2025, 03:38:58 PMDNS und DoT nach außen ist blockiert
Das Thema hab ich auch noch auf der Agenda, hast du da nette Lektüre zum Nachkochen?
Soweit ich das verstanden habe muss ich mich ja um 3 Sachen kümmern - Alles an DNS und DoT auf Adguard verweisen - Unbound aber rauslassen (?) - Verhindern, dass die IoT Clients Fehler schmeißen wegen der umgeleiteten DNS Anfragen?
Quote from: Patrick M. Hausen on October 03, 2024, 05:28:55 PMBei mir ist Unbound der Default-Nameserver auf Port 53 überall. AdGuard Home liegt auf 127.0.0.1:53530 und hat 127.0.0.1:53 als einzigen Upstream.
Auf allen Interface, bei denen ich will, dass die Clients AGH benutzen, habe ich eine NAT Port Forward Regel von TCP/UDP, Destination: this firewall:53 nach 127.0.0.1:53530.
Ich versuche das gerade auch... (bei mir sind die Ports aber umgedreht von Adguard (53)und Unbound (53053)
LAG 10.10.100.1 ist mein Interface an dem alle Geräte hängen
Ich habe diese NAT Port Forwards:
nat2.JPG
Zum Test in Adguard eine DNS Umschreibung dnsintersect.example.com auf 10.0.1.1
Wenn ich das jetzt teste:
nslookup dnsintersect.example.com
Server: UnKnown
Address: 10.10.100.1
Nicht autorisierende Antwort:
Name: dnsintersect.example.com
Address: 10.0.1.1
Die Umschreibung funktioniert, AAABER:
nslookup dnsintersect.example.com 1.1.1.1
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 1.1.1.1
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.Das Abfangen und Umleiten von Anfragen mit anderen DNS Servern funktioniert nicht...
Ich wette ich hab nur was in den Regeln falsch geschrieben....