Hallo.
Folgendes Problem hier:
Wenn ich auf einem Rechner in der DMZ per ldapsearch über Port 636 den Server abfrage, erhalte ich ein Ergebnis, wenn ich dessen IP Adresse 10.16.1.1 oder aber dessen vollständigen FQDN verwende.
Mache ich das gleiche von zu Hause aus, kommt die Anfrage über den öffentlichen dynDNS Namen ebenfalls an. Die Firewall leitet also Anfragen auf Port 636 für diese Fälle richtig weiter!
Was aber nicht klappt: wenn ich die Anfrage in der DMZ über den öffentlichen dynDNS Namen absetze, erhalte ich keine Antwort; genauer gesagt passiert nichts weiter. Ich vermute, dass das Ergebnis der Anfrage ins Nirvana gesendet wurde?!?
Zum Setting: Wir haben hier „interner FQDN = externer FQDN“ gewählt und zudem ein unbound für die Server Adresse gesetzt, so dass alle internen Anfragen direkt an den Server umgeleitet werden können.
Ich frage mich, warum das aus der DMZ nicht funktioniert bzw wo/warum es hängt?
Erster und naheliegender Gedanke: Die Firewall-Regeln für die DMZ blockieren das?! Daher habe ich zu Testzwecken auf der OPNSense bereits für die DMZ alles erlaubt. Daran liegt es aber nicht!
Wer hat einen Vorschlag, wie man das eingrenzen kann?
Viele Grüße
Michael
Hallo Michael,
das habe ich noch nicht ganz kapiert.
Du hast einen öffentlichen FQDN, und mit dem klappt alles aus der DMZ
heraus.
Wozu hast Du dann noch einen DynDNS-Namen? Oder ist der FQDN ein
DynDNS-Name? Kann nicht sein: Du schreibst ja, dass es mit dem FQDN aus
der DMZ heraus geht, nicht aber mit dem DynDNS-Namen.
Vielleicht bin ich ja auch nur zu blöd, aber könntest Du das nochmal
kurz erklären? Wichtig ist insbesondere, auf welche IPs die Namen in der
DMZ aufgelöst werden.
Normalerweise kann man solche Probleme dadurch lösen, dass man in der
DMZ den DNS-Eintrag überschreibt, dass also zum Beispiel der Hostname
auf die 10.16.1.1 aufgelöst wird.
Beste Grüße
Jörg
Hi.
Da wir intern wie extern den gleichen FQDN verwenden und zusätzlich das unbound eingestellt ist, nehme ich an, dass eine Anfrage über ldapsearch server.unsere-domain.de erst gar nicht wirklich ins Internet geht, um dann von außen (WAN) die Anfrage zu stellen. Stattdessen dürfte das direkt zum Server umgeleitet werden. Wenn ich aber aus der DMZ heraus den DynDNS Namen nehme, muss ja zunächst der DynDNS Dienst im Internet nach der zZ richtigen IP befragt werden. Die Anfrage müsste dann also über WAN raus und wieder reinkommen – und genau das funktioniert hier nicht.
Dass wir das überhaupt so gelöst haben, liegt daran, dass unser Provider uns trotz 1GBit Glasfaser-Paket keine feste IP anbieten kann. Es ist also weiterhin ein dynDNS Service notwendig, um von außen den Server erreichen zu können
Jetzt klarer?? Oder soll ich noch weiter ausholen?
Viele Grüße
Michael
Hallo Michael,
jetzt habe ich es kapiert, danke.
Du benötigst vermutlich NAT Reflection. Das kannst Du bei der Port-Forwarding-Regel aktivieren.
Alternativ kannst Du auch dem Unbound beibringen, den DynDNS-Namen auf die 10.16.1.1 aufzulösen.
Beste Grüße
Jörg
1 „Gefällt mir“
Hallo Jörg, du hast das richtige Buzzword geliefert, denke ich. Hier wird das ganze nochmal ausführlicher erklärt. Klingt genau nach dem o.g. Problem
https://forum.opnsense.org/index.php?topic=7627.0
Besten Dank und ebensolche Grüße
Michael