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

    Routing von VPN zu VPN zu VPN :)

    Deutsch
    2
    16
    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.
    • 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.