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

    Routing von VPN zu VPN zu VPN :)

    Scheduled Pinned Locked Moved Deutsch
    16 Posts 2 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.
    • H
      hilfi2000
      last edited by

      Hallo Freunde des Routings und IPsec,

      folgende Umgebung habe ich:

      LAN 192.168.3.0/24      IP: .1                IPsec über DSL      .1      LAN 192.168.0.0/24          IP .254
      Client  –----------------> FW1(Juniper) ---VPN-zu-FW2--------FW2-------------------------------VPN-Router (nicht in meiner Hoheit)
      IP .150                                                                              |                            |
                                                                                                |                            |----------Client IP .150
                                                                                                |
                                                                                                |
                                                                                                |
                                                                                                FW-Dienstleiter (nicht in meiner Hoheit)
                                                                                                |    LAN 10.0.0.0/24
                                                                                                |
                                                                                                |
                                                                                                Server .100

      Kurze Erläuterung:

      Auf FW2 läuft pfSense, die FW1 ist noch eine alte Juniper Netscreen Appliance.
      Der VPN Router und die Firewall-Dienstleiter gehöhren einem Dritten, ich habe keinen Zugriff.

      Vom LAN 192.168.0.0/24 kann ich über den VPN Router auf das LAN des Dienstleisters 10.0.0.0/24 zugreifen. Dazu baut der VPN Router über meine FW2 eine VPN Verbindung zur FW des Dienstleisters auf. Auf der FW2 habe ich eine statische Route für das LAN 10.0.0.0/24 mit dem Gateway 192.168.0.254 hinterlegt.

      Zwischen FW1 und FW2 ist auch ein IPsec VPN aufgebaut. Ich kann von beiden Seiten alle Clients erreichen.

      Problem:
      Jetzt möchte ich vom Netz 192.168.3.0/24 auf den Server 10.0.0.100 zugreifen.
      Auf der Firewall (Juniper, FW1) habe ich dazu eine statische Route zum VPN Router eingerichtet (10.0.0.0/24 zu 192.168.0.254).
      Wenn ich jetzt z.B. versuche den Server 10.0.0.100 per ping zu erreichen, sehe ich auf der Firewall im Log "Firewall", dass 192.168.3.150 eine ICMP Verbindung aufbauen möchte und die Firewall Rules das auch zulässt. Ich bekomme aber leider keine Antwort (Zeitüberschreitung...).

      Ich muss dazu sagen, dass ich bis zum Wochenende an Stelle der pfSense auch eine Juniper Netscreen hatte. Mit dieser könnte ich mit dieser Konfiguration den Server 10.0.0.100 erreichen.

      Wo kann ich noch nach Fehlern suchen bzw. habt ihr eine Idee?

      Kann es sein dass der Dienstleister auf dem VPN Router eine weitere Phase 2 für das LAN 192.168.3.0 einrichten muss? (bin mir nicht sicher ob er das getan hat).
      Aber warum ging es dann mit der "alten Juniper"???

      Habe jetzt einen ganzen Tag geforscht, leider ohne Erfolg.

      Ich hoffe eine von euch hat eine ähnliche Konfig und kann mir helfen.

      Danke und VG
      HilFi

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

        Wo kann ich noch nach Fehlern suchen bzw. habt ihr eine Idee?

        Jep. Du musst dein Netz .3.0/24 maskieren (NAT) damit als abgehende Adresse beim Dienstleister im 10.0.0.0er Netz eine 192.168.0.x Adresse auftaucht. Deren VPN Router bei dir (.254) kennt dein .3.0er Netz nicht und hat logischerweise keine Rückrouten dafür. Entweder du sagst ihm, dass er .3.0 auch zurückrouten soll, oder du maskierst deine .3.0er Adressen wenn sie nach 10.x wollen mit der IP der pfSense, also der .0.1

        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
        • H
          hilfi2000
          last edited by

          Moin,

          Danke für die Antwort, dachte ich mir schon.

          Unter VPN-IPsec-Tunel-Phase2 habe ich NAT/BINAT translation "Adress" mit der IP 192.168.0.1 ausgewählt.
          So geht es leider nicht.

          Was muss ich bei NAT einstellen?

          Oder muss ich unter Firewall–-NAT etwas eintragen?

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

            Wenn ich mich recht entsinne, dann musst du bei Outbound NAT für dein LAN Interface konfigurieren, dass Pakete von 192.168.3.0/24 auf Interface LAN auf die Interface Address gemappt werden. Das sollte es eigentlich sein.

            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
            • H
              hilfi2000
              last edited by

              Hallo,

              nein, leider war ich damit nicht erfolgreich.

              Ich habe Outbound NAT wie folgt eingestellt:

              Interface LAN
              Source 192.168.3.0/24
              DEST any
              NAT Adress: LAN Adress

              Habe es auch mit Interface IPsec und static Port versucht.
              Alles ohne Erfolg

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

                DEST hätte ich jetzt die 10.0.0.0/24 vom Zielnetz erwartet?

                was sagt denn ein TCPDump / packet capture auf der pfSense? Wie kommen die Pakete via IPSec an? Und wie gehen sie auf das LAN raus?

                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
                • H
                  hilfi2000
                  last edited by

                  DEST 10.0.0.0 hatte ich auch versucht. Dachte mir aber bei any ist es auch mit dabei

                  Werde mal ein CAP starten

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

                    Stimmt natürlich. Deine Einstellungen sind:

                    • Outbound NAT
                    • Interface LAN
                    • Protocol any
                    • Source: 192.168.3.0/24
                    • Destination: any
                    • Address: Interface Address

                    -> das wäre mein Ansatz gewesen. Wir machen das momentan für einen Kunden ähnlich allerdings umgekehrt. Er wählt sich mit OpenVPN Clients bei uns ein und wird über seinen eigenen IPsec Tunnel zu sich ins Office Netz geroutet. Stellenweise ging das sogar noch weiter zu AWS. Deshalb sollte das eigentlich schon funktionieren…

                    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
                    • H
                      hilfi2000
                      last edited by

                      ja, genauso.

                      Habe jetzt auf DEST 10.0.0.0 umgestellt.

                      Hier mein CAP mit Filter auf ICMP

                      CAP vom LAN

                      13:59:20.829563 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 64, id 58627, offset 0, flags [none], proto ICMP (1), length 28)
                          192.168.0.1 > 192.168.0.254: ICMP echo request, id 20991, seq 22093, length 8
                      13:59:20.829731 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 63, id 29587, offset 0, flags [none], proto ICMP (1), length 28)
                          192.168.0.254 > 192.168.0.1: ICMP echo reply, id 20991, seq 22093, length 8
                      13:59:21.361566 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 42: (tos 0x0, ttl 64, id 43883, offset 0, flags [none], proto ICMP (1), length 28)
                          192.168.0.1 > 192.168.0.254: ICMP echo request, id 20991, seq 22094, length 8
                      13:59:21.361742 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 63, id 29588, offset 0, flags [none], proto ICMP (1), length 28)
                          192.168.0.254 > 192.168.0.1: ICMP echo reply, id 20991, seq 22094, length 8

                      CAP IPsec
                      13:58:00.670720 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33140, offset 0, flags [none], proto ICMP (1), length 128)
                          192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 37708, length 108
                      13:58:01.634234 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33146, offset 0, flags [none], proto ICMP (1), length 128)
                          192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 37908, length 108
                      13:58:02.658749 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33155, offset 0, flags [none], proto ICMP (1), length 128)
                          192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38308, length 108
                      13:58:03.637518 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33161, offset 0, flags [none], proto ICMP (1), length 128)
                          192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38508, length 108
                      13:58:04.659020 (authentic,confidential): SPI 0xc9b159a6: (tos 0x0, ttl 64, id 33165, offset 0, flags [none], proto ICMP (1), length 128)
                          192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 38608, length 108

                      Für mich sieht es so aus, ob auf dem Rückweg das Packet verschwindet :)

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

                        Ist das beide Male der gleiche Ping? Eigentlich müsste dann ja im ersten CAP schon das Ziel 10.0.0.1 sein, oder? Das irritiert mich gerade etwas.

                        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
                        • H
                          hilfi2000
                          last edited by

                          du hast recht. Ich kann das ja leider nicht gleichzeitig machen ;)

                          jetzt aber:

                          CAP vom LAN

                          16:15:44.161450 00:0d:b9:44:f5:15 > 00:a0:f9:42:7e:a0, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 63, id 391, offset 0, flags [none], proto ICMP (1), length 128)
                              192.168.0.1 > 10.0.0.1: ICMP echo request, id 34859, seq 52220, length 108
                          16:15:44.190036 00:a0:f9:42:7e:a0 > 00:0d:b9:44:f5:15, ethertype IPv4 (0x0800), length 142: (tos 0x0, ttl 126, id 24262, offset 0, flags [none], proto ICMP (1), length 128)
                              10.0.0.1 > 192.168.0.1: ICMP echo reply, id 34859, seq 52220, length 108

                          CAP IPsec

                          16:13:34.411762 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65481, offset 0, flags [none], proto ICMP (1), length 128)
                              192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 42920, length 108
                          16:13:35.411497 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65491, offset 0, flags [none], proto ICMP (1), length 128)
                              192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 43020, length 108
                          16:13:36.411528 (authentic,confidential): SPI 0xc9b59192: (tos 0x0, ttl 64, id 65496, offset 0, flags [none], proto ICMP (1), length 128)
                              192.168.3.1 > 10.0.0.1: ICMP echo request, id 1024, seq 43220, length 108

                          Sieht trotzdem so aus, als würde der reply verschluckt werden.

                          1 Reply Last reply Reply Quote 0
                          • H
                            hilfi2000
                            last edited by

                            ich glaube ich muss static port aktivieren bei NAT.
                            Geht damit aber auch noch nicht.

                            Muss ich vielleicht im VPN Phase 2 noch was ändern?

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

                              Hmm OK das sieht mir dann so aus, als würde er nicht NATten… und du bekommst dann keine Antwort, weil die Rückroute fehlt. Andere Frage: Kannst du in die State Table schauen? Hier müsste es für das Ziel 10.0.0.1 ja dann mehrere States geben (bspw. von 192.168.0.1) wo auch zu sehen sein sollte, ob bspw. genattet wird oder nicht. Ich muss nochmal nachforschen wo es da haken könnte...

                              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
                              • H
                                hilfi2000
                                last edited by

                                folgendes finde ich da:

                                mit static port bei outbound NAT

                                IPsec icmp 192.168.3.1:1024 -> 10.0.0.1:1024 0:0 29 / 29 4 KiB / 4 KiB
                                LAN icmp 192.168.0.1:7221 (192.168.3.1:1024) -> 10.0.0.1:7221 0:0 29 / 29 4 KiB / 4 KiB

                                ohne static port:

                                IPsec icmp 192.168.3.1:1024 -> 10.251.74.1:1024 0:0 40 / 40 5 KiB / 5 KiB
                                LAN icmp 192.168.0.1:31276 (192.168.3.1:1024) -> 10.251.74.1:31276 0:0 40 / 40 5 KiB / 5 KiB

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

                                  das sieht aber im State so aus, als würde er korrekt das .3.1 in .0.1 umwandeln und NATten. Allerdings verstehe ich den zweiten Eintrag darunter nicht -> wo kommt da plötzlich die .221 her?

                                  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
                                  • H
                                    hilfi2000
                                    last edited by

                                    .221 war ein c&p Fehler ;)

                                    Wo verschwindet dann das Paket?

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