DynDNS Client Einstellungen für STRATO



  • Hallo,

    hat es bereits jemand geschafft, den pfSense-DynDNS-Client so einzustellen, dass er auf Dauer erwartungsgemäß die IP einer bei STRATO gehosteten Domain updated?

    Bisher funktioniert es nur, die der Domäne zugewiesene IP manuell durch Click auf "Force&Update" zu aktualisieren. Bekommt die Firewall vom Provider über Nacht eine neue IP zugewiesen, wird diese vom DynDNS-Client nicht übernommen.

    Zudem besteht das Problem, dass man in den "Custom"-DynDNS-Einstellungen keinen hostnamen angeben kann. Dadurch bleibt die "hostname"-Spalte auf der DynDNS-Übersichtsseite leer. Ein Export der OpenVPN-Einstellungen unter Auswahl von "DynDNS: …" als Hostnamen ist nun nicht mehr möglich, da ein Fehler "Empty Hostname" auftritt.

    Meine Einstellungen:

    Update-URL: https://dyndns.strato.com/nic/update?hostname="meine.domäne.de"
    Benutzername: "meine.domäne.de"
    Passwort: "mein dyndns-passwort"

    In den Systemlogs sind keine Probleme bezüglich DynDNS ersichtlich.

    Lasst von euch hören! Danke!



  • Was sagt denn das Log wenn deine WAN? IP sich ändert ?



  • Im log stehen u.a. die Zeilen:

    Sep 12 12:30:57 php: /services_dyndns_edit.php: DynDns: updatedns() starting
    Sep 12 12:30:57 php: /services_dyndns_edit.php: DynDns (): %IP X% extracted from local system.
    Sep 12 12:30:57 php: /services_dyndns_edit.php: DynDNS (): running get_failover_interface for wan. found igb0
    Sep 12 12:30:57 php: /services_dyndns_edit.php: DynDNS (): DynDns _update() starting.
    Sep 12 12:30:57 php: /services_dyndns_edit.php: Custom DDNS (): DNS update() starting.
    Sep 12 12:30:57 php: /services_dyndns_edit.php: Sending request to: https://dyndns.strato.com/nic/update?hostname=%meineDomain%&ip=%IP X%
    Sep 12 12:31:09 php: /services_dyndns_edit.php: DynDNS (): DynDns _checkStatus() starting.
    Sep 12 12:31:09 php: /services_dyndns_edit.php: DynDNS (): Current Service: custom
    Sep 12 12:31:09 php: /services_dyndns_edit.php: DynDns (): %IP X% extracted from local system.
    Sep 12 12:31:09 php: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wancustom''0.cache: %IP X%
    Sep 12 12:31:09 php: /services_dyndns_edit.php: phpDynDNS: (Success) IP Address Updated Successfully!


  • Moderator

    Öhm… und die Zeile reicht allein bei Strato eine IP zu ändern? Ich übergebe die Domain und die IP und das wars?
    Das kommt mir persönlich spanisch vor, kein DynDNS Dienstleister den ich kenne macht das ohne Token, User oder sonst irgendwas einfach so nach Angabe der Domain und IP. Damit könnte ich ja ohne Probleme deinen DNS Namen übernehmen, zu mir umschreiben, böse Sachen machen und hinterher wieder zurückdrehen. Gruselig.

    Grüße



  • Strato benutzt laut eigenen Angaben (http://www.strato-faq.de/article/671/So-einfach-richten-Sie-DynDNS-für-Ihre-Domains-ein.html) das "Protokoll DynDNS v2 von dyndns.org".

    Benutzername/Passwort werden laut deren API-Doku über HTTP-Basic Auth übertragen (http://dyn.com/support/developers/api/perform-update/). Habe mir den pfsense-Quellcode nicht angeschaut, gehe aber mal davon aus, dass das auch auf pfsense-Seite so angewendet wird. Ansonsten wäre es nicht möglich gewesen, die IP manuell upzudaten.

    Die Update-URL-HTTP-Get-Parameter (hostname und ip) habe ich selbst hinzugefügt, da für den "Custom" service type in pfsense kein Eingabefeld existiert.
    Habe bereits unterschiedliche Update-URL-Parameter ausprobiert, was alles nur kurzfristig funktionierte und bei veränderter WAN-IP die Domain-IP doch nicht aktualisiert wurde, der hostname in der Dynamic DNS Clients Seite leer war, oder beim nächsten Laden der DynDNS-Clientkonfigurationsseite die GET-Parameter komplett abgeschnitten wurden.
    Momentan nutze ich 2.1.5-RELEASE (amd64). Dort trat das Problem mit den abgeschnittenen GET-Parametern bislang nicht auf.



  • Probiere mal folgende Einstellungen:

    Service type                                  Custom
    Interface to monitor                      WAN
    Interface to send update from      LAN

    Update URL

    https://USERNAME:PASSWORD@dyndns.strato.com/nic/update?hostname=meinpc.wunschname.de&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG

    Die restlichen Felder sind leer.

    Da ich eine feste IP habe kann ich die automatische Änderung nicht testen.



  • Ich hab 'Interface to Monitor' und 'Interface to send update from' beides auf WAN. Meine Update-URL ist

    http://dyndns.strato.com/nic/update?system=dyndns&hostname=meine.strato.dynds&myip=%IP%&wildcard=OFF&backmx=NO&offline=NO

    Wenn Du die pfSense hinter einem Router betreibst, bekommt sie die Adressänderung nicht mit, weil ja die WAN-IP die Gleiche bleibt. Da der Cronjob nur alle 24 Stunden läuft und das ja nicht immer dann passiert, wenn eine neue IP vom Provider kommt, läuft das so nicht. Ich habe das gelöst, indem ich in der config.xml den Cronjob auf einmal stündlich geändert habe. So habe ich mindestens 23 von 24 Stunden  eine aktuelle IP auf der dyn. Adresse.


  • Moderator

    Wenn Du die pfSense hinter einem Router betreibst, bekommt sie die Adressänderung nicht mit, weil ja die WAN-IP die Gleiche bleibt.

    Das stimmt so schon länger nicht mehr, wenn die pfSense auf dem WAN eine private IP bemerkt, macht sie einen externen Lookup um die richtige WAN Adresse zu bestimmen.
    Und dass das funktioniert habe ich an mehreren Installationen bereits bestätigen können.



  • Hi,

    Das stimmt so schon länger nicht mehr, wenn die pfSense auf dem WAN eine private IP bemerkt, macht sie einen externen Lookup um die richtige WAN Adresse zu bestimmen.

    @JeGr
    …ich will ja Deine Kompetenz in keinem Fall anzweifeln.
    Aber wie soll die pfSense das hinter einem NAT machenden Router denn wissen.
    An dem Problem habe ich mir nach der Zwangsumstellung von O² auf andere Hardware die Zähne ausgebissen.
    Der Support hat mir das nach mehreren, erst erfolglosen Telefonaten, dann auch bestätigt, das es eben nicht funktioniert, wenn das nicht auf dem am Internet befindlichen Router gemacht wird.
    Bei den O² Chinaböllern ist aber DynDNS und Co. nicht machbar und als Modem lassen die sich auch nicht mehr betreiben.
    Hat mir dann zu mindest einen Business Vertrag mit fester IP und eine Fritte am DSL-Port zu annähernd den gleichen Konditionen eingebracht.
    Gruß orcape


  • Moderator

    @orcape:

    ich habe doch beschrieben wie es läuft? War das irgendwie unverständlich, dann versuche ichs gerne nochmals. Und ich fühle mit nicht in meiner Kompetenz bezweifelt ;) denn bei mir läuft genau diese Konstellation sehr glatt vor sich hin :)

    Aber wie soll die pfSense das hinter einem NAT machenden Router denn wissen.
    Genau deshalb weiß sie  ja, dass sie was anderes machen muss. :) Das DynDNS Check Skript ist da meines letzten Standes nach recht einfach aufgebaut:

    1. Schaue nach, ob WAN IP eine RFC1918 IP nutzt (private address space)

    2a) Public IP: Prüfe WAN IP nach Änderung (regulär) und vergleiche mit gespeicherter Alt-IP
    2b) Private IP: Mache eine zusätzliche Prüfung bei beliebigem Dienst, der die ÖFFI IP ausgibt (bspw. http://www.whatsmyip.de/) und überprüfe mit gespeicherter Alt-IP

    1. Wenn IP geändert -> aktualisiere DynDNS Service mit ermittelter Public IP

    Du siehtst - das ist überhaupt kein Problem. Und wie gesagt, das macht der pfSense DynDNS Client schon seit 2.x. Gerade dass dieses Verhalten NICHT auch bei RFC2136 macht, war ein Problem, das ich mit dem pfSense Team damals klären musste. Da wurde dann nämlich platt die Private IP in den DNS gepusht statt die Public IP. Deshalb gab es einen Feature Request, dass das auch bei DynDNS via RFC2136 bitte einstellbar sein soll.

    Siehe: Services / Dynamic DNS / RFC2136 / New…
    -> "Use Public IP" ... If interface IP is private, attempt to fetch and use the public IP instead.

    Den Schalter gab es dann nach meinem Bugreport (nicht unbedingt wegen mir, aber ich war einer derjenigen, die das als Feature Request gestellt hatten).

    Grüße
    Jens



  • Service Type: custom
    Username & Password: blank
    Update URL:

    https://paketdomain.de:dyndnspwd@dyndns.strato.com/nic/update?hostname=subdomain.paketdomain.de&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
    

    In meinem dual-WAN setup werden sowohl die public-IP am DSL als auch die public-IP von Kabel-D aktualisiert. Nur kann ich meinen China Kernschrott, den mir KDG als alleiniges Zugangsgerät zumutet, nicht in einen funktionierenden Bridge-Modus schalten. Also lebe ich mit einer doppel-NAT und privater IP am pfSense-APU. Trotzdem wird meine public IPv4 vom Kabel Interface a) korrekt erkannt und b) aktualisiert.

    [Das Problem mit dem nicht funktionierenden Bridge-Modus tritt auf, seit KDG ein Firmware-Update auf das Modem gespielt hat. Erst ging gar nichts mehr bis ich massiv interveniert habe und ein downgrade der Firmware verlangt habe. Seither funktioniert der Anschluss wieder, nur im Bridge-Modus wird der APU keine IP per DHCP zugewiesen. Im Router-Mode schon - jedoch eine private vom Router selbst…]



  • @JeGr
    Danke für die Informationen, man lernt eben nie aus…;)
    @jahonix

    Nur kann ich meinen China Kernschrott, den mir KDG als alleiniges Zugangsgerät zumutet, nicht in einen funktionierenden Bridge-Modus schalten.

    Kabel-D ist aber leider nicht der einzige Provider und es werden ständig mehr.
    Das wird dann auch noch unter "zukunftssicherer, moderner Hardware" verkauft und wenn man nicht mindestens 10 Telefonate führt, wobei man, wenn man Glück hat, mal einen kompetenten Mitarbeiter an der Strippe hat, hilft dann nur noch die Kündigung.
    Erst dann bewegt sich was… ;D
    Gruß orcape


  • Moderator

    @orcape: Immer gerne :)



  • @orcape:

    Danke für die Informationen, man lernt eben nie aus…;)

    Wie wahr…

    Klar komme ich da trotzdem nicht. Wenn ich mir das hier

    https://doc.pfsense.org/index.php/Dynamic_DNS

    durchlese, dann sieht es doch so aus, als ob man sein DynDNS entweder auf dem Register DynDNS oder auf dem Register RFC2136 konfiguriert. Die beiden Absätze im Doc

    When editing a DynDNS client…

    When editing an RFC 2136 client...

    deuten jedenfalls darauf hin. Auch Wikipedia sagt so was.

    das hier: https://doc.pfsense.org/index.php/RFC2136_Dynamic_DNS

    fängt auch mit den Worten an: If the DNS for a domain is directly controlled...

    Kurz und gut, ich habe keinen Plan, wie man eine Strato-Subdomain, die man auf DynDNS eingestellt hat, auf dem Register 'RFC 2136' konfiguriert bzw. wie man das irgendwie vermischt. Wenn wir nicht gerade aneinander vorbeireden ist das ja wohl ganz einfach, nur weiß ich nicht, was ich z.B. bei 'Key' oder 'Server' eintragen soll. Das, was auf der RFC-Seite unten steht, hilft mir nicht.


  • Moderator

    Niemand hat was davon gesagt, dass du die DynDNS Domain von Strato als RFC2136 konfigurieren sollst. Das ist wirklich nur dafür gedacht, DynDNS zu machen, wenn man die Domain selbst betreibt und so direkt mit dem Nameserver zu kommunizieren und nicht via irgendeiner WebUI oder API URL von Strato.

    Was bei dir funktionieren sollte ist das was @jahonix oben schon schrieb. DynDNS Reiter, Typ custom und da die angepasste Strato URL zum updaten rein.

    Grüße



  • Dann hatte ich Deine Posts ja komplett falsch verstanden. Werde die DynDNS-Konfiguration mal wie beschrieben anpassen. Ich berichte dann.

    Gruß
    Exil



  • So, melde jetzt das Ergebnis meiner Tests:

    Es funktioniert. Ich hab den Cronjob via config.xml wieder auf die Originalzeiten 1 1 * * * geändert und die URL wie beschrieben angepasst. Allerdings hat es mir nicht so gefallen, dass dort das Kennwort im Klartext steht. Ich habe also bei Username und Password die entsprechenden Daten eingetragen und aus der URL rausgenommen:

    https://dyndns.strato.com/nic/update?hostname=subdomain.paketdomain.de&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
    

    Als Username muss nicht unbedingt der paketdomainname angegeben werden, es kann auch die Subdomain genommen werden.



  • @Exilschwaelmer:

    Allerdings hat es mir nicht so gefallen, dass dort das Kennwort im Klartext steht. Ich habe also bei Username und Password die entsprechenden Daten eingetragen und aus der URL rausgenommen

    Was auf's gleiche hinauslaufen sollte. Allerdings hat es bei mir so nicht funktioniert sondern nur, wenn ich die Daten in der URL selbst eingetragen habe.
    Da das aber HTTPS ist, stört der Klartext auch nur im Interface beim Betrachten.
    Hauptsache, es läuft.