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

    [solved] Verbindungen über Netzwerkgrenzen hinweg

    Scheduled Pinned Locked Moved Deutsch
    16 Posts 3 Posters 1.0k 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.
    • Bob.DigB
      Bob.Dig LAYER 8 @viragomann
      last edited by Bob.Dig

      @viragomann Danke, es läuft. 👍

      Capture2.PNG

      Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @Bob.Dig
        last edited by

        @Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:

        Als Interface habe ich hier die Verbindung des Hosts zu pfSense ausgewählt.

        Ja, natürlich, das Interface, das hier auszuwählen ist, muss jenes sei, an dem die Pakete die pfSense Richtung Ziel verlassen.
        Als Translation Address ist dann die Interface-IP naheliegend, kann aber auch eine andere virtuelle IP sein, die du dem Interface zuvor zugeordnet hast, aber eben eine aus demselben Subnetz.

        Bob.DigB 1 Reply Last reply Reply Quote 1
        • Bob.DigB
          Bob.Dig LAYER 8 @viragomann
          last edited by Bob.Dig

          @viragomann Habe jetzt aber Probleme mit einem anderen Rechner in LAN, der bekommt keine IP Adresse mehr... Vielleicht ist die Regel doch nicht korrekt?

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @Bob.Dig
            last edited by

            @Bob-Dig
            Mit dieser Outbound NAT Regel kann das nichts zu tun haben. Die behandelt ausschließlich Pakete, die zum Host gehen.

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

              Können die Clients jetzt mit dem Server reden? Ist für den Server echt nur die Source IP ein Problem? Dann ist das ganz schön gruselige Software ;) Aber hey wenns so funktioniert, warum nicht :)

              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
              • Bob.DigB
                Bob.Dig LAYER 8
                last edited by Bob.Dig

                Etwas anderes ist viel gruseliger, meine pfSense ist gerade über den Jordan gegangen, ich habe nur noch Link-local IPv4 Adressen bekommen, nur der DNS-Server stimmte noch. So konnte ich auch nicht mehr auf die pfSense verbinden (bzw. hab es auf die Link-local IPv4 Adresse auch nicht versucht).
                Ich hatte Gott sei Dank noch ein passenden Backup von gestern.

                Könnte Ihr bitte noch mal drauf schauen, ob die NAT-Regel wirklich in Ordnung ist? Ich hatte sie zuerst auf LAN gesetzt, nachdem das nicht ging dann auf das andere Interface, weil Noob. Und die besagte Verbindung ging dann, aber die Sense hat sich irgendwie verabschiedet, Neustart der Sense und des ganzen Host brachte keine Verbesserung mehr. 😨

                Veeam hat mir in Punkto pfSense nun schon mehrfach den Arsch gerettet, danke Veeam. 😙

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

                  Findet sich nichts im System-Log zu dem Vorfall?

                  Bei der Regel kann nicht viel schief gehen. Sie hat ein Interface angegeben, auf dem sie angewandt wird, ein Quell-Netz und eine Ziel-IP und -Port und eben die Interface-IP, auf die die Quell-IPs der Pakete transferiert werden.

                  Die Regel bewirkt hinterher für die pfSense, dass der Zielhost sämtliche Antworten wieder an die pfSense-IP adressiert anstatt direkt auf die Clients (was aber auch über die pfSense laufen würde) und diese setzt dann wieder anhand ihrere States die Ziel-IP auf die ursprüngliche Quell-IP um. Also möglicherweise ein klein wenig mehr Speicherbedarf, aber das kann doch nicht das Problem sein.

                  Bob.DigB 1 Reply Last reply Reply Quote 1
                  • Bob.DigB
                    Bob.Dig LAYER 8 @viragomann
                    last edited by Bob.Dig

                    @viragomann Danke. Was ich noch heute gemacht hatte, eine virtuelle IP angelegt, ohne es wirklich zu verstehen, aber dann auch nicht groß was damit gemacht.
                    Das Log hätte ich mir wie ansehen können, in der Console? Oder mittels SSH auf die Link-local IPv4 Adresse verbinden? Hab die vhdx-Datei noch hier, aber Windows kann damit nix anfangen und ich auch nicht.
                    Gut, werde die NAT-Regel noch mal versuchen, Backup ist ja offensichtlich gegeben.

                    Habe jetzt die Regel noch mal weiter präzisiert und die Ports auf alle mir bekannten Ports erweitert.
                    fdgdgf.PNG
                    Mein subjektiver Eindruck ist, dass die Clients langsamer starten als vorher, was vielleicht bedeuten könnte, dass zwar der eingebaute Test erfolgreich verläuft, aber noch nicht alles rund läuft...

                    Bis jetzt keine Auffälligkeiten was die Sense betrifft. 😌

                    JeGrJ 1 Reply Last reply Reply Quote 0
                    • JeGrJ
                      JeGr LAYER 8 Moderator @Bob.Dig
                      last edited by

                      @Bob-Dig said in Verbindungen über Netzwerkgrenzen hinweg:

                      Link-local IPv4 Adresse

                      was für Link local bitte?

                      logs ansehen

                      mit: clog <logfile>

                      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.

                      Bob.DigB 1 Reply Last reply Reply Quote 0
                      • Bob.DigB
                        Bob.Dig LAYER 8 @JeGr
                        last edited by

                        @JeGr said in Verbindungen über Netzwerkgrenzen hinweg:

                        was für Link local bitte?

                        Na so was:
                        169.254.0.0/16

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

                          Das ist APIPA nicht link-local. Sprich DHCP gescheitert, automatisch ne private Adresse vergeben. Heißt also effektiv nur, dass deine Kiste DHCP wollte und keine bekommen hat. Fände ich jetzt im ersten Moment bei ner Firewall eher komisch weil die außer ggf aufm WAN eigentlich kein DHCP Client spricht :)

                          Ansonsten auf Konsole in /var/log sich das Log mit clog system.log bspw. anschauen.

                          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.

                          Bob.DigB 1 Reply Last reply Reply Quote 0
                          • Bob.DigB
                            Bob.Dig LAYER 8 @JeGr
                            last edited by

                            @JeGr said in Verbindungen über Netzwerkgrenzen hinweg:

                            Das ist APIPA nicht link-local.

                            Dann muss jemand mal den Wikipedia Eintrag anpassen. Ich vermute einfach mal, beides ist korrekt.
                            Deswegen, die Sense ist hops gegangen oder mindestens der DHCP-Dienst. Aber Backup hat den Tag gerettet, mal wieder.

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