Nach Update: DynDNS und Regeln durcheinander

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 ;)