OPNsense Forum
International Forums => German - Deutsch => Topic started by: bforpc on July 19, 2023, 12:44:44 pm
-
Hallo,
im Intranet ist die die OPNsense mit Multi WAN natürlich auch der DNS Server. Von einem Client aus ist der Port 53 an der FW verfügbar. "Unbound DNS" ist aktiv.
Jedoch werden keine Namen aufgelöst.
An der Konsole der OPNsense jedoch schon. Ich habe auch an den Einstellungen in System->Settings->General mal gespielt, jedoch keine Verbesserung.
Bfo
-
Was bekommen denn die Clients als DNS-Server vom DHCP-Server serviert? Ist das die LAN-IP-Adresse der OPNsense?
Was passiert wenn du auf einem Client z.B.
dig google.com @<ip-der-opnsense>
eingibst? Das genaue Tool hängt natürlich von deinem Client-OS ab.
-
Hallo Patrick,
danke für deine Mail. Genau das hatte ich auch schon versucht.
Die Clients bekommen, bzw. ich habe das auch manuell festgelegt (debian: /etc/resolv.conf) die LAN Ip der OPNsense.
ein dig heise.de @9.9.9.9 funktioniert, ein dig heise.de oder dig heise.de @[ip der fw], funktioniert *nicht* mit der Meldung
"Temporärer Fehler bei der Namensauflösung"
Bfo
sockstat -4 -l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
unbound unbound 44703 7 udp4 *:53 *:*
unbound unbound 44703 8 tcp4 *:53 *:*
unbound unbound 44703 11 udp4 *:53 *:*
unbound unbound 44703 12 tcp4 *:53 *:*
unbound unbound 44703 15 udp4 *:53 *:*
unbound unbound 44703 16 tcp4 *:53 *:*
unbound unbound 44703 19 udp4 *:53 *:*
unbound unbound 44703 20 tcp4 *:53 *:*
-
Irgendwelche Access-Listen beim Unbound?
Was sagt Services > Unbound DNS > General > Network Interfaces?
-
Stand auf "all Interfaces". Aber auch eine Einstellungen auf das LAN Interface hat nicht geholfen
Keine besondere oder manuellen Access listen, Lan ist in der Liste.
Könnte es etwas damit zu tun haben, dass das WAN Interface nicht WAN heisst?
bfo
-
Lass das auf "All (recommended") stehen - es gibt einen Grund, weshalb da "recommended" steht.
Wie das WAN-Interface heißt sollte egal sein.
Jetzt machst du ein tcpdump auf dem LAN und eins auf dem WAN und löst nochmal so einen Lookup aus und guckst, was passiert.
-
Hallo, habe nun folgendes gemacht: Auf der FW habe ich in 2 Fenstern jeweils einen trcpdump laufen und während dessen auf dem Client 10.41.10.254 ein dig heise.de
//lan Interface der FW ist 10.41.10.99
tcpdump -ni igb0 src host 10.41.10.254 and port 53
15:34:22.920401 IP 10.41.10.254.51546 > 10.41.10.99.53: 7493+ [1au] A? heise.de. (49)
Wenn ich vom Client aus einen dig @9.9.9.9 heise.de mache, bnekomme ich
15:37:06.639976 IP 10.41.10.254.57259 > 9.9.9.9.53: 60361+ [1au] A? heise.de. (49)
WAN Interface
tcpdump -ni igb3 dst host 10.41.10.254 and port 53
[hier kommt nichts an]
Bfo
-
Auf dem WAN hat das Paket ja auch nicht die interne IP-Adresse als destination.
Lass die Host-Filter mal weg und schränke nur auf port 53 ein. Mit einem Trace auf LAN und einem auf WAN solltest du folgendes sehen:
Client (LAN) --> OPNsense
OPNsense (WAN) --> Internet, möglicherweise mehrere Transaktionen
Internet --> OPNsense (WAN)
OPNsense (LAN) --> Client
Zu beobachten ist, an welcher Stelle die Kette unterbrochen wird.
-
Hallo,
das ist leider nicht so einfach zu überblicken, weil zig clients ständig dns Anfragen senden...
auf Lan Seite sieht es so aus:
15:51:44.180917 IP 10.41.10.254.38141 > 10.41.10.99.53: 46397+ [1au] A? heise.de. (49)was scheinbar richtig ist - Client 254 sende eine Anfrage und diese wird an die FW gegeben (und von dort kommt nichts zurück).
Gleichzeitig sehe ich auf dem WAN Interface zwar Anfragen, aber keine, welche "heise.de" abfragen will.
Kann es doch mit dem Multi Wan zusammen hängen (Obwohl jetzt nur noch eines aktiv ist)?
Es existiert auch nur ein aktives Gateway (das zweite ist deaktiviert).
Zur Info: Auf der Konsole der FW ist die DNS Auflösung korrekt und funktioniert.
Bfo
-
Irgendwas mit explizitem Gateway? Sorry, über das Forum fast unmöglich. Jag das Debug-Level vom Umbound hoch und guck in die Logs. Kommt der Request überhaupt beim Umbound and oder liegt der gar nicht auf Port 53 etc. pp.
Das mentale (und auch tatsächliche) Modell, wie so ein Request ablaufen sollte, hatte ich oben kurz skizziert. Um das aufzudröseln, muss man nun jeden einzelnen Schritt überprüfen - ob der so stattfindet wie er sollte. Wenn du dazu abends oder am WE mal alle anderen Clients blocken musst, dann ist das eben so ... so ist unser Handwerk als Netzwerkingenieure.
Hab leider auch keine Glaskugel ;)
EDIT: wie ich so über meinen eigenen Beitrag "hirne" - einen Glaskugel-Versuch doch noch ;)
Hast du evtl. auf dem LAN eine Regel mit Destination "any" und explizit gesetztem Gateway oder Gateway Group für dein Multi-WAN? Der Paketfilter liegt natürlich unter/vor dem Socket-API, mit dem der Unbound kommuniziert. M.a.W. das Paket mit dem Request kommt rein, die Regel greift sich das, wirft es zum Gateway, und der Unbound bekommt es niemals zu sehen ...
Lösung wäre dann eine Regel mit Destination "Interface der OPNsense" und "allow" ohne die Gateway-Geschichte, und natürlich weiter oben in der Reihenfolge.
-
Moin Patrick,
nochmals danke für deine Tipps. Natürlich kannst du nicht - ums mit deinen Worten zu sagen - aus der Glaskugel das Problem lösen. Ich nehme aber alle Tipps gerne entgegen.
Es existiert keine Regel auf dem Lan, welches ein bestimmtes GW nutzt.
Ich habe das 2. WAN auch deaktiviert sowohl als Interface als auch als GW. Kein Unterschied.
Was aber auffällig ist: Die Konsole der FW löst die Namen korrekt auf.
Ein Client aber nicht. Und selbst ein
dig @9.9.9.9 heise.de
auf einem Client erhält ein "connection timed out; no servers could be reached".
Ein
dig @[opnsense IP] antwortet mit ";heise.de. IN A" (also ohne IP Adresse der Domäne).
Das sieht doch eher nach einem "DNS<->Routing"-Problem aus!?
Bfo
EDIT: Ich habe soeben mal das 2. WAN Interface gelöscht und die FW neu gestartet. Jetzt funktioniert alles. Sobald ich das 2. WAN Interface hinzufüge, gehts nicht mehr.
-
Hallo liebe Leser,
das Problem lag *nicht* an der OPNsense, sondern am "Provider". Dieser hatte noch Regeln aktiv, welche die Rückleitung für DNS blockirten. Somit ... viel Wirbel um nichts. Dennoch kann ich für mich sagen, dass ich wieder neue Erfahrungen machen konnte.
Vielen Dank @ all, vor allem an Patrick.
Bfo