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

    HA-Proxy & ACME, wie läuft die Verbindung

    Scheduled Pinned Locked Moved Deutsch
    15 Posts 4 Posters 1.3k 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.
    • P
      pixel24
      last edited by

      Ja, ich denke so hatte ich es auch immer verstanden. Mein interner Groupwareserver auf welchen ich per HTTPS / 443 zugreifen möchte hat intern die 192.168.xx.6 und den FQH com01.intern.lan. Für dieses Dienst habe ich auf dem externen Webserver welcher die Domain (meinedomain.de) verwaltet eine Subdomain gw.meinedomain.de eingerichtet und den A-Record auf die WAN-IP (feste) der pfSense gesetzt. Der HA-Proxy löst die ankommende Anfrage auf https://gw.meinedomain.de auf und leitet sie auf 192.168.xx.6.

      Da ich mehrere Hosts im LAN habe die über HTTPS/444 von extern erreichbar sein sollen habe ich dieses Szenario mit mehren Subdomains wiederholt. Das würde mit einer Portweiterleitung ja so nicht funktionieren.

      Ich dachte immer das NAT-Reflection nun dafür verantwortlich ist dass ich vom internen LAN aus den Dienst ebenfalls unter https://gw.meinedomain.de ansprechen kann anstatt über https://com01.intern.lan

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

        @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

        Da ich mehrere Hosts im LAN habe die über HTTPS/444 von extern erreichbar sein sollen habe ich dieses Szenario mit mehren Subdomains wiederholt. Das würde mit einer Portweiterleitung ja so nicht funktionieren.

        Vermute du meinst 443 :)

        Das würde mit einer Portweiterleitung ja so nicht funktionieren.

        Richtig, ein PortForward kann nur IP weiterleiten, aber nicht differenzieren.

        @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

        Ich dachte immer das NAT-Reflection nun dafür verantwortlich ist dass ich vom internen LAN aus den Dienst ebenfalls unter https://gw.meinedomain.de ansprechen kann anstatt über https://com01.intern.lan

        Das ist auch umgangssprachlich so. Da gehts aber nicht direkt um NAT oder nicht, sondern um Regellogik. Dein Portforward von extern gilt normalerweise NUR GENAU auf dem WAN wenn etwas von extern auf die externe IP ankommt und wird - ebenfalls NUR dann - nach innen geschickt. Kommt dein Client von innen jetzt mit der externen IP, landet er auf der Sense, auf dem äußeren Interface und ... ja versauert da. Denn der Forward ist ja auf dem WAN definiert und nicht auf dem LAN. Du kommst dann aber vom LAN.

        NAT Reflection fügt nun quasi jedem Port Forwarding automatisch noch weitere Regeln zu, die von allen anderen Interfaces aus weitere Redirects machen auf die entsprechende interne IP. Damit bekommt der Request dann die richtige Richtig. Prinzipiell könntest du die Regel selbst bauen und 1:1 die gleiche Regel wie mit dem WAN Interface nochmal bauen fürs LAN - dann hättest du dir manuell den Forward quasi gebaut.

        Ob du intern den Dienst über deine externe Domain oder nicht ansprechen kannst liegt übrigens überhaupt nicht bei NAT, sondern beim DNS ;) Wenn du intern deinen DNS Resolver von der sense nutzt und dir dann dort einen Host Override für dein gw.meinedomain.de auf die interne IP setzt (man spricht von Split DNS weil du dann intern eine andere Antwort als extern erhältst) brauchst du auch kein NAT Reflection, sondern kommst ohne durch und baust die Verbindung direkt mit dem richtigen System ohne 3-Ecken dazwischen auf :)

        Cheers

        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.

        P 1 Reply Last reply Reply Quote 1
        • P
          pixel24 @JeGr
          last edited by

          @jegr said in HA-Proxy & ACME, wie läuft die Verbindung:

          Vermute du meinst 443 :)

          Jeb ✌

          @jegr said in HA-Proxy & ACME, wie läuft die Verbindung:

          NAT Reflection fügt nun quasi jedem Port Forwarding automatisch noch weitere Regeln zu, die von allen anderen Interfaces aus weitere Redirects machen auf die entsprechende interne IP. Damit bekommt der Request dann die richtige Richtig. Prinzipiell könntest du die Regel selbst bauen und 1:1 die gleiche Regel wie mit dem WAN Interface nochmal bauen fürs LAN - dann hättest du dir manuell den Forward quasi gebaut.

          Ja ok, verstanden ... zumindest hoffe ich das.

          @jegr said in HA-Proxy & ACME, wie läuft die Verbindung:

          Ob du intern den Dienst über deine externe Domain oder nicht ansprechen kannst liegt übrigens überhaupt nicht bei NAT, sondern beim DNS ;) Wenn du intern deinen DNS Resolver von der sense nutzt und dir dann dort einen Host Override für dein gw.meinedomain.de auf die interne IP setzt (man spricht von Split DNS weil du dann intern eine andere Antwort als extern erhältst) brauchst du auch kein NAT Reflection, sondern kommst ohne durch und baust die Verbindung direkt mit dem richtigen System ohne 3-Ecken dazwischen auf :)

          Ja, hier tun sich dann ernsthafte Wissenslücken auf die es zu schließen gilt. Wie ich intern den DNS Resolver von der pfSense nutze kann ich nur vermuten :-( Ich konfiguriere am lokalen DNS-Server (Univention) die pfSense als "externer DNS" ?

          with best

          JeGrJ 1 Reply Last reply Reply Quote 0
          • P
            pixel24
            last edited by

            This post is deleted!
            1 Reply Last reply Reply Quote 0
            • P
              pixel24
              last edited by pixel24

              Ich denke ich muss mich zuerst mit dem Thema DNS beschäftige und nachfolgend mit HA-Proxy.

              Ich habe hier eine Testumgebung und eine frisch installierte pfSense.

              Ebenfalls habe ich das Handbuch zum Thema konsultiert.

              Während der Installation bzw. dem nach-gelagerten Setup habe ich als Domain mein lokale Domain 'intern.lan' sowie den dafür zuständigen lokalen DNS-Server (UCS-Server) mit seiner IP '192.168.xx.5' konfiguriert. Zusätzlich habe ich noch einen DNS vom Provider (Vodafone) als Secondary DNS Server: 80.69.100.230 gesetzt.

              Per Default ist der DNS-Resolver der pfSense ja im 'Resolver mode' um Problemen mit nicht vorhanden oder falsch konfigurierten loaklen DNS-Servern vorzubeugen. Wenn ich das Handbuch hier richtig interpretiere ist es sinnvoll unter: Dienste -> DNS-Weiterleitung den 'Forward Mode' zu aktivieren. Vorher den REsolver-Mode deaktivieren

              Hier habe ich ebenfalls eine Host-Überschreibung hinzugefügt:

              Host:       gw
              Domäne:     meinedomain.de
              IP:         192.168.xx.6
              

              Wenn ich nun von einem Client im Testlan:

              dig gw.meinedomain.de
              

              erhalte ich vom lokal DNS die LAN-IP mit externem Domain-Suffix, also:

              gw.meinedomain.de    192.168.xx.6
              

              Das schein nun also korrekt zu sein wenn ich es soweit richtig verstanden. habe

              Beste Grüße
              pixel24

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

                @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

                Ja, hier tun sich dann ernsthafte Wissenslücken auf die es zu schließen gilt. Wie ich intern den DNS Resolver von der pfSense nutze kann ich nur vermuten :-( Ich konfiguriere am lokalen DNS-Server (Univention) die pfSense als "externer DNS" ?

                Warum "externer DNS"? Jeder Rechner braucht nen DNS. Welchen du einträgst liegt an dir. Wenn du ne interne DNS Zone aufbauen willst weil mehrere Geräte macht es Sinn einen internen DNS zu führen/füttern. Das kann man mit dem DNS der Sense problemlos machen.

                Und da der caching etc. macht, macht es ja Sinn wenn alle internen Clients ihr DNS nicht einfach in die Welt rauströten, sondern das an die pfSense schicken, die das dann für sie auflöst (resolver mode, nicht forwarding mode) und ihnen antwortet. Als Edge Device direkt am Rand des lokalen Netzes zum Internet macht das am meisten Sinn.

                Und wenn alle internen Kisten dann eh die Sense als DNS haben, kann man dort dann auch problemlos DNS Einträge überschreiben oder via DNS Blocklisting mit pfBlockerNG bspw. eben rausblocken (Werbeblocking, Porn-Filter, etc. blah) :)

                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
                • JeGrJ
                  JeGr LAYER 8 Moderator @pixel24
                  last edited by

                  @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

                  Dienste -> DNS-Weiterleitung den 'Forward Mode' zu aktivieren. Vorher den REsolver-Mode deaktivieren

                  Nein. Warum solltest du das?

                  @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

                  Per Default ist der DNS-Resolver der pfSense ja im 'Resolver mode' um Problemen mit nicht vorhanden oder falsch konfigurierten loaklen DNS-Servern vorzubeugen.

                  Und weil es einfach Sinn macht DNS ordentlich zu "resolven" statt stumpf zu forwarden? :)

                  @pixel24 said in HA-Proxy & ACME, wie läuft die Verbindung:

                  Während der Installation bzw. dem nach-gelagerten Setup habe ich als Domain mein lokale Domain 'intern.lan' sowie den dafür zuständigen lokalen DNS-Server (UCS-Server) mit seiner IP '192.168.xx.5' konfiguriert. Zusätzlich habe ich noch einen DNS vom Provider (Vodafone) als Secondary DNS Server: 80.69.100.230 gesetzt.

                  Das macht für mich keinen Sinn. Warum sollte die pfSense einen Server "hinter" ihr im LAN für DNS fragen, der dann wieder im Netz nach DNS fragt? Das ist doch Ping-Pong?
                  Und als 2. DNS einen Provider Server (die notorisch anfällig sind mal nicht zu laufen) der deine interne Domain nicht kennt zu nutzen bringt auch eher wenig :)

                  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.

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

                    Zum Thema DNS Hiearchie siehe auch

                    https://forum.netgate.com/post/1023560

                    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
                    • P
                      pixel24
                      last edited by

                      Ok, den Forward-Mode deaktiviert und dort die Host-Überschreibung gelöscht. Den Resolver-Mode wieder aktiviert und dort die Host-Überschreibung hinzugefügt.

                      In den Allgemeinen Einstellungen die beiden DNS-Server entfernt.

                      Mit dig vom Client aus die gw.meinedomain.de abegfragt. Als Ergebnis erhalte ich die LAN-IP.

                      So sollte es nun passen

                      1 Reply Last reply Reply Quote 0
                      • P
                        pixel24
                        last edited by

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