Nach Periodic reset keine neu IPv6 Adresse

nonick

Hallo zusammen,

ich habe IPv6 nach folgender Anleitung https://moerbst.wordpress.com/2016/07/31/ipv6mit-pfsense-an-dsl-der-telekom/ eingerichtet und es funktioniert dann erstmal reibungslos. Leider geht das nur bis zum Periodic reset. Danach bekommt das WAN Interface keine IPv6 Adresse mehr. Es langt dann ein nochmaliges Speicher des WAN Interface und es funktioniert wieder, aber eben nur bis zum nächsten Periodic reset.

Gibt es eine Lösung für das Problem?

mrpink

Welche pfSense Version hast du denn im Einsatz?

Ich habe dieses Verhalten seitdem ich letzte Woche von Version 2.3.3 auf 2.3.4 aktualisiert habe und an meiner Konfiguration hat sich zwischen 2.3.3 und 2.3.4 auch nichts geändert. Vorher lief ipv6 ohne Probleme.

Manueller Disconnect und Connect funktioniert, soll heißen ipv6 Adressen werden vergeben. Nur eben nicht für den Periodic reset.

Will heute evtl. noch mal frisch 2.3.4 installieren und das Backup einspielen um zu testen ob es dadurch behoben ist.

Edit:
Ich habe einen 1&1 VDSL 50 Anschluss wo es leider noch eine tägliche Zwangstrennung gibt.

nonick

Hallo mrpink,

danke für deine Atwort.

Ich habe PFSense mit der Version 2.3.4 neu installiert und konfiguriert. Ich hatte zuvor OpnSense am laufen, damit war ich nicht mehr zufrieden. Mit PFSense funktioniert alles reibungsloser. Außer das mit dem Periodic reset. Ich denke nicht, dass bei dir eine Neuinstallation helfen wird. Es wird dann mit der Version zusammenhängen. Mir würde ja schon der Befehl für das Speichern des WAN Interface reichen. Damit könnte man einen Cronjob statt dem Periodic reset erstellen.

mrpink

Du könntest auch einen reboot von pfSense per Cron machen. Da bekommt er auch immer eine ipv6 habe ich festgestellt.

Werde die Tage noch einiges Testen, damit ich das wirklich auch die neue Version schieben kann.

Hat evtl. noch jemand festgestellt, dass seit der Version 2.3.4 keine ipv6 Adressen nach einem Periodic reset vergeben werden?

nonick

@mrpink:

Du könntest auch einen reboot von pfSense per Cron machen. Da bekommt er auch immer eine ipv6 habe ich festgestellt.

Daran habe ich auch schon gedacht. Da sind dann nur die Logfiles weg, da sie bei mir im RAM liegen. ;)

nonick

Hat keiner eine Idee wie man das WAN Interface per Cronjob reloadet?

Das wäre für mich der bessere Workaround solange der Fehler in der Version 2.3.4 besteht. Den Router alle 24 Std. neu zu starten funktioniert zwar, aber es ist schon eher eine Holzhammermethode.

mrpink

Das ist der Befehl der einen Reload auf dem WAN Interface ausführt:

/usr/local/sbin/pfSctl -c 'interface reload wan'

Ist aber nichts anderes wie auch in der Datei /var/etc/pppoe_restart_pppoe0 enthalten und wird somit wenig bringen.

nonick

Hallo mrpink, du hast Recht, das Problem bleibt weiterhin auch bei einem Reload des Interface.

Was ich beobachtet habe, es scheint der Dienst radvd manchmal nicht mehr zu laufen nach dem Periodic reset. Wenn ein Periodic reset erfolglos war und keine IPv6 Adresse zugeteilt wurde, funktioniert es nach einem wiederholten Periodic reset. Das passiert dann immer abwechselnd.

mrpink

Bei mir läuft der Router Advertisement Daemon (radvd) ohne Probleme durch, habe jetzt bestimmt 6 mal einen Periodic reset ausgeführt.

Aber du hast Recht, dass bei jedem zweiten Reset ipv6 Adressen bezogen werden. Sehr seltsam das ganze. ::)

mrpink

Bin gestern endlich mal zum testen gekommen und hier die neueste Erkenntnis:

