DynDNS Client Einstellungen für STRATO
-
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 -
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:- 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- 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…;)
@jahonixNur 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 -
@orcape: Immer gerne :)
-
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.
-
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.
-
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. -
Guten Tag,
ich greife diesen 4 Jahre alten Post auf, da ich das gleiche Anliegen habe. Ich möchte in pfSense mein Strato-Paket nutzen.
Ich habe unter Strato den DynDNS-Dienst eingerichtet.Nach Eintragung der Update-URL https://paketdomain.de:dyndnspwd@dyndns.strato.com/nic/update?hostname=subdomain.paketdomain.de&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG
wie im Beitrag von jahonix oben beschrieben, erhalte ich die Fehlermeldung
Jan 2 13:49:14 php-fpm 338 /services_dyndns_edit.php: Dynamic DNS () There was an error trying to determine the public IP for interface - wan (igb0 ).Wenn ich diese Update URL aus dem Browser aufrufe, erhalte ich "good IP".
Was muss ich einstellen, damit die Fehlermeldung verschwindet und folglich pfSense die IP im DynDNS-Dienst aktualisiert? Danke!
-
This post is deleted! -
Bei mir funktioniert das problemlos so:
Service Type: Custom Interface to monitor: WAN (pFsense befindet sich hinter einem anderen Router) Interface to send update from: WAN Verbose Loggin: - HTTP API DNS Options: - HTTP API SSL Options: - Username: - Password: - Update URL: https://Domain:Password@dyndns.strato.com/nic/update?hostname=Domain&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG z.B. https://test.de:pa55wOrt@dyndns.strato.com/nic/update?hostname=test.de&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG Result Match: - TTL: -
Greetz
Ovrld -
Moin, ich wollte hier mal meine Erfahrungen teilen - eventuell hilft es jemandem:
- Für Strato funktioniert wie bereits erwähnt die "Custom"-URL (https://dyndns.strato.com/nic/update?hostname=Domain&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG)
- Benutzername und Passwort muss man der URL nicht voranstellen. Das pfSense-Skript übernimmt diese aus den Einstellungen. Es funktioniert auch andersherum, nur findet man dann das Paswort im Klartext in den Konfigurationsdateien.
- Das "Custom"-Skript wertet nicht die Antworten von Strato aus. Im Log und auch in der Benutzeroberfläche werden keine Fehler angezeigt, wenn das Update nicht funktioniert hat. Das konnte der alte ddclient besser.
- Ich habe 5 Sub-Domains bei Strato. Ich hatte leider das Problem, dass die IP nur bei der ersten Domain un den letzten beiden geändert wurde. Die anderen Updates mussten manuell angestossen werden.
- Meine Annahme, dass dies damit zu tun hat, dass die Antwort von Strato nicht ausgewertet wird, scheint sich bestätigt zu haben:
- Ich habe als Hack mal einen "sleep(10)" in das Skript eingebaut. Damit scheint es jetzt zu funktionieren: Alle Domains werden korrekt angepasst.
- Meine Änderung ist aber wirklich nur ein Hack, ich habe mehr oder weniger geraten, wo man das Skript bremsen muss. Das sollte sich mal jemand ansehen, der sich damit auskennt... (/etc/inc/dyndns.class)
VG
A R -
@baltic said in DynDNS Client Einstellungen für STRATO:
Moin, ich wollte hier mal meine Erfahrungen teilen - eventuell hilft es jemandem:
- Das "Custom"-Skript wertet nicht die Antworten von Strato aus. Im Log und auch in der Benutzeroberfläche werden keine Fehler angezeigt, wenn das Update nicht funktioniert hat. Das konnte der alte ddclient besser.
Das stimmt so nicht ganz. Das kann der Custom Eintrag durchaus. Dafür ist der Eintrag beim Result match zuständig:
Wenn der natürlich leer ist, gibt es logischerweise auch keinen Check ob das geklappt hat oder nicht. WAS da genau rein muss, liegt an der Ausgabe von Strato.
- Ich habe 5 Sub-Domains bei Strato. Ich hatte leider das Problem, dass die IP nur bei der ersten Domain un den letzten beiden geändert wurde. Die anderen Updates mussten manuell angestossen werden.
Was wahrscheinlich an einem Error lag, der durch fehlendes Result Matching nicht erkannt wurde? Ist lediglich eine Vermutung, müsste man ggf. sonst aus den Logs kratzen was das Feedback war.
- Ich habe als Hack mal einen "sleep(10)" in das Skript eingebaut. Damit scheint es jetzt zu funktionieren: Alle Domains werden korrekt angepasst.
- Meine Änderung ist aber wirklich nur ein Hack, ich habe mehr oder weniger geraten, wo man das Skript bremsen muss. Das sollte sich mal jemand ansehen, der sich damit auskennt... (/etc/inc/dyndns.class)
Oooder man liest sich da ggf. mal einfach genau durch, was Strato bei einem Update via URL die du gepostet hast als "Feedback" im Browser zurückgibt. Einfach mal im Browser ausführen und schauen was zurück kommt. Normalerweise geben Dienste was aus in der Art
success 192.0.2.1
oder
good 203.0.113.2
oder
IP has not changed 198.51.100.4
aus als Feedback. Das kann man wie in meinem Beispiel entsprechend einfangen und mehrere Ausgaben berücksichtigen. Dann wird das auch sauber ausgewertet und angezeigt und kann in der UI dargestellt werden und ggf. nochmals später ausgeführt werden wenn ein Change nicht geklappt hat.
Cheers
\jens -
@jegr Vielen Dank!
Du hast natürlich in allen Punkten recht! Und ich hätte mir natürlich auch mal die Hinweise im UI durchlesen können...
Folgendes funktioniert jetzt bei mir reproduzierbar:
- Custom auswählen
- Username (==Domain)/Password in den dafür vorgesehenen Feldern.
- Die STRATO-URL (https://dyndns.strato.com/nic/update?hostname=Domain&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG)
- als Result Match "good %IP% | nochg %IP%"
Damit ist dann auch der Hack im Skript unnötig.
Hinweis: Wenn man zuviel herumspielt antwortet Strato mit "abuse %IP%".
VG
AR -
@baltic said in DynDNS Client Einstellungen für STRATO:
Hinweis: Wenn man zuviel herumspielt antwortet Strato mit "abuse %IP%".
Aye, das sind dann zu viele Updateversuche pro Zeit gegen deren API. Da sind sie etwas arg empfindlich. :)
-
@baltic funktioniert das "result matching" bei Dir aktuell noch?
Habe heute auch dyndns eingerichtet exakt wie von Dir beschrieben, aber das log zeigt nach update trotzdem/rc.newwanip: phpDynDNS (): (Error) Result did not match. [good XXX.XXX.XXX.XXX ]
an.
Das dns update selbst bei strato funktioniert.
Wenn ich entweder good %IP oder nochg %IP% eintrage, checkt es die pfsense und liefert ein success im log.Das "oder" scheint also nicht zu funktionieren.
Mir ist aufgefallen, dass im result nach der IP noch ein leerzeichen kommt (auch im log oben zu sehen), bin aber nicht sicher, ob das was zur sache tut? (habe bisher nicht viel dokumentation zum "Result Match" teil gefunden...
Hat jemand eine Idee?
[edit]
achso, es läuft 2.4.5-RELEASE-p1 -
Hallo zusammen,
ich würde den Beitrag nochmal ausgraben. Ich habe meine pfSense (2.5.2) die als VM auf Proxmox läuft gerade "umgezogen" und meine damit an einen neuen Internatsanschluss. Dort habe ich nun eine Unitymedia-ConnectBox, die Rechnung kommt von Vodafone aber technisch sieht mir das immer noch nach dem gleichen Netz aus, im Bridge-Mode und die pfSense hat auf der WAN-IP (DHCPv4).
Das funktioniert auch. Nun habe ich bei Strato eine Subdomain "gw.meindedomain.de" eingerichtet und DDNS aktiviert und schlussendlich ein Passwort dafür gesetzt.
In der pfSense habe ich es wie folgt eingetragen:
Dienst Typ: Benutzerdefiniert Schnittstelle zum Monitor: WAN Schnittstelle, von der aus: WAN Verify SSL/TLS Certificate Trust: [X] Benutzername: gw.meinedomain.de Kennwort: Das was ich in der Domainverwaltung -> Subdomain -> DDNS -> Passwort gesetzt habe Update URL: https://dyndns.strato.com/nic/update?hostname=Domain&myip=%IP%&wildcard=NOCHG&mx=NOCHG&backmx=NOCHG Ergebnis passt: good %IP% | nochg %IP%
Aber der Status bleibt auf dem roten X. In welchem Log finde ich die hilfreichen Hinweise?
Beste Grüße
pixel24 -
@pixel24 said in DynDNS Client Einstellungen für STRATO:
Verify SSL/TLS Certificate Trust: [X]
Das habe ich wieder raus genommen da die Domain nur ein selbst-signiertes hat.