PfSense - Neuling: HTTPS Port auf mehrere Clients weiterleiten



  • Hallo Zusammen,

    Ich möchte eine Port-Weiterleitung zu entsprechenden Clients anhand der Anfrage einrichten:
    Öffnet jemand https://cloud.contoso.com, wird er auf den internen Client https://192.168.1.5 umgeleitet. Öffnet jemand aber https://mail.contoso.com, soll er auf https://192.168.1.10 umgeleitet werden. Ist dies Firewall-technisch lösbar?

    Besten Dank und liebe Grüsse


  • Banned

    Wenn es um LAN Klienten geht nennt sich das "Host Override" und ist teil des DNS. Für WAN brauchst du da was in der Richtung von HAProxy, das geht aber nur für Protokolle die die Ziel URL mit übermitteln wie z.B. HTTP/S. Höchste Zeit für RTFM.



  • Salü Grimson,

    Vielen Dank für deine Antwort. Im LAN (via DNS) ist mir klar, danke. Dass dies per WAN nur bei Protokollen wie HTTP oder HTTP/S funktioniert, ist mir ebenfalls klar.
    Nur eben HAProxy sagt mir überhaupt nichts, weshalb ich mir überlegt habe, ob dies die Firewall evtl. kann. Deiner Antwort entnehme ich, dass die Firewall dies (zumindest Standardmässig nicht kann, aber gem. Dr. Google gibt es ein HAProxy Package, über welches ich mich doch gerne einmal schlaue mache.

    Meinst du, im Manual wäre eine solche spezifische Frage auch für Neulinge ersichtlich?

    Besten Dank für deine Hilfe & deine von dir aufgewendete Zeit

    Liebe Grüsse

    Wuschy




  • Rebel Alliance Moderator

    Zudem hat das HAProxy Package auf der pfSense auch noch einen schönen Template Fall mit "mehrere Domains auf gleichem Frontend (IP) auf mehrere Backends verteilen". Das kann man laden, anschauen, verstehen, anpassen und es nutzen (hinterher natürlich freuen) :)

    Grüße



  • Vielen Dank für alle Antworten, hat schlussendlich auch geklappt (bis auf etwas).

    Bei den HTTP Verteilungen funktioniert alles tadellos. Die HTTPS Verteilungen funktionieren soweit eigentlich auch, nur scheint mir ein Backend einen Strich durch die Rechnung zu machen (drei weitere laufen einwandfrei):
    Ein Backend wird in den Stats als UP (grün) angezeigt, jedoch nur, wenn ich beim Check statt OPTIONS GET oder HEAD auswähle. Die Weiterleitung funktioniert dann wahrscheinlich (Daten kommen rein), aber der Host scheint nicht zu antworten (keine Daten gehen raus). Intern läuft alles einwandfrei, wenn ich eine NAT Weiterleitung (auf einem anderen Port) mache, funktioniert es ebenfalls. Da das Problem offensichtlich beim Host im Hintergrund liegt (OpenSuSe) wäre die Frage, wie ich die Verbindungsfehler, welche mir die Stats ausgeben, prüfen kann?

    Aus dem Manual (weder Management Manual noch Starter) finde ich hierzu brauchbare Hilfe. Dr. Google hat mir bisher lediglich mal ausgespuckt, dass es Schwierigkeiten geben könnte, wenn ich einen Docker Container betreibe, was bei mir der Fall ist… hat jemand damit schon Erfahrungen?
    Anbei ein Screenshot der Stats



  • Rebel Alliance Moderator

    Es sollte kein Problem sein, als Check mit HEAD zu agieren, machen viele kommerzielle LBs auf Basis von HAProxy auch, da OPTIONS bspw. auch mal gern je nach Server gesperrt ist um Information Leaks zu minimieren. Im Prinzip würde auch ein tumber Ping erstmal reichen, auch wenn der keine Aussagekraft hat, ob der Service da ist, da gehts nur darum, dass HAProxy das Backend überhaupt UP hat und die Daten zustellt.

    Ansonsten ist es - wenn keine Daten zurückkommen - allermeistens ein Konfigurationsproblem auf dem Webserver selbst. Der muss ja via SNI auf den entsprechenden Domainnamen hören und Daten liefern. Tut er das nicht, wirds auch über HAProxy nicht klappen. Hast du mal lokal bspw. mit einer angepassten HOSTS Datei auf deinem eigenen Rechner geschaut, ob der Server direkt mit Namen auch funktioniert (also ohne Proxy)?



  • Vielen Dank, ja ich sehe schon, dass es ein WebServer Problem ist… intern funktioniert, wie erwähnt alles ohne Probleme, extern mit einer NAT Weiterleitung ebenso, nur über den HA Proxy nicht. Aber habe eben die Anleitung von ownCloud zu Rate gezogen, ich müsste da den Proxy eintragen, damit das klappt:

    https://doc.owncloud.org/server/9.0/ownCloud_Server_Administration_Manual.pdf
    5.16.1  Defining Trusted Proxies
    For security, you must explicitly define the proxy servers that ownCloud is to trust. Connections from trusted proxies
    will  be  specially  treated  to  get  the  real  client  information,  for  use  in  access  control  and  logging.  Parameters  are
    configured in
    config/config.php
    Set the
    trusted_proxies
    parameter as an array of IP address to define the servers ownCloud should trust as proxies.
    This parameter provides protection against client spoofing, and you should secure those servers as you would your
    ownCloud server.
    A reverse proxy can define HTTP headers with the original client IP address, and ownCloud can use those headers
    to retrieve that IP address.  ownCloud uses the de-facto standard header ‘X-Forwarded-For’ by default, but this can
    be configured with the
    forwarded_for_headers
    parameter.  This parameter is an array of PHP lookup strings,  for
    example ‘X-Forwarded-For’ becomes ‘HTTP_X_FORWARDED_FOR’. Incorrectly setting this parameter may allow
    clients to spoof their IP address as visible to ownCloud, even when going through the trusted proxy! The correct value
    for this parameter is dependent on your proxy software.

    Momentan klappt es noch nicht, aber ich probiere noch etwas rum :)

    Auf jeden Fall ist das primäre / Thread Problem gelöst, vielen herzlichen Dank an alle :D


Log in to reply