Navigation

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

    WAN Failover und IPsec

    Deutsch
    4
    12
    201
    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.
    • F
      FSC830 last edited by

      Hi, zu diesem Thema habe ich Dutzende Posts gefunden, aber alle leicht verschieden und die meisten ohne Lösung.
      Daher versuche ich mein Problem in einem neuen Thread zu beheben.
      Meine Konfiguration, die monatelang lief, sieht wie folgt aus:
      DrayTek Modem als Full Bridge, WAN ist ein VDSL 100 Anschluss. Zugriff von unterwegs über IPsec mit Windows/Android geht problemlos.
      In den letzten Wochen kam es aber sehr häufig zu Ausfällen, teilweise mehrfach täglich. DrayTek/pfSense wurden kurzzeitig durch eine FritzBox 7490 ersetzt, die Ausfälle blieben aber. Mehrfache Versuche seitens des Providers die Ursache zu finden blieben erfolglos.
      Ich habe mich nun entschlossen einen zweiten DSL Anschluss legen zu lassen, der kommt aber erst in den nächsten Tagen.
      Um aber die Ausfallzeit so gering wie möglich zu halten, habe ich den zweiten WAN Anschluß bereits vorbereitet.
      Ich bin mir eigentlich sicher, alles richtig gemacht zu haben, ich habe eine Gateway Group eingerichtet, diese als default Gateway eingetragen, außerdem die Gateway Group als Interface bei DynDNS und IPsec Service eingetragen.
      Wenn nach dem DSL Ausfall das WAN wieder online ist, dann wird durch DynDNS die neue IPv4 Adresse ordnungsgemäß veröffentlicht, aber über IPsec ist keine Verbindung mehr möglich. Erst wenn ich den IPsec Dienst neu starte, dann erreichen die Clients wieder die pfSense.
      Was stimmt hier nicht? Auch wenn ich auf dem IPsec Dienst wieder das WAN Interface anstelle des Gateways eintrage, funktioniert IPsec. Welche Einstellung passt hier nicht? Wie gesagt, z.Zt. ist nur ein WAN Interface aktiv.

      Gruss

      1 Reply Last reply Reply Quote 0
      • S
        sebden last edited by

        Theoretisch müsste deine Konfiguration funktionieren wie geplant.

        Was man nicht unterschätzen sollte, ist die Verzögerung mit der ein ggf. Eingesetztes DynDSN die neue IP erhält und diese auch bei den DNS-Servern der mobilen Geräte sichtbar wird. Dauerte bei meinen Szenarien mindestens 2-3 Minuten. Allerdings lief bei mir der ipsec einfach weiter.

        Teste doch mal die Option, die States killen zu lassen, wenn der Gateway wechseln musste. Vielleicht hilft das weiter?

        1 Reply Last reply Reply Quote 0
        • F
          FSC830 last edited by FSC830

          Hi,
          danke für die Antwort, so habe ich die Theorie auch verstanden ;).
          Die States werden gekillt, ich habe mittlerweile das Syslog enabled und finde da folgendes (nur ein Auszug):

          /rc.newwanip: Dynamic DNS (): running get_failover_interface for WAN_Failover. found pppoe1
          /rc.newwanip: Dynamic DNS: updatedns() starting
          /rc.newwanip: IP Address has changed, killing states on former IP Address xx.xx.xx.xx
          /rc.newwanip: phpDynDNS: updating cache file /conf/dyndns_WAN_Failovercustom''0.cache: yy.yy.yy.yy
          /rc.newwanip: DynDns (): Dynamic Dns: cacheIP != wan_ip. Updating. Cached IP: xx.xx.xx.xx WAN IP: yy.yy.yy.yy

          Also DynDNS geht einwandfrei, aber ich finde auch folgendes:

          Error: pidfile "/var/run/vnstat/vnstat.pid" lock failed (Resource temporarily unavailable), exiting.

          und

          /rc.newwanip: Ignoring IPsec reload since there are no tunnels on interface wan

          Und dieser letzte Eintrag verwundert mich sehr. Entweder wird die Gateway Group nicht genommen? Oder weil gerade kein Tunnel aktiv ist?

          Phase1 sieht so aus:
          442c164d-9760-4ec4-9ede-0a887ae7026a-grafik.png

          Gruss

          P.S. Und auch nach Stunden ist kein IPsec möglich, wie gesagt, erst wenn der Service manuell neu gestartet wird, dann geht es sofort wieder.
          Bin schon am überlegen, ob ich im PHP Skript etwas ändere oder besser ein bash Script in die crontab setze. Aber so ist es unbrauchbar.

          P.P.S. Ich habe jetzt zu Testzwecken auf dem WAN Interface auf einen "Pseudo-Tunnel" eingerichtet, mal schauen, wie es nach dem nächsten Ausfall mit IPsec aussieht.

          pfSense_IPsec.png

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

            @fsc830 Ohne Konfiguration zu zeigen wird hier Hilfe schwer. Das ist sonst reines Glaskugellesen. Bitte mal Failover Gruppe, DynDNS Kram und IPSec P1/P2 zeigen.

            F 1 Reply Last reply Reply Quote 0
            • F
              FSC830 @JeGr last edited by

              @jegr Aber gerne doch. Sollte etwas zuviel geschwärzt sein, dann war es kein böse Absicht, sondern übtriebene Vorsicht. Falls was fehlt, bitte sagen.

              Gruss

              Gatway/GW Group:

              pfSense_GWs.png
              pfSense_GWG.png

              DynDNS, auf der zweiten Seite weiter unten ist nur noch die Update URL, aber ich denke, die wird nicht benötigt, denn das funktioniert.

              pfSense_DDNS.png
              pfSense_DDNS_01.png

              IPsec P1:

              pfSense_IPsec.png
              pfSense_IPsec_01.png

              IPsec P2:

              pfSense_IPsec_02.png
              pfSense_IPsec_03.png

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

                @fsc830 OK und WANH46 gibts noch nicht?

                1 Reply Last reply Reply Quote 0
                • F
                  FSC830 last edited by

                  Nein, der Anschluss soll frühestens nächste Woche geschaltet werden. 😞

                  Gruss

                  1 Reply Last reply Reply Quote 0
                  • F
                    FSC830 last edited by FSC830

                    Na sowas, es gibt Neuigkeiten.
                    Heute Nacht hatte ich laut Syslog zwei Ausfälle 😕 .
                    Aber: IPsec geht noch.
                    Leider hatte ich natürlich zwei Dinge geändert 👎 :

                    1. Den "Pseudo"-Tunnel eingerichtet, wie gestern schon beschrieben
                    2. waren 3 IPsec Clients aktiv, 2 x Android und 1 x Win10

                    Die Androiden zeigten mir heute morgen unverdrossen einen "Verbunden" Status, ließen sich trennen und auch wieder verbinden!
                    Der Win Client war nicht mehr verbunden, ließ sich aber problemlos wieder verbinden.

                    Da ich eher davon ausgehe, das der Pseudo" Tunnel hier ausschlaggebend war, habe ich alle IPsec Verbindungen getrennt und warte auf den nächsten Ausfall, der wird mit Sicherheit kommen 😠 .
                    Spätestens dann sehen wir weiter...

                    Gruss

                    P.S. Und zack, der nächste Ausfall 👿 !
                    Interessanterweise werden mir im Dashboard aber die 3 Mobile Clients immer noch angezeigt (auch vorhin, ist mir eben erst aufgefallen), wenn auch als "offline". Sonst stand dort immer eine "0".
                    Und IPsec geht immer noch, scheint also tatsächlich an dem "Pseudo"-Tunnel zu liegen. 🤔

                    1 Reply Last reply Reply Quote 0
                    • F
                      FSC830 last edited by

                      Noch mal ein Update.
                      Ich habe auf beiden WAN Schnittstellen einen "Pseudo" Tunnel angelegt, den aber auf disabled gesetzt.
                      Heute gab es den nächsten Ausfall und natürlich war hinterher wieder keine VPN Verbindung möglich.
                      Ich habe darauf hin einen der Pseudo-Tunnel aktivert, und zwar absichtlich den, der überhaupt noch keine I-Net Verbindung hat, also das WANH46.
                      Danach war aber wieder eine VPN Verbindung möglich...?

                      Ich verstehe z.Zt. nicht, was die pfSense da macht 🤔 .

                      Aktuell sieht es so aus:

                      IPsec_10.png

                      Gruss

                      1 Reply Last reply Reply Quote 0
                      • N
                        NOCling last edited by

                        Da hast du durch die Änderung den Dienst neu gestartet, daher läuft das wieder.

                        Werfe doch mal die aktuell eh noch nicht funktionale WAN Verbindung ganz weg.

                        Bei mir, habe nur eine, ist VPN immer möglich, wenn das Cabel Modem wieder hochgefahren ist und WAN eine IP bekommen hat.

                        Kann mir vorstellen, das du wegen dem nicht funktionalen WAN 2 in ein Loch fällst, weil dieser Sonderfall nicht abgefangen wurde.
                        Das ist aber ein fall für die Entwickler, wenn das mit 2.5 nicht behoben ist, wird.

                        1 Reply Last reply Reply Quote 0
                        • F
                          FSC830 last edited by

                          Hi,
                          ohne Gateway Gruppe und mit nur einem WAN hat es vorher auch problemlos funktioniert.
                          Diese Woche wird endlich der zweite Anschluss gschaltet, leider erst am Freitag. Dann werde ich das auch ohne die Pseudo Tunnels testen.

                          Gruss

                          1 Reply Last reply Reply Quote 0
                          • F
                            FSC830 last edited by

                            Update: nachdem nun beide WAN Links aktiv sind habe ich ein wenig getestet:
                            Egal welcher Link ausfällt, nach kurzer Zeit (ca. 1-2min) ist eine VPN Verbindung über den verbleibenden Link wieder möglich, aber nur, wenn die pseudo-tunnels aktiv sind.
                            Ohne diese Tunnels wird IPsec wohl nicht vollständig neu gestartet.

                            Meiner Meinung nach ist das ein Bug in der pfSense Software. Und nach allem, was ich dazu gefunden habe, sogar ein sehr alter!?
                            Da bin ich gespannt, ob v2.5 eine Besserung bringt.

                            Gruss

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post

                            Products

                            • Platform Overview
                            • TNSR
                            • pfSense
                            • Appliances

                            Services

                            • Training
                            • Professional Services

                            Support

                            • Subscription Plans
                            • Contact Support
                            • Product Lifecycle
                            • Documentation

                            News

                            • Media Coverage
                            • Press
                            • Events

                            Resources

                            • Blog
                            • FAQ
                            • Find a Partner
                            • Resource Library
                            • Security Information

                            Company

                            • About Us
                            • Careers
                            • Partners
                            • Contact Us
                            • Legal
                            Our Mission

                            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                            Subscribe to our Newsletter

                            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                            © 2021 Rubicon Communications, LLC | Privacy Policy