Habe eine neue Installation mit pfSense 2.3.3 gemacht und das Backup zurückgespielt. Mehrere Periodic reset (/var/etc/pppoe_restart_pppoe0) ausgeführt und ich bekomme immer eine ipv6 Adresse. Läuft also ohne Probleme wie vorher auch.
Dann im Anschluss ein Upgrade auf pfSense 2.3.4 und das Problem tritt wieder auf. Nach jedem zweiten Periodic reset wird keine ipv6 Adresse bezogen bzw. zugewiesen.
Habe dann auch mal eine Installation mit pfSense 2.4-Beta ausgeführt und das Backup zurückgespielt und es funktioniert wieder alles, soll heißen ich bekomme nach jedem reset eine ipv6 Adresse.

Fazit: Es scheint wirklich ein Problem mit der Version 2.3.4 zu sein.

pfadmin

Kann das auch bestätigen.

Gruß
pfadmin

pfadmin

Ist hier einer schon einen Schritt weiter?

Gruß
pfadmin

mrpink

Ich nutze im Moment pfSense 2.4 und damit habe ich keine Probleme.

pfadmin

Ich habe nun auch aktualisert auf 2.4.0.b.20170612.1823
Dabei sind die Interface etwas durcheinandergekommen (re0/vlan7/pppoe), nachdem das gelöst war, ging IPv6 mehrere Tage, wobei ich auch keinen periodic reset mehr eingestellt habe und die DTAG keinen auslöste. Nach einem Stromausfall allerdings das gleiche Bild wie mit 2.3.4., es gibt keinen /56 Präfix der verteilt werden könnte. Ich werde die box komplett werksreseten und das Configbackup einspielen, was hoffentlich so geht. Vielleicht ist da noch der Wurm drin.

Die aktuellste Version sowie ein Reboot ist erst am Wochenende möglich, bevor das jemand rät ::)

Wie kann man eigentlich auf der Konsole den Inhalt z.B. von "LAN1 Net" ausgeben? Hier müßte ja das IPv4 Netz drinstehen sowie auch das IPv6 Präfix mit der Subnet-ID

grüße
pfadmin

JeGr

Was meinst du mit LAN1 Net? Dein Alias aus der PF Konfiguration vom Filter?

pfadmin

Bei den Rules kann man doch SCR und DST wählen, unter anderem "Interface net" , bei mir beispielsweise "LAN1 net" oder auch "Single Host or Alias". Dahinter verbirgt sich dann doch die jeweils vergebene IP bzw. das Netz - oder? Idee war, auf der Konsole den Inhalt bestimmter Variablen zu prüfen, ob der auch meinen Erwartungen entspricht. Beispielsweise ob die richtige IP drin steht.

JeGr

Nein das kannst du nicht direkt abfragen, du kannst auf der Konsole nur sehen, welches Netz gerade da gebunden ist. Im Konsolenmenü wird es ja angezeigt, was auf LAN1 bspw. gerade für eine IP und Maske anliegt. IN den Regeln selbst ist nur das Interface als Alias drin, das Netz wird vorher ausgelesen und direkt reingeschrieben

(Beispiel: pass in quick on $LAN1 inet proto icmp from 192.168.1.0/24 to any tracker <id>keep state label "USER_RULE: <description>")

Du könntest mit einem grep auf /tmp/rules.debug nur das Interface Alias sehen

bspw.: LAN1 = "{ igb0 }"

Grüße</description></id>

Dirk_Platt

Hallo zusammen,

Das vom TE geschilderte Verhalten kann ich (leider) auch beobachten. Nach der Ausführung des /var/etc/pppoe_restart_pppoe0 steht nicht immer ein IPv6-Präfix zur Verteilung zur Verfügung. Allerdings passiert das bei mir völlig unvorhersehbar (nicht jedes 2. mal) und recht selten. Oft reicht der nochmalige Aufruf von /var/etc/pppoe_restart_pppoe oder direkt /usr/local/sbin/pfSctl -c 'interface reload wan' aus, um die Verbindung "zu reparieren", aber eben nicht immer.

Ich habe mir dazu folgenden (zugegebenermaßen ziemlich kruden) Workaround implementiert:

die /var/etc/pppoe_restart_pppoe habe ich kopiert in eine /etc/pppoe_customrestart.pppoe0 und dann den periodic reset am WAN-Interface abgeschaltet. Dadurch verschwindet der cron-Eintrag und die Datei selbst (deshalb vorher die Kopie)
die pppoe_customrestart_pppoe0 habe ich wie folgt angepasst:

