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

    OpenVPN Probleme mit aktivem CARP

    Scheduled Pinned Locked Moved Deutsch
    10 Posts 4 Posters 1.8k 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.
    • D
      d4sId
      last edited by

      Hallo zusammen

      Ich habe erst gerade auf Hochverfügbarkeit umgestellt. Bis dahin funktionierte alles korrekt. Seit der Umstellung habe ich Probleme mit OpenVPN.

      Zuerst mal meine Konstellation.

      Modem:
      WAN: 192.168.10.1

      Modem NAT:
      1. öffentliche IP Adresse -> 192.168.10.2
      2. öffentliche IP Adresse -> 192.168.10.202
      3. öffentliche IP Adresse -> 192.168.10.203
      4. öffentliche IP Adresse -> 192.168.10.204
      5. öffentliche IP Adresse -> 192.168.10.205
      6. öffentliche IP Adresse -> 192.168.10.206

      Firewall:
      pf1:
      WAN: 192.168.10.250
      DMZ: 192.168.5.250
      LAN: 192.168.1.250

      pf2:
      WAN: 192.168.10.251
      DMZ: 192.168.5.251
      LAN: 192.168.1.251

      Virtuelle IPs:
      WAN: 192.168.10.2 (Haupt Adresse)
      WAN2: 192.168.10.202
      WAN3: 192.168.10.203
      WAN4: 192.168.10.204
      WAN5: 192.168.10.205
      WAN6: 192.168.10.206
      DMZ: 192.168.5.1
      LAN: 192.168.1.1

      Sync Interface ist hier nicht aufgeführt, dies funktioniert einwandfrei ;-)

      NAT:
      WAN (Interface) -> UDP (Proto) -> * (Src. addr) -> * (Src. ports) -> 192.168.10.2 (Dest. addr) -> 1194 (Dest. ports) -> 192.168.1.1 (NAT IP) -> 1194 (NAT Ports)

      Das VPN funktioniert aber einfach nicht. Wenn ich einen Port Test mache, sagt dieser der Port sei geschlossen. Wenn ich als NAT IP bspw. die IP Adresse des Wireless Router eingebe (192.168.1.10), ist der Port beim Port Test offen. Die gleiche Konstellation hat vorher erfolgreich funktioniert, bevor ich die Umstellung auf Hochverfügbar durchgeführt habe.

      Hat hier jemand einen Tipp?
      Ich blicke echt nicht mehr durch, aus meiner Sicht müsste es passen.

      Danke und Gruss

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

        Also grundsätzlich funktioniert so etwas.

        Ich habe eine ähnliche Konfiguration, doch forwarde ich eine interne, private CARP VIP auf eine öffentliche (WAN VIP). Klappt ohne Probleme.

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

          Jo dachte ich auch  ;)
          Seitdem das Ziel (192.168.1.1) eine CARP VIP ist, funktioniert es nicht mehr. Vorher war der einzige Unterschied, dass es eine normale LAN Adresse der Firewall war.

          1 Reply Last reply Reply Quote 0
          • B
            bitboy0
            last edited by

            Bei mir läuft es prima… du musst konsequent in ALLEM die vIPs eintragen ... NAT,Rules,Interfaces,usw.
            Am Anfang hab ich da auch eine Weile gebraucht bis ich alles gefunden hatte wo das rein muss.

            Wenn du eine bestehende Konfiguration hast dann prüfe mal:

            • Im VPN-Server muss als Interface die vIP stehen, die als WAN dafür vorgesehen ist
            • Eine Rule muss für das WAN eingerichtet sein. IPV4/UDP mit Destination WAN adress und dem Port des Servers.
            1 Reply Last reply Reply Quote 0
            • D
              d4sId
              last edited by

              Habe ich gemacht, ist bei mir aus meiner Sicht überall korrekt. Sobald ich als NAT IP bspw. den Wireless AP angebe, ist der Port sogleich offen. Wenn ich die NAT IP wieder auf die CARP VIP vom LAN lege (192.168.1.1) ist der Port wieder zu.

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

                Wenn ich die NAT IP wieder auf die CARP VIP vom LAN lege (192.168.1.1) ist der Port wieder zu.

                Der Teil ist mir unklar. Was legst du warum wo wie auf die VIP vom LAN? Was hat die denn damit zu tun?

                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
                • B
                  bitboy0
                  last edited by

                  Ich hatte mit CARP auch einiges an Problemen. Hauptsächlich wegen mir unbekannter Begriffe und auch weil pfSense teilweise etwas eigen ist.
                  Ich denke, das auch hier einfach das nur ein paar Missverständnisse sind … das Problem ist vermutlich einfach zu lösen. Nur herauszufinden an welcher Stelle der TE sich grade selber reinlegt ist das Problem.

                  gruß

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

                    @JeGr:

                    Wenn ich die NAT IP wieder auf die CARP VIP vom LAN lege (192.168.1.1) ist der Port wieder zu.

                    Der Teil ist mir unklar. Was legst du warum wo wie auf die VIP vom LAN? Was hat die denn damit zu tun?

                    Der OpenVPN Server läuft ja auf pfsense. Ich habe daher per NAT die erste öffentliche IP Adresse mit UDP Port 1194 auf die CARP VIP des LANs gelegt. Ich habe diese NAT Regel auch schon temporär deaktiviert und dafür die FW Regel auf die WAN Schnittstelle (*.10.2) zeigen lassen, Port bleibt leider zu…

                    Oder mache ich hier etwas komplett falsch? Vorher hatte ich es so eingerichtet und VPN hat tadellos funktioniert.

                    @bitboy0:

                    Ich hatte mit CARP auch einiges an Problemen. Hauptsächlich wegen mir unbekannter Begriffe und auch weil pfSense teilweise etwas eigen ist.
                    Ich denke, das auch hier einfach das nur ein paar Missverständnisse sind … das Problem ist vermutlich einfach zu lösen. Nur herauszufinden an welcher Stelle der TE sich grade selber reinlegt ist das Problem.

                    gruß

                    Da bin ich mir sicher, es wird irgendetwas sein dass ich übersehe. Nur was?  :)

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

                      Grrrrrrr!  :-\

                      OpenVPN auf der WAN Schnittstelle nochmals per Regel geöffnet -> VPN funktioniert wieder. Aber der Port Test sagt noch immer der Port ist zu:
                      Checking UDP.
                      Port 1194 is closed at xxx.xxx.xxx.201

                      Ich habe mich der massen auf den Port Test verlassen, dass ich den Verbindungsaufbau gar nicht mehr getestet hatte. Hatte ja keine Lust jedes Mal bei einer Änderung wieder die ganzen Credentials einzugeben  :-\

                      Vielen Dank für eure Unterstützung!

                      1 Reply Last reply Reply Quote 0
                      • B
                        bitboy0
                        last edited by

                        Also

                        • IP/Port weiterleiten von Router auf das WAN der pfSense (auf die vIP des WAN)
                        • Rules: für das betreffenden WAN-interface auf der pfSense -> "IPv4(UDP)" von "/" auf "/1194" per Gateway ""
                        • Rules: für OpenVPN -> "IPv4() von "/" auf "/" per Gateway ""
                        • Routes: Netz des VPN auf das Gateway auf dem aus auch angesprochen werden soll (also das entsprechende WAN, dessen vIP du oben benutzt)

                        Wenn du einen Router hast, bei dem du nicht bestimmen kannst, welche IP abgehend dann benutzt wird… also keine Ahnung was dann passiert.
                        Was für ein Router ist denn das?

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