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

    Vom LAN auf NAT Forwarding zugreifen .. oder ich steh auf dem Schauch …

    Deutsch
    3
    5
    1.1k
    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.
    • Z
      Zikke
      last edited by

      Moinsen zusammen,

      ganz einfache Situation:

      Ich habe per NAT einen Dienst, sagen wir mal HTTPS ins Inet freiegeben. Dieser ist per fester IP und DNS Name auch gut erreichbar. Alles toll :-)

      Wenn ich jetzt aber aus dem selben LAN (in der auch der Server ist) den HTTPS Port erreichen will geht es nicht. Warum? Und was für Möglichkeiten gibt es noch außer den DNS Namen per HostOverride auf die interne IP des Server zu verbiegen? Entweder es gibt nix, oder ich seh den Wald vor Bäumen nicht.

      Evtl hat ja einer ne tolle Idee von euch:-)

      1 Reply Last reply Reply Quote 0
      • N
        nachtmensch
        last edited by

        Hängt deine pfSense an/hinter einem Router?

        Mein ISP hat mein Modem gegen ein tolle All-in-One Büchse getauscht und seitdem komme ich von innen auch nicht mehr über meinen DNS-Namen an den Server… ist wohl ein "Sicherheitsfeature".

        Ich habe nun dem Server einen Alias verpasst und schicke die Anfragen per Firewallregel über meine WAN2 Leitung.

        PC Engines APU.2C4, pfSense 2.3.2-RELEASE-p1

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

          Wenn ich jetzt aber aus dem selben LAN (in der auch der Server ist) den HTTPS Port erreichen will geht es nicht. Warum?

          Möglicherweise hast du keine NAT Reflection aktiviert/konfiguriert? Ich mutmaße mal der DNS Name geht auf die externe IP die aber auf der WAN Seite der pfSense aufliegt (oder auf einem Router davor)?

          Und was für Möglichkeiten gibt es noch außer den DNS Namen per HostOverride auf die interne IP des Server zu verbiegen? Entweder es gibt nix, oder ich seh den Wald vor Bäumen nicht.

          NAT Reflection ist Variante #1 aber häßlich, da du ständig den Traffic sinnfrei über die Firewall schickst, wenn der Service eigentlich direkt "neben" dir im internen Netz steht. Variante #2 ist korrekterweise den HostOverride entweder via pfSense oder deiner lokalen Hosts Datei (pfSense bzw. eigener DNS damit wäre da sinnvoller).

          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
          • Z
            Zikke
            last edited by

            Danke JeGr .. dann war ich ja richtig unterwegs. Dachte nur das es evtl auch was besseres gibt .-)

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

              Für solch ein Szenario eigentlich nur sehr schwer. NAT Reflection ist dann das andere was bleibt, hat aber den "Nachteil", dass man daran denken muss, die Regeln entsprechend passen müssen und man ggf. manchmal verwirrt ist, wenn manche Dinge nicht gleich sofort wie von extern funktionieren und man erst einen Fehler sucht bis man dran denkt, dass man ja quasi von der Firewall reflektiert wird und daher nicht direkt mit dem Server spricht. Gerade bei Endpunkten die nicht direkt, sondern dann wieder z.B. über einen Loadbalancer o.ä. erreicht werden kann das ziemliche Knoten im Weg geben, den das Paket nimmt.

              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
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.