Wie versprochen, geht es hier weiter mit HA-Proxy. Ich denke du bist nicht ohne Grund hier  entweder weil du einfach IT-begeistert bist ohne weil dir noch der entscheidende Punkt fehlt um dein Projekt umzusetzen. Wofür und warum HA-Proxy, das ist relativ schnell erklärt.

Wir bedienen uns dem Screenshot aus meinem letzten Beitrag:

Rechts schön zu sehen, habt ihr vllt. mehrere Applikation/Dienste, die Ihr gerne extern zur Verfügung stellen wollt. Klassische Beispiele: Mailserver, Cloud, Hausautomation usw. was man eben so im privaten Bereich benötigt  Problem ist nur, die meisten Sachen kommunizieren über den Port 443. 

Mit einem Dienst, wäre das kein Problem, einfach eine 443 Portforwarding/Weiterleitung auf der Fritzbox/Router einrichten auf die Maschine, die den Dienst inne hat und schon funktioniert das Ganze, aber was, wenn Ihr mehrere Dienste habt, dafür könnt Ihr HA-Proxy verwenden.

Doch zunächst zu den Voraussetzungen.

Grundvoraussetzungen

Domäne

Wie im vorherigen Screenshot zu sehen benötigt Ihr eine Domäne, diese kostet nicht viel und macht es euch mit Subdomänen später einfacher. Sprich für jeden Dienst eine Subdomäne (bspw. mail.euredomaene.de)

Zertifikat

Ein gültiges Zertifikat, hierzu hatte ich im LetsEncrypt-Beitrag beschrieben, was dazu nötig ist und wie Ihr es erstellen könnt.

DynDNS oder feste IP

Bevorzugt wäre eine feste IP. Diese könnt Ihr bei eurem Provider anfragen und meist für einen schmalen Taler bekommen. In meinem Falle habe ich damals einmalig einen 10er bezahlt. Doch zu geizig?  Dann müsst Ihr euch mit einem DynDNS-Account rumschlagen und bei eurem Domänen-Anbieter anstatt einem A-Record ein C-Name auf eure DynDNS-Adresse eintragen.

Portforwarding/Weiterleitung

Nachdem Ihr diese Vorbereitungen getroffen habt, fehlt noch eine Grundvoraussetzung und zwar kommen nun die Pakete/Anfragen bei eurer externen IP an z.B. eurer Fritzbox/Router an, doch die weiß ja nicht, was Sie damit anfangen soll. Vereinfacht dargestellt, Ihr wollt einen Webserver betreiben und kommt mit https:\\www.euredomaene.de an, dann sieht die Fritzbox, alles klar Port 443 aber was soll ich damit tun? Ganz einfach, den Traffic via Port-Forwarding weiterleiten auf die pfSense, denn die weiß später über den konfigurierten HA-Proxy, was damit geschehen soll. 

Bei einer Fritzbox: Internet --> Freigaben --> Freigabe hinzufügen: (die Ports, die Ihr benötigt)

Btw., falls Ihr mit DynDNS arbeiten wollt, dann seht Ihr im gleichen Screenshot oben auch den Registerreiter "DynDNS".

pfSense Voraussetzungen 

Soweit so gut. Ist alles sauber vorbereitet, machen wir uns an die pfSense. Wie immer "meine Empfehlung" macht nach jedem erfolgreichen Schritt ein vollwertiges Backup und vor jedem neuen Test ein Snapshot.

Wie immer, links auf eure pfSense und in der Mitte auf Snapshots.

Falls noch nicht installiert, bekommt Ihr das Paket "haproxy" über System --> Paketverwaltung:

Nach der Installation findet Ihr unter "Dienste" einen neuen Eintrag "HAProxy"

HAProxy Konfiguration

Wie zuvor erwähnt findet Ihr HAProxy nun unter Dienste --> HAProxy

Hier sind eigentlich nur drei Punkte interessant (zugegeben, die anderen habe ich noch nie gebraucht )

• Settings
• Frontend
• Backend

Wobei die Reihenfolge "aus meiner Sicht" eher in umgekehrt Sinn macht, denn ohne Backend könnt Ihr z.B. kein Frontend richtig anlegen.

