Problem bei dynamic DNS in Zusammenspiel mit DNAT

[lxnet]

Hallo zusammen,

ich habe ein Verständnisproblem bezüglich dynamic DNS in Zusammenspiel mit DNAT.

Kurz zum Aufbau. Ich habe einen Router mit OPNsense 18.7.2. Die Interneteinwahl erfolgt über PPPoE. Es gibt einen dynamic DNS für die WAN und eine DMZ mit einem murmur Server. Es ist ein DNAT für den murmur Server eingerichtet.

Nun zu meinem Problem. Ein Client versucht sich über das Internet zum murmur Server zu verbinden. Wenn der Client versucht sich über den dynamic DNS Namen zu verbinden und ich einen tcpdump auf dem OPNsense mache sehe ich wie das Datenpaket über die WAN zur DMZ und zum murmur Server durch gereicht wird. Der murmur Server sendet sein Antwortpaket über die DMZ zur WAN Schnittstelle zurück und dann wird das Paket verworfen. Das Paket wird nicht ins Internet geroutet. Der Verbindungsaufbau des Clients läuft in den time out.
Versucht der Client hingegen eine Verbindung nicht über den dynamic DNS Name sondern über die gerade aktuelle Public IP funktioniert der Verbindungsaufbau problemlos.
Deswegen vermute ich eine Fehlkonfiguration beim DNAT. Irgendwie fehlt hier eine Verknüpfung zum dynamic DNS Name.
Ich habe im DNAT unter destination WAN address eingetragen. Auch ein versuch mit This Firewall und ein Versuch über Alias eine Verbindung zu schaffen schlug fehl. Ich arbeite beruflich mit OpenWRT. OpenWRT verknüpft automatisch die WAN Zone mit dynamic DNS. Ist das bei OPNsense anders? Wenn ja wo muss ich die Verknüpfung konfigurieren?

Vielen Dank für Eure Hilfe!

[JeGr]

Ich habe leider ein Verständnisproblem mit deinem Post, denn ich verstehe nicht, was an der Stelle DynDNS mit IP respektive Port Forwarding (nicht DNAT) zu tun haben soll.

Du hast ein Port Forwarding eingerichtet, dass - vermute ich - offenbar funktioniert mit WAN Address und Destination auf die DMZ IP. Ansonsten wäre ja die Aussage falsch, dass es mit der public IP funktioniert? Wenn dem so ist und es mit der IP funktioniert, müsste es dies auch mit dem DNS Namen. Es gibt keine Zuordnung oder sonstwie Verknüpfung. Das macht auch gar keinen wirklichen Sinn. Der DynDNS Name wird aufgelöst -> public IP, Verbindung, fertig. Da gibt es keine Magie die das irgendwie zusammenklebt (wozu auch?).

Wenn der Connect mit DNS nicht funktioniert vermute ich den Fehler eher an was anderem. Aber wenn der reine IP4 connect sauber funktioniert, sollte es auch mit dem DNS Namen tun.

Gruß

[lxnet]

Hallo JeGr,

danke für deine schnelle Antwort! Ich bin der selben Meinung wie Du. Mich hätte das auch gewundert...

Nur noch einmal damit wir nicht aneinander vorbei reden. Der Client kann sich über die public IP verbinden. Da sich diese aber regelmäßig ändert habe ich einen DynDNS eingerichtet. Der funktioniert auch, das habe ich mehrmals per nmap getestet. Will der Client sich aber über den DynDNS verbinden laufen die Pakete sauber über das Port Forwarding bis zum Server durch, der schickt sein Antwortpaket an den Client zurück wo diese aber nie ankommt.

Das verstehe ich überhaupt nicht ...     

Gruß

[JeGr]

> Nur noch einmal damit wir nicht aneinander vorbei reden. Der Client kann sich über die public IP verbinden.

Aye, soweit so gut

> Da sich diese aber regelmäßig ändert habe ich einen DynDNS eingerichtet.

Ebenfalls gut

> Der funktioniert auch, das habe ich mehrmals per nmap getestet.

Mit nmap? Wie testest du ob die DynDNS Adresse geht mit nmap? Ich würde jetzt mal sagen, wenn nach einer Neuverbindung die IP sauber an den DynDNS Provider übermittelt wird und sich damit ordentlich ändert, sollte es funktionieren. Wenn nicht -> DynDNS checken.

> Will der Client sich aber über den DynDNS verbinden laufen die Pakete sauber über das Port Forwarding bis zum Server durch, der schickt sein Antwortpaket an den Client zurück wo diese aber nie ankommt.

Nope, das ist der Punkt an dem es komplett unrealistisch wird. Die Pakete haben - außer auf Anwendungsebene bei HTTP und Co. - keinerlei Inhalt der sich mit oder ohne DynDNS verändert. TCP/UDP bleibt TCP/UDP und da steht nur ne IP drin. Dass du schreibst dass sie bis zum Ziel durchlaufen muss ich glauben und annehmen, dass sie aber dann abgehend verpuffen glaube ich nicht wirklich. Dann ist entweder die abgehende NAT Käse (gibt es abgehend mehrere IPs dass da was rotiert?) oder es stimmt was anderes grundsätzlich nicht. Da ist aber kein MultiWAN oder sonstwas dran? Mehrere Gateways? Von wo (extern) und wie (DNS mit/ohne) testest du?

[lxnet]

Hallo JeGr,

na mit sudo nmap -Pn -sU -p 64738 meindnsname.dd-dns.de

Geht aber auch im Webinterface des Providers  ;-)

