[erledigt] pfSense (als exposed Host) hinter FritzBox - Problem mit DynDNS
-
Hallo Jürgen,
zwei Fragen dazu:
- Wie ist die Fritzbox angebunden? Kabel? DSL? Gerade wenn länger sich die IP nicht ändert gibts manchmal seltsame Phänomene mit DynDNS Adressen.
- Du postest hier die DNS Einstellungen von General und Forwarder, die haben mit dem DynDNS aber erstmal gar nichts zu tun. Wie sind denn die DynDNS Adressen eingetragen und konfiguriert?
Prinzipiell scheint es wohl bei dir ab und an Probleme beim Aufruf von "checkip.dyndns.org" zu geben (so zumindest deine Fehlermeldung oben). Interessant wäre noch deine Konfiguration der DynDNS Dienste.
Grüße
-jens -
Hallo Jens,
zwei Fragen dazu:
- Wie ist die Fritzbox angebunden? Kabel? DSL? Gerade wenn länger sich die IP nicht ändert gibts manchmal seltsame Phänomene mit DynDNS Adressen.
Die FritzBox ist per DSL angebunden. Ich habe in der FritzBox eine tägliche Zwangstrennung (zwischen 03:00 und 04:00) vorgegeben.
Wie sind denn die DynDNS Adressen eingetragen und konfiguriert?
Die Einstellungen habe ich unverändert belassen (d.h. so, wie zu dem Zeitpunkt, als die pfSense direkt hinter einem reinen VDSL-Modem saß und die Einwahl (PPPoE) selbst erledigte).
DynDNS-Einstellung für noip.com:
DynDNS-Einstellung für freeDNS (afraid.org):
Prinzipiell scheint es wohl bei dir ab und an Probleme beim Aufruf von "checkip.dyndns.org" zu geben
Vermutlich hast Du Recht. Ich habe allerdings checkip.dyndns.org wiederholt über das command prompt der pfSense aufgerufen```
$ip = file_get_contents('http://checkip.dyndns.org');
echo $ip;Viele Grüße Jürgen
-
Du kannst evtl noch verbose logging bei den beiden DynDNS Diensten aktivieren und dann im Log mal nachsehen, wenn was nicht funktioniert, was dann der tatsächliche Fehler war. Vielleicht gabs auch beim Dienstleister ein Problem beim Update via API/URL. Prinzipiell ist es bei DynDNS Diensten so, dass die pfSense merkt, wenn ihr WAN Interface eine private IP hat. Dann wird zum Prüfen der IP ein externer Check via checkip… gemacht und so entsprechend geprüft. Das wird per Cron 1x am Tag gemacht und zusätzlich immer dann, wenn ein WAN Interface Event getriggert wird (also im Falle von PPPoE bspw. eine Zwangstrennung). Da diese nicht stattfindet, kann es in diesem Fall dann sein, dass dein DynDNS Check erst nach deiner Zwangstrennung geprüft wird und somit für dich nicht praktisch ist. Wenn ich richtig weiß, ist der Check um 1:01.
(müsste dieser hier sein: 1 1 * * * root /usr/bin/nice -n20 /etc/rc.dyndns.update)
jetzt kannst du einfach manuell nochmal um 4:05 bspw. den Job nochmal ausführen lassen oder deine Zwangstrennung auf bspw. 0:30 legen, dann sollte es auch wieder klappen.
-
Du kannst evtl noch verbose logging bei den beiden DynDNS Diensten aktivieren und dann im Log mal nachsehen, wenn was nicht funktioniert
Danke für den Hinweis; verbose logging habe ich jetzt mal aktiviert.
[…] Dann wird zum Prüfen der IP ein externer Check via checkip… gemacht […] Das wird per Cron 1x am Tag gemacht und zusätzlich immer dann, wenn ein WAN Interface Event getriggert wird […] Wenn ich richtig weiß, ist der Check um 1:01 […] jetzt kannst du einfach manuell nochmal um 4:05 bspw. den Job nochmal ausführen lassen
Den cron job in der pfSense hatte ich bereits unmittelbar nach Festlegung der Zwangstrennung in der Fritzbox auf 04:10 Uhr angepaßt. Daran sollte es also nicht liegen.
Ich werde jetzt ein paar Tage abwarten, was für Erkenntnisse das erweiterte Logging bringt und mich dann wieder hier melden. Zumindest ist es schon einmal gut zu wissen, daß mir kein Fehler bei der Einrichtung unterlaufen ist.
Viele Grüße
Jürgen -
Zumindest ist es schon einmal gut zu wissen, daß mir kein Fehler bei der Einrichtung unterlaufen ist.
So sieht es zumindest für mich aus :)
-
Hallo,
im deinem ersten screenshot hast du die DNS 192.168.178.1 , also deine Fritz.Box angegeben. Bei mir steht da nichts. und fu nktioniert. FB ist als DHCP eingestellt (Voreinstellung der FB). pfsense muss das aber gesagt werden.
-
Also bei den General Settings sollten schon irgendwelche DNS Server stehen, sonst hat das ganze System ja kein sauberes DNS anbieten. Sinnvoll wären da aber mehr als einer, also 2 oder 3 bzw. auch für jedes WAN eines.
-
Update:
Ich habe per Cron ein zweites DynDNS-Update im Abstand von 5 Minuten angelegt (also um 04:10 und um 04:15). Vereinzelt finde ich in den Logs zwar noch die Meldung```
php: rc.dyndns.update: DynDns (alias.no-ip.info): IP address could not be extracted from checkip.dyndns.orgWarum die Fehlermeldung jetzt seltener auftaucht, kann ich nicht sagen und für eine tiefergehende Recherche fehlt mir leider schlicht die notwendige Zeit. Aber so, wie es im Moment ist, kann ich damit leben. Nochmals danke für die Hilfestellung. :-) Jürgen
-
Servus cantor,
auch wenn's für Dich jetzt zufriendenstellend läuft noch eine kurze Info meiner Erkenntnisse zu dem Thema, das mich auch immer wieder mal beschäftigt.
Der Grund, wieso die DynDNS Updates so schlecht laufen ist tatsächlich, dass die pfS den WAN IP Wechsel nicht mehr selbst mitbekommt, weil diese ja nicht mehr an einem eigenen Interface stattfinden, sondern an der Fritze. Dadurch muss sich pfS mit der checkip.dyndns.org (übrigens unabhängig vom verwendeten DynDNS Provider) behelfen.
Das geht leider oft schief, da die URL (zumindest aus Deutschland) oft gar nicht, oder extrem langsam antwortet. Hinzu kommt, dass diese URL nur alle 10 Minuten von der gleichen IP aufgerufen werden darf. (Daher kommen vermutlich Deine "IP address could not be extracted" Meldungen, wenn Du es per Cron im Abstand von 5 Minuten machst)Ich habe dann mal gespielt und mir auf einem meiner WebServer eine eigene Seite gebastelt, die mir die IP zurückgibt und die URL in das dyndns.class.php gehacked.
Das funktionierte deutlich besser, ist aber auch nur eine Krückenlösung. Das Problem ist immer noch, dass das WAN Interface den IP Change nicht mit bekommt. Hatte das auch im englischen Forum geposted https://forum.pfsense.org/index.php?topic=91754.msg507713#msg507713, es gab aber leider keine Resonanz auf das Thema.Mittlerweile verlasse ich mich auf den DynDNS Client der Fritze, der seit Monaten stabil läuft. Deutlich gruseliger sieht es bei den unsäglichen Routern der Kabelprovider aus. Die haben keinen DynDNS Client und dann muss es eben doch mit der externen Auflösung gehen. Einziger Trost dabei ist, dass es keine Zwanstrennung gibt und die IPs teils über Wochen gleich bleiben.
Hoffe zum allgemeinen Verständins beigetragen zu haben.
Falls jemand was Neues / Besseres gefunden hat - immer her damit!Gruß
Harry -
Ahoi Spezi,
eine Variante wäre noch mit Unbound zu debuggen, ob der Request von checkip.dyndns.org lokal abläuft (also gegen Unbound oder DNSMasq) und diesen ggf. einfach umzuschreiben auf einen eigenen Service. Ein eigener Service mit gleicher Ausgabe ist ja nicht schwierig zu bauen. Ausgabe ist ja nur ein Einzeler:
Current IP Address: a.b.c.d
Das kann man sich auch leicht selbst auf den eigenen Webspace werfen so man einen hat. DynDNS selbst nutzt ja 3 verschiedene (checkip.dyndns.org, checkip.dyndns.com, checkip.dyn.com).
Damit hätte man zumindest keine Arbeit im Code zu fixen oder dort etwas zu ändern. Besser wäre natürlich, wenn man ggf. unter Experteneinstellungen selbst den Server ändern könnte. Aber mit DNS Rewrite sollte es auch laufen.Das ändert natürlich am Grundproblem wenig, denn die Box bekommt eben nichts mit, dass sich die IP geändert hat. Aber wie soll sie auch.
Gruß Jens