Nach Update: DynDNS und Regeln durcheinander

JeGr

Da ich etwas in Eile bin, dieses Mal kein englischer Fehlerbericht, ich hoffe Hoba kann es entsprechend weitergeben ;)

Betrifft: Update von Beta2->3 und nun beim 3->4er zu sehen
Vorgehensweise: Da ich kein Freund von Dauerupdates und Patches bin, habe ich bei jedem Wechsel jeweils eine 2. CF Karte für meine net4501 verwendet und auf diese das neue Abbild geladen (jüngst Beta4). Von der alten Version ein Backup der Config und auf der neuen eingespielt. Bei Beta3 wurde fälschlicherweise (oder nur bei mir) nicht neu gebootet nach dem Restore, was Probleme aufrief, ein manueller Neustart half. Bei Beta4 wird wie in der WebGUI auch beschrieben entsprechend neu gebootet. Nach dem NEustart ist auch alle soweit in Ordnung, bis… ja bis auf DynDNS und die NAT Regeln von außen (was zusammenhängt). Hier wird nämlich nach dem Neustart die Dummy Adresse 192.0.2.112 an den DynDNS Account übermittelt statt des aktuellen richtigen. Bei Beta3 war dies durch ein Neustarten des DynDNS zu beheben (speichern in den Einstellungen löste das aus) und nach einem Regel-Reload waren auch alle Mappings von außen wieder greifbar. Nun gestern nacht in Eile ebenfalls wieder ein update gemacht auf Beta4, Restore der Einstellungen, Neustart, kurzer Test ins Internet - geht. Jetzt von der Arbeit: DynDNS geht nicht, Ports reagieren (logischerweise) nicht.

Hier wäre schön:

a) das zu beheben woran es auch liegen möge (first-time-initialize des DynDNS Daemon?)
b) den Schalter für Wildcards bei DynDNS zu richten ;)

Nach dem ersten "draufhauen" auf den DynDNS Daemon, läuft er auch weiter ohne Probleme, aber das erste Mal nach dem Update scheint er leider irgendwie zu spinnen :)

Grüße
Grey ... der momentan auf der Arbeit auf dem Trockenen sitzt, da die Gegenseite nicht reagiert.

hoba

Komisch, mit dieser Dummyadresse hatten wir früher glaube ich mal einen Bug (wenn ich mich da richtig erinnere), aber der sollte eigentlich schon lange lange behoben sein. U.u. greift der aber nur bei PPPoE. Mit unserer statischen IP auf der Arbeit ist der Fehler jedenfalls nicht aufgetreten. Ich gebe das mal an Erik weiter, der die DynDNS-Implementierung in PHP geschrieben hat. Mich würde interessieren, ob sich das Problem nach der 24h Zwangstrennung von selbst löst, oder ob es wirklich den Druck auf den Schalter nochmal benötigt. Vielleicht kannst Du das ja mal heute Nacht prüfen ohne den Schalter vorher betätigt zu haben.

JeGr

Würde ich prinzipiell gern, allerdings hängt an der kleinen Zoé auch ein Portforwarding mit SMTP und anderen Dingen dran. Aber ich kann ggf. eine Zwangstrennung simulieren, indem ich dem Modem den Saft abziehe - das sollte im Prinzip einen ähnlichen Effekt auslösen, da die PPPoE Verbindung in dem Moment abbricht. Die Frage ist eher, erkennt pfSense, dass das IF zum Modem runtergeht… denk

Ich denke ich bin in spätestens einer Stunde wieder dort vor Ort und dann kann ich das mal fieserweise ausprobieren. Wenn sonst noch jemand Fragen dazu hat um das Problem zu eliminieren, immer frei heraus damit!

hoba

Spitzenidee, ich warte auf das Resultat :D

JeGr

Was mich gerade wieder zu der Frage bringt, ob das Interface das überhaupt bemerkt und die PPPoE sauber beendet grübel Bei OpenBSD gabs da früher mal ein Problem, dass der Dienst stehen blieb und nicht das IF-Down bemerkte…

hoba

Das müßte schon funktionieren. Damit hatte ich eigentlich noch nie Probleme und ein paar meiner Kollegen nutzen auch WRAPs mit pfSense an dynamischen PPPoE-Anschlüßen unterschiedlicher Provider.

JeGr

So, gerade angekommen. Modem abgeklemmt -> Interface Status zeigt "No Carrier" (richtig) aber trotzdem Status "up". Nach ein paar Sekunden Modem wieder angeklemmt, blinkt leise vor sich hin -> IF Status zeigt Carrier mit Status "down" (richtig).
Nach einer Minute: Modem neu gesynct, Verbindungsaufbau beendet. Status zeigt:

WAN interface (sis2)
Status up
PPPoE up

(richtig) und eine neue outside IP. Soweit so gut.

