Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Nach Periodic reset keine neu IPv6 Adresse

    Scheduled Pinned Locked Moved Deutsch
    24 Posts 5 Posters 4.6k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • JeGrJ
      JeGr LAYER 8 Moderator
      last edited by

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

      Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

      If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

      1 Reply Last reply Reply Quote 0
      • P
        pfadmin
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • JeGrJ
          JeGr LAYER 8 Moderator
          last edited by

          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>

          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

          1 Reply Last reply Reply Quote 0
          • D
            Dirk_Platt
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • nonickN
              nonick
              last edited by

              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

              Netgate 6100

              1 Reply Last reply Reply Quote 0
              • D
                Dirk_Platt
                last edited by

                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)

                1 Reply Last reply Reply Quote 0
                • nonickN
                  nonick
                  last edited by

                  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

                  Netgate 6100

                  1 Reply Last reply Reply Quote 0
                  • P
                    pfadmin
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • nonickN
                      nonick
                      last edited by

                      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
                      
                      

                      Netgate 6100

                      1 Reply Last reply Reply Quote 0
                      • D
                        Dirk_Platt
                        last edited by

                        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

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.