Navigation

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

    OpenVPN (pf ist Client) bleibt über Nacht getrennt

    Deutsch
    3
    15
    139
    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.
    • S
      sebden last edited by

      Moin Allerseits,

      ich habe ein mittelgroßes Problem bei einer Standortkopplung.

      Hier wollen eigentlich 2 pf miteinander sprechen, aber der Client (Außenstelle, LTE-Zugang) verliert "fast" jede Nacht die Verbindung. Hier reicht es unter Status -> OpenVPN einmal den grünen Pfeil zu betätigen und der Tunnel steht sofort.

      Im Protokoll wiederholen sich bis zu diesem Zeitpunkt immer wieder die gleichen Meldungen. Ich versuche den Schnappschuss mal anzuhängen:

      anydesk00008.png

      Danke vorab für einen Tipp, wie sich das lösen lässt. Notfalls vielleicht ein Cron-gesteuerter Reconnect?

      Grüße

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @sebden last edited by

        @sebden
        Ist das eine reine Site-to-Site VPN und ist da auf Clientseite der OpenVPN-Instanz ein Interface zugewiesen und auf dem Gateway das Monitoring aktiviert?
        Die ständigen Pings des Gateway-Monitorings sollten einen Timeout verhindern.

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

          @viragomann
          Danke für die schnelle Reaktion.

          Ja es ist ein Site-to-Site VPN.

          Als Interface habe ich die sog. Gatewaygruppe zugewiesen. Das ist ein Verbund aus 2 Gateways unterschiedlicher Tiers als Failover. Momentan läuft ohnehin nur einer der beiden Gateways, bis an dem Standort das DSL wieder zugeschalten wird.

          Monitoring ist seitens der Gateways aktiv, zu getrennten Cloudflare Servern. Unter OpenVPN ist ein Keepalive aktiv, Intervall = 10, Timeout = 60. Ich meine das war Standard.

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @sebden last edited by

            @sebden said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

            Als Interface habe ich die sog. Gatewaygruppe zugewiesen. Das ist ein Verbund aus 2 Gateways unterschiedlicher Tiers als Failover.

            Ich meinte, ob du der OpenVPN-Instanz (ovnpc1) selbst ein Interface zugewiesen hast.

            Die Gatewaygroup enthält ja vermutlich Upstream-Gateways, nicht VPN. Wenn du die monitorst, geht ja noch keine Traffic über die VPN.

            Ja, die 60 Sekunden für den Timeout sind Standard. Diesen zu erhöhen bringt auch nix, wenn stundenlang keine Daten drübergehen, es sei denn, du setzt ihn auf 20 Stunden. Keine Ahnung, ob OpenVPN das gefällt.
            Allerdings gibt es diesen Timeout auch auf Serverseite.

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

              @viragomann
              Wenn ich die Frage korrekt verstehe, dann nein. Du meinst unter Schnittstellen und Zuweisung? Da wäre ovpnc1 noch zu vergeben. Den Mehrwert hatte ich nur bislang nicht erkannt.

              Die Upstream-Gateways sind wie vermutet vergeben. Einmal der LTE-Router, einmal die nicht aktive FritzBox für das DSL.

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @sebden last edited by

                @sebden said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

                Du meinst unter Schnittstellen und Zuweisung? Da wäre ovpnc1 noch zu vergeben. Den Mehrwert hatte ich nur bislang nicht erkannt.

                Genau.
                Für mich ist eine Interface-Zuweisung bei einer Site-to-Site obligatorisch auf beiden Seiten, wenngleich auch nur für bestimmte Zwecke wirklich nötig.
                Nach Hinzufügen des Interfaces muss die VPN neu gestartet werden.

                Um permanenten Traffic auf der VPN zu haben, ist das Gateway-Monitoring die simpelste Möglichkeit. Kannst aber natürlich auch auf andere Weise einen initieren.

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

                  @viragomann
                  Ah ok. Könnte es sich lohnen das hier zu aktivieren? Ich dachte genau diese Aufgabe übernimmt der keepalive aus dem OpenVPN-Konfigurationsdialog.

                  Und müsste der "tote" Tunnel nicht spätestens erwachen, wenn jemand einen RDP starten will? Zusätzlich hängen noch einige Telefone an der Außenstelle die im 45 Sekunden Takt einen NAT-Keepalive auslösen sollten zur TK in der Hauptstelle.

                  V JeGr 2 Replies Last reply Reply Quote 0
                  • V
                    viragomann @sebden last edited by

                    @sebden said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

                    Zusätzlich hängen noch einige Telefone an der Außenstelle die im 45 Sekunden Takt einen NAT-Keepalive auslösen sollten zur TK in der Hauptstelle.

                    Damit hättest du also schon einen ständigen Traffic.
                    Allerdings könnte das Intervall für den UDP-Timeout zu lang sein.
                    Du könntest es mit dem konservativen Modus versuchen (in System > Advanced > Firewall & NAT) oder nur die UDP-Timeouts erhöhen.

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

                      @sebden said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

                      Und müsste der "tote" Tunnel nicht spätestens erwachen, wenn jemand einen RDP starten will? Zusätzlich hängen noch einige Telefone an der Außenstelle die im 45 Sekunden Takt einen NAT-Keepalive auslösen sollten zur TK in der Hauptstelle.

                      Das ist alles stochern im Nebel ohne Konfiguration. Bitte posten, sonst sieht keiner, was ggf. da nicht stimmt. Bitte beide Seiten :)

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

                        @jegr
                        Hier die Klient-Seite:

                        anydesk00012.png anydesk00011.png anydesk00010.png anydesk00009.png

                        Besten Dank für's drüber schauen!

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

                          Server:
                          anydesk00016.png anydesk00015.png anydesk00014.png anydesk00013.png

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

                            Kleine Ergänzung: Falls es nicht anders zu lösen wäre, habe ich einen Cron-Job für frühs angelegt, der den OpenVPN-Client neu startet. Im Zweifel muss ich mich darauf verlassen. 🤕

                            V 1 Reply Last reply Reply Quote 0
                            • V
                              viragomann @sebden last edited by

                              @sebden said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

                              Falls es nicht anders zu lösen wäre, habe ich einen Cron-Job für frühs angelegt, der den OpenVPN-Client neu startet.

                              Diesen Job sollte das Watchdog-Package weitaus gezielter erledigen können. Es überwacht die VPN und startet den Service ggf. neu.
                              Ich habe es allerdings selbst noch nie eingesetzt.

                              Wenn die Verbindung nun trotz Traffic und langen State-Timeouts immer noch abbricht, würde ich eine Unterbrechung der LTE-Verbindung als Ursache vermuten.
                              In diesem Fall wäre Watchdog bzw. ein Neustart des Clients wahrscheinlich eh das einzige, was helfen kann.

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

                                Ja den Service-Watchdog habe ich immer mit an Bord.

                                Ich weiß nur gerade nicht, ob der Dienst in dem Zustand frühs, dort als Rot erkannt wäre. Prinzipiell läuft er ja laut System-Protokoll, hängt aber im "pending" fest.

                                Sollte der Cron-Job funktionieren, würde ich das vorerst nicht weiter verfolgen. An der Konfiguration war erstmal kein eklatanter Mangel zu erkennen?

                                Ach zur Ergänzung noch: die States sind in dieser Konstellation schon länger Konservativ. Die UDP Timeouts hatte ich zusätzlich vor 1-2 Tagen nochmal auf 50 Sekunden angehoben um oberhalb des NAT-Keepalive der Telefone zu bleiben.

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

                                  @viragomann said in OpenVPN (pf ist Client) bleibt über Nacht getrennt:

                                  Diesen Job sollte das Watchdog-Package weitaus gezielter erledigen können. Es überwacht die VPN und startet den Service ggf. neu.

                                  Jein, das überwacht ja lediglich den Service Status und wenn der Server Up ist wird da auch nichts neu gestartet, weil der Prozess ja läuft. Mich wundert eher, dass da der Client die Verbindung nicht wieder aufbaut, denn dafür ist das Keepalive Statement zuständig und das funktioniert im Normalfall problemlos egal auf welcher Plattform.

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

                                  Products

                                  • Platform Overview
                                  • TNSR
                                  • pfSense Plus
                                  • 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