Nach Periodic reset keine neu IPv6 Adresse



  • 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?



  • 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.



  • 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.



  • 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?



  • @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. ;)



  • 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.



  • 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.



  • 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.



  • 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.  ::)



  • 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.



  • Kann das auch bestätigen.

    Gruß
    pfadmin



  • Ist hier einer schon einen Schritt weiter?

    Gruß
    pfadmin



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



  • 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


  • Moderator

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



  • 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.


  • Moderator

    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>



  • 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:

    1. 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)

    2. 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

    1. 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.

    1. 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 ;) …



  • 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



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



  • Ich bin bei 1&1 und habe einen VDSL 100 Dual-Stack Anschluss. Dieser wird aber von Versatel bereitgestellt.

    Ich habe mich darüber sehr gefreut, da nun der tägliche Reboot des Routers entfällt. Das hatte bei mir einige Nachteile, da der Reboot etwas dauert und Icinga anfängt zu Meckern. Auch sind dann die meisten Logfiles weg, da sie im RAM liegen.

    Gruß, Micha



  • Ich habe mit 2.4 auch Aussetzer, allerdings beim Bezug des Präfixes, nicht der IPv6 am WAN. Anschluß ist Telekom VDSL BNG. Deshalb lasse ich den vorgestellten Workaround auch am LAN Interface prüfen, und nicht am WAN oder pppoe, ob eine IPv6 vorhanden ist.

    Gruß
    pfadmin



  • Heute ist mir aufgefallen, dass mit dem Workaround Snort nicht funktioniert. Es kommt immer ein FATAL ERROR da Snort eine custom Rule nicht findet.

    Im Logfile sieht man das Snort startet, aber durch den erneuten Reload wegen der nicht vorhandenen IPv6 Adresse in diesen Fehler läuft.

    Das könnte man vermutlich abstellen, indem man Snort verzögert starten lässt.

    Ich habe die sleep Zeit auf 60 Sekunden erhöht, danach tritt der Fehler nicht mehr auf.

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


  • Danke für den Hinweis, snort habe ich nicht installiert … die 15sec waren von mir nur nach Bauchgefühl gemessen die Zeit, in der ich recht zuverlässig einen neuen Präfix hatte, wenn alles glatt lief. Also ggf. die Pause bei Bedarf etwas anhheben.

    Gruß, Dirk Platt