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

    IPSEC findet die neue IP des DDNS nicht

    Scheduled Pinned Locked Moved Deutsch
    13 Posts 4 Posters 2.5k 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

      Ahoi

      1. Frage: Wie ist der Tunnel konfiguriert bzw. ist der DNS Name beim Tunnel-Setup auch der identifier, damit auch der entsprechende Helper gestartet wird?
      2. Frage: Läuft auf den Sensen ein Prozess "dnswatch"?
      3. Frage: Was sagt das IPSec Log (raccoon)?

      Und zum Tunnel selbst: Gibt es einen Grund, bei 2 Sensen an den Enden, dass es IPSEC sein "muss"? Wäre OpenVPN eine Alternative?

      Grüße

      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
      • R
        rj45
        last edited by

        Hallo,

        zu 1. Der identifer ist ein "Distinguished name", was in der Vergangenheit auch immer gut funktionierte.
        zu 2. Einen  Prozess "dnswatch" habe ich nicht in der Prozessliste gesehen.
        zu 3. racoon: INFO: IPsec-SA request for x.x.x.x queued due to no phase1 found.
        Wobei x.x.x.x die alte DDNS-Adresse ist.

        Die Konfiguration ist über die Jahre gewachsen und hat bisher gut funktioniert, vor allem in Verbindung mit anderer Hardware (DrayTek, AVM etc).

        Grüße

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

          Könntest du zum Fehler ein wenig mehr Zeilen posten? Das Queueing ist nur das Resultat, aber nicht das Problem. Da muss vorher schon dann was stehen. Klar die alte IP ist in dem Zusammenhang doof, aber vorher müsste ein Reconnect / Reload getriggert werden.

          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
          • R
            rj45
            last edited by

            Das Log gibt leider nicht viel her.

            Alles logisch und nachvollziehbar:
            Die Verbindung besteht normal.
            Die Verbindung wird getrennt (wegen Zwangstrennung).
            Verbindung kann nicht wieder hergestellt werden, da alle Versuche auf der kalten IP fehlschlagen müssen.

            May 6 00:32:42 racoon: INFO: begin Aggressive mode.
            May 6 00:33:13 racoon: [XXX.XXX.XXX.XXX] ERROR: phase2 negotiation failed due to time up waiting for phase1 [Remote Side not responding]. ESP XXX.XXX.XXX.XXX[0]->YYY.YYY.YYY.YYY[0]
            May 6 00:33:32 racoon: ERROR: phase1 negotiation failed due to time up. 1e216a8f4a7cbd93:0000000000000000
            May 6 00:33:32 racoon: INFO: IPsec-SA request for XXX.XXX.XXX.XXX queued due to no phase1 found.
            May 6 00:33:32 racoon: [Self]: INFO: initiate new phase 1 negotiation: YYY.YYY.YYY.YYY[500]<=>XXX.XXX.XXX.XXX[500]

            Um es vielleicht noch einmal hervorzuheben, die Probleme finden auf dem Anschluss mit der statischen IP statt.

            Dann ein manueller Neustart des racoon Service und alles läuft wieder super, da dann die DDNS-Adresse korrekt aufgelöst wird.

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              Ein ähnliches Problem hatte ich sporadisch auf einem beidseitig dynamischen IPsec Tunnel. Mit openVPN ist der Aufbau nach IP-Wechsel wesentlich schneller und stabiler.

              1 Reply Last reply Reply Quote 0
              • E
                eSpezi
                last edited by

                Servus,

                hatte das Problem auch, dass pfS trotz einem IP-Wechsel noch die alte IP gecached hatte und diese an den DynDNS weitergegeben hat. Somit hat der Host an der Gegenstelle falsch aufgelöst.
                Mit dieser Lösung hatte ich dann Erfolg: https://forum.pfsense.org/index.php?topic=58034.0

                Viel Glück!
                Harry

                1 Reply Last reply Reply Quote 0
                • ?
                  Guest
                  last edited by

                  " Alles läuft super bis auf der dynamischen Anbindung eine neue IP zugewiesen wird. Wenige Augenblicke später ist der DDNS-Wert entsprechend aktualisiert. Wenn ich auf der statischen Seite ein DNS Lookup auf den DDNS mache, wird der aktuelle Wert korrekt angezeigt."

                  Der DynDNS IST aktuell, aber die pfSense auf der anderen Seite des Tunnels fragt ihn nicht ab, sondern versucht weiter die alte IP. Mittlerweile habe ich das selbe Verhalten auch bei openVPN beobachtet…

                  1 Reply Last reply Reply Quote 0
                  • ?
                    Guest
                    last edited by

                    …und hier erklärt bekommen:

                    https://forum.pfsense.org/index.php?topic=76735.msg421427#msg421427

                    Es ist die Cache-Lebensdauer (TTL), die der DynDNS Anbieter vorgibt.

                    Anbieter gewechselt nachdem DynDNS.com nicht mehr kostenlos ist?  ;)

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

                      Ah hat Chris etwas Licht ins Dunkel bringen können. Sehr gut :)

                      Wenn du die Möglichkeit hast, deine DNS Zonen selbst zu verwalten, ist DynDNS nach RFC2136 sehr angenehm zu handeln, ansonsten gibt es ja inzwischen auch noch einige neue DynDNS Anbieter. Auch wenn deren Modalitäten teils etwas … frech sind.

                      Grüße

                      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
                      • ?
                        Guest
                        last edited by

                        …unter Zeitdruck halt schnell einen Serviceanbieter ausgesucht, da DynDNS.com kostenpflichtig wurde und bei SPDNS.de gelandet.

                        Da ist scheinbar einen TTL von 5 min angesetzt, der "Support" dort reagierte in den letzten Tagen nicht auf meine Anfrage, ob das korrekt ist. Wenn die Zwangstrennung der Verbindung nachts ist, ist das ja eigentlich auch kein großes Problem, aber manchmal will die Telekom das am hellichten Tag durchziehen und dann nerven die verschwundenen Tunnel doch arg...

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

                          @chemlud: Kannst du nicht die Zwangstrennung über die pfSense machen lassen (also DSL direkt dort auflegen)? Also pfS die DSL Verbindung aufbauen lassen und als Trennung 5h morgens auswählen? ;)

                          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
                          • ?
                            Guest
                            last edited by

                            uuups, gerade erst gesehen! Ja, tatsächlich, da ist ja eine Option für eine frei definierte Unterbrechung der Verbindung auf der pfSense GUI Seite für das WAN Interface, wenn man PPPoE wählt. Hab ich jetzt gleich eingerichtet… ;)

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