Mir kam gerade auf der Heimfahrt die Idee mal einen anderen DynDNS Dienst auszuprobieren. Nur um zu sehen ob der Fehler bleibt oder weg ist.
Wenn der Fehler weg ist würde das für mich gar keinen Sinn machen aber irgendwie muss ich ja mal den Fehler eingrenzen.

Ich habe nur eine public IP und MultiWAN ist auch nicht konfiguriert.

Ich berichte nachher über das Ergebnis.

[lxnet]

Manchmal sieht man vor lauter Bäumen den Wald nicht mehr und es ist gut wenn man eine zweite Person zur Unterstützung hat um wieder einen klaren Blick zu bekommen. Einen ganz großen Dank dafür JeGr! Ich hatte mich zu sehr auf das Port Forwarding als Ursache versteift ...

Ich habe die Ursache für das Problem gefunden, auch wenn es jeglicher Logik widerspricht und mit Sicherheit auf meiner Liste der unerklärbaren IT Phänomene laden wird...
 
Im Webinterface meines DynDNS Providers stand eine andere public IP drin als ich tatsächlich hatte. Das erklärt warum der Verbindungsaufbau nicht zustande kam. Es erklärt aber nicht
- warum konnte ich erfolgreich meinen DynDNS Namen anpingen?
- warum konnte ich erfolgreich einen Portscan über meinen DynDNS Name machen?
- warum sah ich im Dump die Pakete bis zum Server durchlaufen?
- warum stand im Logfile des Routers das er sich erfolgreich beim DynDNS Provider angemeldet hatte?

Ich glaube diese Fragen werden wohl nie wirklich beantwortet werden ...

Erst als ich im Webinterface meines DynDNS Providers auf IP aktualisieren gedrückt hatte funktionierte es problemlos.

[JeGr]

> Es erklärt aber nicht

Vielleicht kann ich helfen

> - warum konnte ich erfolgreich meinen DynDNS Namen anpingen?

Das ist einfach, dein DynDNS nicht aktualisiert wird jetzt einfach auf einen anderen Kunden zeigen der Online ist und zudem "pingbar", dessen Endgerät also antwortet.

> - warum konnte ich erfolgreich einen Portscan über meinen DynDNS Name machen?

Gleicher Grund. Wird wohl ein anderer Kunde mit aktiven Ports gewesen sein.

> - warum sah ich im Dump die Pakete bis zum Server durchlaufen?

Der ist schwierig. Die Frage ist ob du überhaupt die Pakete von DIR und deinem Test gesehen hast. Wie gefragt: Wie hast du das getestet? Du kannst DynDNS Zugriff ja nur von extern testen, nicht von intern?

> - warum stand im Logfile des Routers das er sich erfolgreich beim DynDNS Provider angemeldet hatte?

Welchem Router? Der Sense oder nochwas vornedran? Mitunter geben die je nach Provider eben auch OK zurück, wenn sie nur die PUSH-URL für den Service sauber mit 200 quittiert bekommen. Das kommt ganz auf DynDNS Provider + Antwort und Gegenstelle an.

> Erst als ich im Webinterface meines DynDNS Providers auf IP aktualisieren gedrückt hatte funktionierte es problemlos.

Ärgerlich. Deshalb lasse ich meine Sense das DynDNS machen bzw. brauche inzwischen keinen DynDNS Provider mehr - da ich meine Spieldomain dafür zu Cloudflare gepackt habe und via API dort direkt meine IP hinpushen lasse - klappt toll. Und im Dashboard sieht man ob der DynDNS Eintrag aktiv/korrekt ist oder nicht.

[lxnet]

> Welchem Router? Der Sense oder nochwas vornedran?

Nur der Vollständigkeit halber, ich habe nur die Sense mit einem ADSL Modem. Es gibt keinen zweiten Router.
Im Dashboard und unter Services / Dynamic DNS war die PIP grün. Im Logfile sah ich das die Sense sich erfolgreich beim DynDNS registriert hatte. Da ich gerade nicht davor sitze kann ich Dir nicht zu 100% sagen welches Logfile es war, kann aber heute Abend noch einmal nachsehen. Deswegen kam mir auch nicht der Gedanke das da etwas nicht stimmen könnte.

Ich finde auch das DynDNS nicht die sauberste Lösung ist. Privat kann man es nutzen da ein Ausfall meist verkraftbar ist. Beruflich setze ich auf eine VPN Lösung. Ich habe beruflich draußen vor Ort immer zwei Internetanschlüsse (primär meist Festnetz und als Backup Mobilfunk) weil die Anlagen redundant angebunden sein müssen. Die Anlagen müssen aber immer über ein und die selbe public IP erreichbar sein. Deswegen baut der Router vor Ort als OVPN Client einen Tunnel zum OVPN Server auf. Auf dem OVPN Server ist die public IP konfiguriert über die wir uns zu den Anlagen verbinden können. Das läuft bisher sehr stabil.
Ich habe gesehen das man so etwas (public IP über VPN) für kleines Geld kaufen kann. Vielleicht wäre das privat eine bessere Lösung als DynDNS. Erfahrung habe ich allerdings mit solchen Anbietern nicht.

[JeGr]

OK dann war das aber eine sehr seltsame Konstellation. Wenn die externe Adresse grün und OK gemeldet wurde, dann ist das merkwürdig, dass hier die DynDNS Adresse beim Provider nicht gestimmt hat.

An der Stelle wie gesagt nur der Tipp, das ggf. über einen anderen Provider zu machen oder zu prüfen, ob dieser eine Rückmeldung beim Update gibt und der Adresscheck sauber funktioniert. Ansonsten nutze ich das selbst auch für VPN oder Zugriff auf Dienste von bestimmten Locations und das hat bisher auch immer sauber funktioniert