Nach Periodic reset keine neu IPv6 Adresse

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)

nonick

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

pfadmin

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

nonick

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

Dirk_Platt

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