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

    Open VPN - internes Netz nicht erreichbar

    Deutsch
    3
    24
    1.8k
    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.
    • P
      pc-dok
      last edited by

      so ich habe nun den redirect gateway rausgenommen und im local network folgendes gesetzt:
      192.168.2.0/24,192.168.1.0/24,10.0.0.0/16

      Wow, nun funktioniert der ping auch auf das interne LAN auf den 192.168.1.254. Auch auf das HP ILO MGMT mit 192.168.1.252 komm ich nun rauf, das geht also in meinen augen. nur der Zugriff auf die Azure IPSec 10.0.0.0/16 geht nicht. Also ich schalte in Azure den AD Server ein, der die 10.0.2.101 hat, aber ich kann ihn nicht pingen. Kann ich mit dem open VPN dann überhaupt auf den IPSEC Tunnel zugreifen?

      Hier der Output vom Packet Capture:

      23:58:33.082445 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 828, length 40
      23:58:33.082470 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 828, length 40
      23:58:34.112197 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 829, length 40
      23:58:34.112213 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 829, length 40
      23:58:35.137665 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 830, length 40
      23:58:35.137680 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 830, length 40
      23:58:40.020774 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 831, length 40
      23:58:40.020791 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 831, length 40
      23:58:41.922452 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 832, length 40
      23:58:41.922469 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 832, length 40
      23:58:42.932329 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 833, length 40
      23:58:42.932344 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 833, length 40
      23:58:43.945614 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 834, length 40
      23:58:43.945629 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 834, length 40
      23:58:44.972436 IP 192.168.100.2 > 192.168.1.254: ICMP echo request, id 1, seq 835, length 40
      23:58:44.972451 IP 192.168.1.254 > 192.168.100.2: ICMP echo reply, id 1, seq 835, length 40
      23:58:49.235986 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 836, length 40
      23:58:54.002531 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 837, length 40
      23:58:59.010760 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 838, length 40
      23:59:04.002508 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 839, length 40

      hey schon mal jetzt coole sache vielen dank, hast mir schon super geholfen, wenn wir das noch mit Azure IPSEC herbringen könnten, wäre coole Sache!

      gruss frank

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

        @pc-dok:

        Kann ich mit dem open VPN dann überhaupt auf den IPSEC Tunnel zugreifen?

        Solange dein OpenVPN-Tunnel ein Subnetz des Azure-Netzes ist, wird das nix!

        Wenn du diesen entsprechend geändert hast, musst du noch dem IPSec Tunnel klar machen, an welchem Ende welches Netz zu finden ist.

        1 Reply Last reply Reply Quote 0
        • P
          pc-dok
          last edited by

          hmm, ich habe ja das OpenVPN Netz umgestellt auf 192.168.100.0/24, das Azure IP Sec Netz ist ja das 10.0.0.0/16. Internes Netz ist 192.168.1.0/24, und WAN ist 192.168.2.0/24. Was müsste ich nun beim IP Sec Tunnel noch einstellen, oder hab ich was falsch verstanden?

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

            Moment, möglicherweise hab ich was falsch verstanden.

            Zwischen welchen Geräten steht die IPSec Tunnel. Zwischen pfSense und Azure und du möchtest mit dem PC über OpenVPN auf die pfSense und dann über IPSec auf die Azure Server zugreifen? So hab ich es verstanden.

            1 Reply Last reply Reply Quote 0
            • P
              pc-dok
              last edited by

              ja eigentlich habe ich es mir so gedacht:
              zuhause habe ich den IPSec Tunnel zu der Azure, das heisst meine Server von 192.168.1.0/24 können nun auch die Server im Azure Netz erreichen 10.0.2.0/24. Nun versuche ich, das wenn ich mit dem Laptop unterwegs bin, mit OpenVPN auf mein Netzt zuhause zuzugreifen, also auf das 192.168.1.0/24, was nun auch geht, aber schön wäre jetzt noch wenn ich auch nun die Azure Server erreichen könnte, also die Server die im 10.0.2.0/24 oder halt insgesamt ist das Azure Net auf 10.0.0.0/16 eingerichtet, erreichen könnte. Weiss allerdings gar nicht ob das so möglich ist. Geht das überhaupt?

              gruss
              frank

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

                Ja, geht, wenn die Routen stimmen.

                Das Server Netz von Azure 10.0.2.0/24, das du erreichen möchtest, hast du ja schon zu den Local Networks im OpenVPN-Server hinzugefügt. Wenn du das ganze Netz 10.0.0.0/16 erreichen möchtest, setze eben dieses anstatt 10.0.2.0/24 ein.

                Dann musst du noch die Routen für den IPSec-Tunnel setzen.
                Dazu musst du der IPSec-Konfiguration auf beiden Seite eine zusätzliche Phase 2 hinzufügen.
                Auf der pfSense:
                Local Network: 192.168.100.0/24 (das OpenVPN Tunnel-Netz)
                Remote Network: 10.0.2.0/24 (das Netz, das du auf der anderen Seite erreichen möchtest)

                Auf Azure-Seite muss das genau umgekehrt aussehen.

                Grüße

                1 Reply Last reply Reply Quote 0
                • P
                  pc-dok
                  last edited by

                  ok, es reicht mir das 10.0.2.0/24 Netz, da sind die backend Server drin, habe mir das auch schon so gedacht. Ich habe bereit im IPSec in der Phase2 Entrie als Local Network die 192.168.100.0/24 und als remote wieder die 10.0.2.0/24 eingetragen, da ich das schon vermutet hatte, trotzdem geht der PING noch nicht, aber du hast ja wahrscheinlich recht, natürlich werde ich genau das gleiche noch beim Azure GW einrichten müssen. Mal schauen, hey echt, cool das du mir hilfst. genial. auch grüsse aber nun mal zuerst gn8, mach morgen am abend weiter!

                  1 Reply Last reply Reply Quote 0
                  • P
                    pc-dok
                    last edited by

                    ok, habe also nun eine phase 2 entry gemacht, wie vorher beschrieben, hab in Azure zum Virtual Network Gateway ein local Network Gateway hinzugefügt mit IP Adress Range 192.168.100.0/24 und dann eine Local Connection eingerichtet. Laut Azure ist sie auch connected, aber ich komme nicht zum Server, also der Ping geht immer noch nicht, und ich habe das mit der Diagnostic nun:

                    01:56:14.752684 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 1181, length 40
                    01:56:19.515185 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 1182, length 40
                    01:56:24.510267 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 1183, length 40
                    01:56:29.510227 IP 192.168.100.2 > 10.0.2.101: ICMP echo request, id 1, seq 1184, length 40

                    hmm was könnte den jetzt noch fehlen?

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

                      Das konnte wohl doch nicht warten?  ;D

                      Die Firewall-Regeln lassen den Zugriff zu?

                      Wie sehen die Routen auf allen beteiligten Geräten aus?

                      Von der pfSense bzw. den Heimservern kommst du ja auf 10.0.2.0/24?

                      1 Reply Last reply Reply Quote 0
                      • P
                        pc-dok
                        last edited by

                        sagen wir mal so, wenn ich bei Azure eine zusätzliche Local Network Gateway mit dem Range 192.168.100.0/24, und eine neue Connection gemacht, und habe bei pfsense einfach ne neue Phase2 Entry gemacht, und auch die IPSec Firewall Rule hinzugefügt. Dann habe ich aber das Problem das ich das normale Azure Netzt, also die Server konnte ich danach nicht mehr erreichen. Ich werde heute also nochmal komplett eine eigene IPSec VPN machen für das 192.168.100.0 und das gleiche bei Azure, so das ich 2 IPSEC VPNs aufbaue. Evtl. geht es ja dann. Sehr sehr interessant das ganze :)

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

                          @pc-dok:

                          sagen wir mal so, wenn ich bei Azure eine zusätzliche Local Network Gateway mit dem Range 192.168.100.0/24

                          Zu Azure kann ich nichts sagen, ich kenne es nicht so weit.
                          Doch "Local Network" klingt für mich nicht logisch, wenn dieses Netz an der anderen Seite liegt, also Remote.

                          Sollte bei Azure nur ein Tunnel möglich sein, kannst du ja auch diesen einen so konfigurieren, dass er alle benötigen Remote-Netze mit einschließt, bspw. 192.168.0.0/17. Solange da keine weiteren Verbindung aufgebaut werden, stört das ja nicht. Oder du legst den OpenVPN-Tunnel näher zu deinem Heimnetz und kannst dann den IPSec-Tunnel enger machen.
                          Wichtig ist, dass die Einstellungen immer an beiden Seiten des Tunnels gegengleich sind.

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