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

    Internen Traffic über NAT zurück ins LAN leiten

    Scheduled Pinned Locked Moved Deutsch
    19 Posts 6 Posters 1.1k 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.
    • U
      unique24
      last edited by unique24

      Hallo,

      ich habe statische DNS Einträge.

      public.company.com weisst bei mir im internen LAN auf die interne IP der pfSense.
      Wäre ich extern, erhalte ich vom öffentlichen DNS Server die externe IP der pfSense.

      Das Problem:
      Wenn ich am Handy oder PC Programme haben, die über eine Port Weiterleitung auf der pfSense auf ein internes Gerät zeigt, klappt das nicht intern:

      extern ok:
      PC => WAN => pfSense => NAT Port Forwarding => LAN => interner PC

      intern nicht ok:
      PC => LAN => pfSense => WAN => ??

      sollte so sein:
      PC => LAN => pfSense => NAT Port Forwarding => LAN => interner PC

      Ich müsste also den Traffic, der an der pfSense an einem Port ankommt, wo ein NAT existiert, diesen "zurück" ins passende LAN senden.

      Wie kann ich das erreichen?

      Danke!

      V 1 Reply Last reply Reply Quote 0
      • RicoR
        Rico LAYER 8 Rebel Alliance
        last edited by

        https://docs.netgate.com/pfsense/en/latest/recipes/port-forwards-from-local-networks.html

        -Rico

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

          @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

          public.company.com weisst bei mir im internen LAN auf die interne IP der pfSense.

          Warum? Läuft ein Proxy für diese Domain auf der pfSense?
          Falls nicht ist das doch sinnfrei, dann gib im internen DNS gleich die IP des Zielservers an.

          1 Reply Last reply Reply Quote 0
          • U
            unique24 @Rico
            last edited by unique24

            @Rico Danke, scheint aber nicht zu klappen.

            Ich habe Apps die auf ein Service im LAN zugreifen. Das soll intern als auch extern klappen. Ich kann ja aber nur eine IP hinterlegen.

            Ich füge also den externen DNS Namen ein, und der dann immer zur pfSense geht.

            Aber das NAT klappt von intern nicht. Ich teste das grad mit WireGuard auf Port 8999 UDP.

            Wenn mein iPhone mit dem LAN verbunden ist, vebindet es sich nicht mit dem WireGuard Server. Wenn ich das WLAN abschalte und per 4G surfe, klappt es.

            Meine Einstellungen:
            7b4bee2f-7807-4c01-9faf-2bde59a01bd4-image.png

            sollte er da etwas eintragen?:
            e90916a1-e4f9-41b9-a4aa-98fa1ee53958-image.png

            1 Reply Last reply Reply Quote 0
            • U
              unique24
              last edited by

              Hab nun das noch gesetzt:
              49855354-a6ab-4d55-9be9-0412efcb3f8f-image.png

              Aber noch kein Erfolg ... macht mir die Firewall rule hier ein Strich durch die Rechnung?

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

                @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                Hab nun das noch gesetzt:
                49855354-a6ab-4d55-9be9-0412efcb3f8f-image.png

                Aber noch kein Erfolg ... macht mir die Firewall rule hier ein Strich durch die Rechnung?

                Das ist eine NAT-Regel, kein DNS.

                @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                public.company.com weisst bei mir im internen LAN auf die interne IP der pfSense.

                Das hatte ich als internes (Split) DNS verstanden. Das wäre die richtige Umsetzung, allerdings mit der internen Server-IP als Ziel.

                Wenn du es via NAT Reflection realisieren möchtest, muss dein internes DNS auch auf die WAN-IP auflösen.

                1 Reply Last reply Reply Quote 0
                • U
                  unique24
                  last edited by

                  @viragomann said in Internen Traffic über NAT zurück ins LAN leiten:

                  muss dein internes DNS auch auf die WAN-IP auflösen.

                  Wie meinst du das?
                  Wenn ich intern bin, und den DNS Namen "portal.company.com" eingebe, löst es auf die interne WAN IP der pfSense auf.

                  Du meinst ich muss auf die externe WAN adresse auflösen?

                  Ich habe bis dato 3 Host overrides.
                  9b5551c6-e425-4f44-9936-e91cd8471ddd-image.png

                  Wenn ich im LAN "portal.company.com" eingebe, komme ich auf Server A
                  firewall.company.com ist die pfSense
                  cloud.company.com ist mein Fileserver.

                  So konnte ich mit der Namensauflösung die 3 Geräte direkt ansprechen. Alle 3 existieren auch im öffentlichen DNS und wird dann vpn der WAN kommend, auf die 2 Geräte passende weiter gegeben (firewall ausgenommen).

                  Ich vermute ich muss diese rausnehmen muss?

                  Die ganze Geschichte sollte am Ende so funktionieren:
                  cloud.company.com:80 => WAN => pfSense => LAN => Server 1
                  cloud.company.com:80 => LAN => pfSense => LAN => Server 1
                  cloud.company.com:443 => WAN => pfSense => LAN => Server 1
                  cloud.company.com:443 => LAN => pfSense => LAN => Server 1

                  firewall.company.com:80 => LAN => pfSense Admin

                  portal.company.com:80 => WAN => pfSense => LAN => Server 2
                  portal.company.com:80 => LAN => pfSense => LAN => Server 2
                  portal.company.com:443 => WAN => pfSense => LAN => Server 2
                  portal.company.com:443 => LAN => pfSense => LAN => Server 2

                  portal.company.com:xx => WAN => pfSense => LAN => Server 3
                  portal.company.com:xx => LAN => pfSense => LAN => Server 3

                  portal.company.com:yy => WAN => pfSense => LAN => Server 4
                  portal.company.com:yy => LAN => pfSense => LAN => Server 4

                  portal.company.com:zz => WAN => pfSense => LAN => Server 5
                  portal.company.com:zz => LAN => pfSense => LAN => Server 5

                  ...

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

                    @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                    Die ganze Geschichte sollte am Ende so funktionieren:
                    cloud.company.com:80 => LAN => pfSense => LAN => Server 1
                    cloud.company.com:443 => LAN => pfSense => LAN => Server 1
                    portal.company.com:80 => LAN => pfSense => LAN => Server 2

                    So soll es nicht sein, sondern
                    cloud.company.com:80 => LAN => Server 1

                    Warum sollen der Traffic von einem LAN-Gerät zu einem anderen die pfSense passieren? Wenn du diesen filtern möchtest, stecke die Server in eine DMZ.
                    Genau dafür setzt du ja im DNS ein Hostoverride auf die interne IP des Servers.

                    @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                    So konnte ich mit der Namensauflösung die 3 Geräte direkt ansprechen. Alle 3 existieren auch im öffentlichen DNS und wird dann vpn der WAN kommend, auf die 2 Geräte passende weiter gegeben (firewall ausgenommen).

                    Was ist nun dein tatsächliches Problem? Sieht ja alles gut aus.

                    @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                    Ich vermute ich muss diese rausnehmen muss?

                    Nein, das benötigst du ja, um die pfSense per Namen anzusprechen.

                    U 1 Reply Last reply Reply Quote 0
                    • U
                      unique24 @viragomann
                      last edited by unique24

                      @viragomann
                      Vielleicht erkläre ich es ja schlecht:

                      ich habe 5 Port Weiterleitungen:
                      Port 8080 zu Server 1, Port 80
                      Port 8999 zu Server 2, Port 8999
                      Port 37777 zu Server 3, Port 37777
                      Port 21000 zu Server 4, Port 80
                      Port 8884 zu Server 3, Port 80

                      Die 5 Programme haben je ein Ziel:
                      portal.company.com:8080
                      portal.company.com:8999
                      portal.company.com:37777
                      portal.company.com:21000
                      portal.company.com:8884

                      Ich habe extern ja nur eine öffentliche IP.

                      Die Programme sollen nun aber auch im internen LAN funktionieren und die einstellungen kann ich nicht ändern.

                      Sodass eben oben die Port Weiterleitungen intern auch greifen müssen.
                      angenommen extern habe ich 1.2.3.4, und die pfSense hat intern 192.168.0.254

                      Wie soll sonst der Traffic von 192.168.0.254:8080 zu der internen IP 192.168.0.20:80 kommen?

                      Hoffe es ist nun verständlicher.

                      Danke!

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

                        Okay, das lässt sich mit DNS Overrides nicht realisieren.

                        Dann mach einfach NAT-Reflection, wie in dem Link von @Rico erklärt.
                        NAT Reflection ist nichts anderes, als das dieselben NAT-Regeln vom WAN auch auf den internen Interface angewandt werden, ohne diese anzuzeigen.
                        Damit das innerhalb desselben Subnetzes funktioniert, muss die pfSense quasi als Proxy arbeiten und die Quell-IP in Paketen auf ihre eigene umsetzen. Ergo du siehst die pfSense als Quelle, wenn du die Server-Logs prüfst.
                        Möglicherweise funktioniert das nur mit "NAT + Proxy".

                        Und wie bereits erwähnt, musst du das DNS Override entfernen, denn NAT-Reflection verwendet die WAN-IP in ihren Regeln.

                        U 1 Reply Last reply Reply Quote 1
                        • U
                          unique24 @viragomann
                          last edited by

                          @viragomann
                          ok, aber welche IP soll ich den Clients über den DNS zuweisen?
                          die interne oder externe der pfSense?

                          portal.company.com:8080

                          soll zu
                          192.168.0.254:8080
                          oder
                          1.2.3.4:8080
                          werden?

                          Oder ist das der pfSense egal?

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

                            Die WAN IP.
                            Aber dafür benötigst du ja kein Override! Das ist ja eh im externen / public DNS.
                            Daher habe ich geschrieben "entferne den DNS Override".

                            1 Reply Last reply Reply Quote 1
                            • U
                              unique24
                              last edited by

                              ok, danke, funktioniert!

                              Nun habe ich noch einen Punkt offen.
                              Es gibt 2 Server die nicht über den pfSense Proxy laufen sollen. Das sind vor allem Datei Transfers, usw.

                              Bei diesen sind die externen Ports gleich den internen:

                              odoo.company.com (port 80 und 443) soll nach 192.168.0.202 (80 oder 443, je nach Source)

                              cloud.company.com (port 80 und 443) soll nach 192.168.0.201 (80 oder 443, je nach Source)

                              Hier soll bei der WAN unterschieden werden, welchen FQDN gewählt wurde. Da ja beide den selben Port nutzen.

                              Jedoch intern kann ich den Host Overrides verwenden, richtig?
                              odoo.company.com => 192.168.0.202
                              cloud.company.com => 192.168.0.201

                              dann verbinden diese intern gleich direkt.

                              Aber wie das vom WAN erkennen?

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

                                @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                                Jedoch intern kann ich den Host Overrides verwenden, richtig?
                                odoo.company.com => 192.168.0.202
                                cloud.company.com => 192.168.0.201

                                Ja.

                                @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                                Hier soll bei der WAN unterschieden werden, welchen FQDN gewählt wurde. Da ja beide den selben Port nutzen.

                                Das geht nur mit einem Reverse Proxy.
                                HAProxy wäre das geeignete Paket für die pfSense. Die Einrichtung ist aber nicht ganz trivial.

                                Ich habe eine solche Anfordung in meinem Heimnetz mittels eines Proxymoduls auf einem der Webserver (Apache) gelöst. D.h. dieser Webserver bekommt auf der pfSense alles weitergeleitet und leitet die andere Domain von sich aus auf den zweiten Server weiter.

                                1 Reply Last reply Reply Quote 0
                                • U
                                  unique24
                                  last edited by

                                  Danke,

                                  ich werd mal versuchen dieser Anleitung zu folgen:
                                  https://sysadms.de/2018/10/pfsense-haproxy-als-reverse-proxy/

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

                                    @viragomann said in Internen Traffic über NAT zurück ins LAN leiten:

                                    HAProxy wäre das geeignete Paket für die pfSense. Die Einrichtung ist aber nicht ganz trivial.

                                    Geht, genau für den beschriebenen Fall gibts ein Template in HAproxy das man einfach erstellen lassen und abändern kann.

                                    @unique24 said in Internen Traffic über NAT zurück ins LAN leiten:

                                    Danke,

                                    ich werd mal versuchen dieser Anleitung zu folgen:
                                    https://sysadms.de/2018/10/pfsense-haproxy-als-reverse-proxy/

                                    WARUM sucht ihr euch eignetlich immer alte Tutorials aus dem Internet raus? Ich verstehs nicht. Nur weil bei Google auf Platz 1 oder so? Warum nicht einfach erstmal die eigene Doku nutzen oder die Netgate/pfSense Ressourcen nutzen?

                                    https://www.netgate.com/resources/videos/server-load-balancing-on-pfsense-24.html

                                    Bitteschön :)

                                    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

                                      Kann ha proxy eigentlich auch funktionieren, wenn SNI verschlüsselt ist und kein offloading genutzt wird?

                                      noplanN 1 Reply Last reply Reply Quote 0
                                      • noplanN
                                        noplan @Bob.Dig
                                        last edited by

                                        @Bob-Dig said in Internen Traffic über NAT zurück ins LAN leiten:

                                        Kann ha proxy eigentlich auch funktionieren, wenn SNI verschlüsselt ist und kein offloading genutzt wird?

                                        Hmmmm gute Frage

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

                                          @Bob-Dig said in Internen Traffic über NAT zurück ins LAN leiten:

                                          Kann ha proxy eigentlich auch funktionieren, wenn SNI verschlüsselt ist und kein offloading genutzt wird?

                                          Wenn SNI WIE verschlüsselt ist? Momentan gibt es AFAIK nur eine Variante SNI zu verschlüsseln und das ist ESNI. Wenn die Komponenten ordentlich ESNI sprechen, alle Komponenten APIs aufgerüstet sind und SplitMode ESNI läuft, sollten auch LBs gehen.

                                          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.