Aber bleiben wir bei "Settings"

Man glaubt es kaum, hier könnt Ihr über "Enable HAProxy" den Proxy aktivieren  Die Connections müsst Ihr selbst schauen, was Ihr im Schnitt habt, wobei Ihr rechts ein kleines Beispiel seht, wieviel RAM benötigt wird für entsprechende Connections. 

Ich habe aktuell nur 500 angegeben und hatte bisher nie Probleme, nutzt Ihr jedoch die pfSsense in einer Firmenumgebung mit einem Exchange und einigen Leuten, dann werdet Ihr sicher mehr benötigen.

Widmen wir uns dem Reiter "Backend"

Hier legt Ihr eure Maschinen an, die entsprechende Dienste zur Verfügung stellen. Ich werde hier auf zwei Beispiele eingehen: Webserver & Exchange

Betreibt Ihr Zuhause einen Webserver und habt den z.B. Apache in der Default-Konfig, dann lauscht er standardmäßig auf Port 80, d.h. Ihr müsst Ihn so anlegen, wie Ihr ihn "intern" ansprechen würdet. Angenommen ihr würdet ihn intern mit http://10.10.70.127 ansprechen, dann muss er so auch im Backend eingetragen werden! (lasst euch nicht beirren vom Namen "nginx" da kann ein x-beliebiger Name stehen z.B. auch Apache oder sonst was.)

Backend für Webserver

Unten "Health check method" habe ich bisser immer auf "nicht gesetzt" gestellt und speichere das Ganze.

Backend für Exchange

Hier legt Ihr ihn ebenfalls analog zum Webserver an nur mit dem Unterschied, dass dieser auf Port 443 lauscht und müsst zusätzlich noch das Häkchen bei "Encrypt(SSL)" setzen.

Auch hier einfach auf "nicht gesetzt" stellen und speichern.

Habt Ihr nun eure "Backends" angelegt schauen wir uns den Reiter "Frontend" an

Grundsäztlich ist das die "Schnittstelle" sprich "pfSense lauscht auf Ihrer WAN-Schnittstelle, arbeitet mit ACLs zur Steuerung welche Anfrage wohin delegiert wird"

Doch zunächst machen wir es uns etwas "einfacher". Wir legen ein "Shared-Frontend" an. Es funktioniert sozusagen wie das Parent-Child-Prinzip. D.h. Ihr legt einmal diverse Einstellungen an um Sie bei weiteren Frontends nicht erneut vornehmen zu müssen.

Einfach auf "hinzufügen" Name und Beschreibung frei vergeben und natürlich den Status aktiv. Der wichtige Part ist dann die "WAN-Schnittstelle und den Port, der an der WAN-Schnittstelle erwartet wird sowie den Haken bei SSL-Offloading. Diese Punkte würden sich in einigen Frontends wiederholen und können uns mit dem Shared-Frontend zukünftige Konfigurationen sparen.

Wer einen Webserver mit Joomla betreibt (oder vllt. auch grundsäztliche Applikationen, die eine ClientIP und keine stellvertretende IP erwarten) sollte noch den Haken bei "Use forwardfor option" setzen.

Perfekterweise, wenn Ihr ein Wildcard Zertifikat mit LetsEncrypt erstellt habt, könnt Ihr es hier direkt verwenden und funktioniert auf alle Subdomains/Frontends. Die erste Checkbox sollte noch mit gesetzt werden. Hatte ich im Screenshot wohl übersehen.

Soweit so gut, bis hier her habt Ihr schon alles gut vorbereitet und nun kommt die "eigentliche" Arbeit und zwar die Frontends, die verantwortlich sind den Traffic auf die entsprechenden Maschinen zu routen. Das ist jedoch leichter als man denkt 

Ich nutze hierzu wieder meine zwei Beispiele Webserver & Exchange.

Webserver-Frontend

Wie beim SharedFrontend auch, einfach auf den Registereiter "Frontend" und "hinzufügen".

Namen und Beschreibung sind wieder frei zu vergeben, sollten jedoch eindeutig sein.