May 10 16:29:37 dnsmasq[2279]: using nameserver 217.237.151.161#53
May 10 16:29:37 dnsmasq[2279]: reading /etc/resolv.conf
May 10 16:27:23 php: : FTP proxy disabled for interface opt1 - ignoring.
May 10 16:27:05 php: : Creating rrd graph index
May 10 16:27:05 php: : Creating rrd update script
May 10 16:27:05 php: : Informational: DHClient spawned /etc/rc.newwanip and the new ip is - 84.163.168.153.

Sieht auch gut aus, aber (noch) keine Spur von DynDNS…

Edit: Ok, dauerte etwas länger:

May 10 16:29:49 php: : phpDynDNS: (Success) IP Address Changed Successfully! (84.163.168.153)
May 10 16:29:47 php: : phpDynDNS: updating cache file /cf/conf/dyndns.cache: 84.163.168.153
May 10 16:29:47 php: : DynDns: Current Service: dyndns
May 10 16:29:47 php: : DynDns: DynDns _checkStatus() starting.
May 10 16:29:45 php: : DynDns: DynDns _update() starting. Dynamic
May 10 16:29:45 php: : DynDns: DynDns _update() starting.
May 10 16:29:45 php: : DynDns: cacheIP != wan_ip. Updating.
May 10 16:29:45 php: : DynDns: Cached IP: 84.163.144.130
May 10 16:29:42 php: : DynDns: Current WAN IP: 84.163.168.153
May 10 16:29:42 php: : DynDns: _detectChange() starting.
May 10 16:29:41 php: : DynDns: updatedns() starting
May 10 16:29:40 php: : DynDns: Running updatedns()
May 10 16:29:39 php: : Informational: services_dyndns_configure() is starting.

Das heißt, nach einer Zwangstrennung tut er wie gewollt (oder sollte), nur beim ersten Start nach dem Update verschluckt er sich irgendwie...

hoba

Ich bezweifle, daß es am Update liegt. U.u. wird beim Booten etwas nicht in der richtigen Reihenfolge oder zum falschen Zeitpunkt ausgeführt wo das Interface noch keine öffentliche IP bezogen hat. Danke für die Beobachtungen. Ich geb's an Erik weiter.

JeGr

Aber gern geschehen.

Ich hätte generell einen Verbesserungsvorschlag: Der DynDNS Updater wird momentan nur ab und an aufgerufen und gleicht lokal gecachte mit aktueller IP ab. Aber nicht mit dem Dienst selbst. So hat man die Situation, dass man gern ein Update machen würde, es aber abgelehnt wird, weil der Updater lokal keine Änderung sieht. Aber die gespeicherte IP kann sich durchaus geändert haben (bspw. manuell). Ich würde daher den Aufruf in die IFUP Routine des PPP Daemon einhaken (dann wird garantiert erst nach der Verbindungsherstellung die IP abgeglichen) und im Updater selbst ggf. nicht nach lokal gespeicherter, sondern nach vom Dienst gespeicherter IP abgleichen. So kann man dann auch im Betrieb bspw. Wildcard an oder abschalten oder MX Referrer umsetzen.

Immerhin funktioniert nun die Wildcard-Einstellung - also bitte auch großes Lob ausrichten ;)

JeGr

Da ich gerade wieder darüber gestolpert bin und der Thread hier noch existiert:

Gerade einen kalten Bootvorgang gehabt (pfSense abgestürzt, da ich aber nicht an der Location war, konnte ich nicht nachvollziehen warum). Also Stecker raus, warten, rein und booten. Funktionierte auch alles gut, bis auf die Tatsache dass die VPN Roadwarrior immer noch keine Verbindung hatten. Problem war das altbekannte:

Jan 1 01:01:58 	php: : phpDynDNS: (Success) IP Address Changed Successfully! (192.0.2.112)
Jan 1 01:01:58 	php: : phpDynDNS: updating cache file /cf/conf/dyndns.cache: 84.163.167.39

Reihenfolge ist bottom-up, also kam zuerst das Update der IP (korrekterweise) und danach aber ein AdrChg mit der (falschen dummy) IP Adresse. Passiert wie gesagt nur nach einem (Kalt/Neu)start, bei Wiedereinwahl ist das Problem weg. Aber 24h im ungünstigsten Fall zu warten, bis die Adresse refresht wird, ist nicht ganz so schön.

Grüße
Grey

hoba

Ich habe meine pfSense gerade upgedated auf den letzten Snapshot. Nach dem Reboot kam sie direkt mit der richtigen IP-Adresse im DynDNS-Update (habe pppoe mit dynamischer Adresse). Kann das Problem also nicht nachvollziehen.

JeGr

Letzter Snapshot 09-… 26? 27?

hoba

Ja, das frische leckere und nicht das Gammelfleisch ;)