#!/bin/sh
/usr/local/sbin/pfSctl -c 'interface reload wan'
/usr/bin/logger -t pppoe0 "PPPoE periodic reset executed on wan"
sleep 15
/etc/rc.check_lanipv6

Es wird also nach dem absetzen des "interface reload wlan" erstmal 15 sekunden gewartet und dann ein "check-script" (/etc/rc.check_lanipv6) aufgerufen

dieses /etc/rc.check_lanipv6 Skript sieht (bei mir!) so aus:

#!/bin/sh
#
# rc.check_lanipv6
#
# performs an: ifconfig em1 | grep 'inet6 2a02:2028:'
# and reloads interface wlan if no valid IPv6 Adress is currently bound on em1

/usr/bin/logger -t pppoe0 "Probing for valid IPv6 Adress on LAN interface (em1)"
while ! ifconfig em1 | grep 'inet6 2a02:2028:' >/dev/null
do
        /usr/bin/logger -t pppoe0 "No valid IPv6 Adress found ... trying to reload WAN interface to fix that"
        /usr/local/sbin/pfSctl -c 'interface reload wan' >/dev/null
        sleep 15
        /usr/bin/logger -t pppoe0 "Probing (again) for valid IPv6 Adress on LAN interface (em1)"
done

/usr/bin/logger -t pppoe0 "Valid IPv6 Adress found ..."
exit 0

Hier prüfe ich anhand der Ausgabe eines ifconfig auf meinem LAN Interface (em1) ob es eine Zeile mit 'inet6 2a02:2028:' darin gibt - 2a02:2028: ist der Präfix mit dem die IPv6-Adressen meines Providers beginnen. Findet das Skript die Zeile ist alles ok, Wenn nicht, wird ein erneuter Interface reload auf der WAN Schnittstelle angestoßen, 15 Sek gewartet und erneut geprüft. Das ganze wiederhole ich, bis ich eine entsprechende Verbindung auf der LAN-Seite feststelle.

Schließlich habe ich noch die neue /etc/pppoe_custom_restart per cron anstelle des Originals 1 mal pro Nacht zum gewünschten Zeitpunkt eingeplant.

Mir ist klar, das das ganze ein ziemlich "wilder" Workaround ist (allein durch die harte Abhängigkeit zu meiner Konfiguration und meinem ISP). Meine Hoffnung ist aber auch, dass ich das ganze nur vorübergehend bis pfSense 2.4 brauche.

Gruß, Dirk Platt

P.S.: Wenn das alles totaler Mist ist, nur zu - zerreißt mich in der Luft ;) …

nonick

Hallo Dirk,

vielen Dank für deinen Workaround! Ich habe das heute früh gleich mal getestet und es funktioniert perfekt! Ich habe nur deinen Check ifconfig em1 | grep 'inet6… gleich auf ifconfig pppoe0 | grep 'inet6... abgeändert und den Rest entsprechend angepasst. Man sollte nur daran denken, die Datei /etc/rc.check_lanipv6 mit chmod 755 /etc/rc.check_lanipv6 ausführbar zu machen.

Solange es selbst die Entwickler von PFSense nicht hinbekommen, ist dein Workaround der "Heilige Gral"! :D

Dirk_Platt

Hallo nonick

freut mich, dass es bei Dir auch funktioniert. Ich würde aber nicht so weit gehen zu behaupten, dass die Entwickler das nicht hinbekommen. Ich weiss zeimlich gut, dass es für einen Entwickler oft die Hauptschwierigkeit ist, ein Problem erst einmal nachstellen zu können. Die Lösung selbst ist dann oft eher einfach.

Da das eine Weile dauern kann, auch weil (je nach Anzahl der Betroffenen) die Prioritäten manchmal eben anders liegen und man sich nicht zerreissen kann, denke ich immer: Ein schlechter dreckiger Workaround ist besser als gar nichts.

Mit dem "heiligen Gral" tust du der Sache aber sicher zuviel der Ehre an ;)

Gruß, Dirk Platt

P.S: Bei welchem Provider bist Du eigentlich? Ich bin bei Wilhelm.tel (FTTH, Dual-Stack)