Anders wie beim SharedFrontend müsst Ihr jetzt die dort getätigen Konfigurationen nicht erneut durchführen sondern setzen den Haken bei "Shared Frontend" und könnt euer erstelltes Frontend unten im Dropdown auswählen.

Danach kommt der spannende Part und zwar die "Erkennungsregel, auf die später reagiert werden soll". Schauen wir uns den Abschnitt "Access Control List" an.

Der Name kann frei vergeben werden, sollte jedoch nachvollziehbar für euch sein! Bei Expressions könnt Ihr angeben, was die Voraussetzung ist z.B. "Host Contains", gerade bei Webservern wird die anführende URL (sprich Domäne) immer gleich sein, jedoch verändert sich der Pfad am Ende je nach angesurfter Seite. Daher wäre "Host matches" hier fehl am Platz! Anschließend noch die Value, die eben vorhanden sein soll. (im Screenshot seht Ihr cloud.euredomaene.de, es wäre natürlich sinniger wenn dort www.euredomaene.de drin stehen würde.)

Im Abschnitt "Aktionen" müsst Ihr angeben, was passieren soll, wenn die ACL zutrifft. D.h Ihr müsst im Dropdown in diesem Fall "Backend" auswählen und hinten dann die zutreffende "ACL" (muss natürlich den gleichen Namen haben wie im Abschnitt Access Control List) und dann entsprechend das zuvor von euch erstellte Backend, in dem Falle "Webserver"

Exchange Frontend

Analog zum Webserver oben die gleichen Einstellungen mit eigenem Namen natürlich und unten könnt Ihr genau genommen einfach spicken 

Es müssen hierfür 2 ACLs angelegt werden. Meine empfohlene Einstellungen:

Im unteren Bereich müsst Ihr das Ganze natürlich in der "Aktion" hinterlegen, einfach die ACLs mit einem Leerzeichen getrennt hintereinander schreiben. Als Backend natürlich euren Exchange-Server.

Da Ihr in der Regel sicher nicht nur "mail.euredomaene.de" habt sondern auch "autodiscover.euredomaene.de" müsst Ihr es dazu natürlich auch passend einrichten!

Firewall-Regel erstellen

Nachdem wir alles konfiguriert haben, bleibt eignetlich nur noch ein Punkt offen, die Firwall-Regel!

Aktuell wird alles geblockt, was von außen kommt, was ja auch gut so ist! Allerdings soll ja nun die pfSense den Traffic von außen nach innen entsprechend seine Port/Dienst steuern. Wir müssen also den eingehenden Traffic zulassen z.B. wie nachfolgende Regel:

Ihr braucht euch hier auch keine Sorgen zu machen, denn die Firewall lässt sich zwar von Port 443 konfigurieren, wenn wir aber HAProxy aktiv haben und eben auf Port 443 lauschen um den Traffi eben entsprechend weiter zu leitern, dann kann die Firewall selbst ja nicht mehr über diesen Port (von der WAN-Seite) konfiguriert werden, was sie sowieso nicht sollte! 

HTTP Traffic zu HTTPS umleiten

Eine Kleinigkeit noch zu HAProxy, sofern dies jemand so möchte. Angenommen Ihr betreibt einen Webserver und irgend jemand da draussen tippt in der Browser-Adresszeile: http://www.euredomaene.de, dann wird er relativ schnell merken, dass er darunter keine Verbindung aufbauen kann, da Ihr letzendlich nur auf Port 443 aktuell lauscht!

Wer dem Surfer somit die Möglichkeit schaffen möchte, dass er trotzdem auf euren Webserver kommt, kann den Traffic umleiten und verwendet am Ende dann doch wiederum eine sichere Verbindung mit eurem Zertifikat.

Einfach ein weiteres Frontend anlegen und lauscht auf der WAN-Schnittstelle auf Port 80 (setzt natürlich voraus, dass die Fritzbox auch diesen Port auf die Firewall weiter leitet!)

Wichtig ist der Part bei "Aktion" hier:

Und schon wird jeglicher Traffic, der auf Port 80 rein kommt umgeleitet auf Port 443!

Dann viel Erfolg beim Nachbauen