Downgrade to one WAN (only) with two LANs (subnets) and one webserver per LAN



  • Hi all

    Having two WANs (one ext. IP each) and two LANs (one webserver with its own domain each), pfSense is working fine with four (4) physical GBIT ethernet interfaces: WAN1 (ext. IP1) => LAN1 (webserver example1.com) and WAN2 (ext. IP2) => LAN2 (webserver example2.com). I'm very happy for that solution.

    Current configuration

    WAN1 (ext. IP1) => LAN1 (domain example1.com)
    WAN2 (ext. IP2) => LAN2 (domain example2.com)

    Now, I'm sad to say that I have to downgrade to one WAN (one ext. IP with one WAN only), but having still two LANs (one webserver with its own domain each). How can I map two domains (example1.com and example2.com) to the same WAN IP so that the traffic for domain example1.com goes to LAN1 and the traffic for domain example2.com goes to LAN2?

    New Solution

    WAN (only one IP) => LAN1 (if traffic for domain example1.com)
    WAN (only one IP) => LAN2 (if traffic for domain example2.com)

    Is there a new solution with the same pfSense-HW/SW solution, or do I need to change things on webservers, such as defining virtual hosts etc. ? For example: one WAN => one LAN (with two virtual hosts/two virtual webservers)?

    Sorry for my English! Thanks in advance for your help.
    Regards,

    LAVenetz



  • Sorry for my English! Thanks in advance for your help.

    This is the german part of the forum so you can write in german if you want so.
    Or look for other languages.

    With an reverse proxy like squid you can do want you want to do.
    Forward different URL's to different servers.
    Squid is available as a package for PfSense.
    There are many documentations about that here in the forum or in the internet.


  • LAYER 8 Moderator

    I'd recommend to move that topic to HaProxy or Squid Proxy forums - or we switch answers to german. Depends on what you want :)



  • Squid3 sollte es schon sein nur der hat den reverse Proxy so weit ich weiß.
    Ansonsten
    https://www.google.de/search?q=pfsense&ie=utf-8&oe=utf-8&gws_rd=cr&ei=PROrVvqfOYfxapKXs9gD#safe=off&q=pfsense+reverse+proxy
    und hier im Forum suchen. Gibt es genug.
    Was die besten Anleitung ist muss jeder für sich selbst entscheiden :) hängt ja auch vom Vorwissen ab.




  • LAYER 8 Moderator

    Ja HAProxy kann prinzipiell auch bei TLS mittels SNI mehrere Domains auf tcp/443 auf verschiedene Backends durchreichen. Kommt darauf an ob er TLS Offloading macht oder ob er das ganze nur weiterreicht, je nachdem wie man möchte, gehen tut prinzipiell beides.


  • LAYER 8 Moderator

    Also das WAN2/LAN2-Paar ist obsolet und der Firewall kann das nicht mehr ohne drastische Massnahmen handeln?!?

    Definiere drastische Maßnahmen ;)

    Nun muss/müsste der HPProxy (o.ä.) über diese eine dyn.IP doch eigentlich nur anhand des HTTP/HTTPS-Trafics in HTTP-Anfrage Header feststellen, ob er entweder an den physischen Webserver1 www.example1.com oder an den anderen physischen Webserver2 www.example2.com weiterleiten soll.

    Etwas ausschweifend beschrieben, aber ja. Beide Domainnamen werden auf die gleiche dynamische IP konfiguriert und zeigen daher auf WAN(1). Dort lauscht dann HAProxy auf 80/443 (je nach Wunsch) und leitet weiter auf die konfigurierten Backends.

    Kommt das ganze Desaster mit dem Offload jetzt deswegen ins Spiel, weil bei verschlüsselten HTTP-Anfragen der Firewall nicht ohne Offload "sieht", an welchen Webserver die Anfrage geht?

    Moooment, jetzt werfen wir aber munter Dinge durcheinander. Ich hatte lediglich angemerkt, dass die Konfiguration lediglich an der Stelle bei HAproxy unterschiedlich ist, wenn man SSL offloaden möchte oder nicht. Das KANN man machen MUSS man aber nicht. Da gehts um mehrere Dinge wie Security, Standards, Capabilities der Backends etc.
    Beispiel: Dein Backend Webserver kann vielleicht gar kein HTTPS. Dann kann man HTTPS offloaden in HAProxy und der Client kann via HTTPS connecten, da die Verbindung bei HAproxy terminiert wird und HAproxy dann selbst unencrypted mit dem Webserver spricht - was aber egal ist, da dieser Verbindung ja vertraut wird.
    Oder ebenso beliebt: Der Webserver ist älteren Datums und kann nicht geupdated werden, unterstützt aber nur alte Chiffren und Cipher und ist daher nicht wirklich sicher. Auch hier kann HAproxy dann einspringen und die Verbindung terminieren. Ob er dann selbst https oder http mit dem Backend spricht ist hier dann nebensächlich.
    Oder auch: Webservice ist bspw. Java. Java und SSL sind unschöne Themen (Java SSL/TLS Keystore meh).

    Ich dachte immer, dass selbst bei HTTPS-Anfragen im TC/IP Header die URL sichtbar ist. Wozu denn das Ganze? Wäre froh, wenn mir jemand diese prinzipielle Frage beantworten könnte. Danke.

    Ui, HTTP(S) hat als Protokoll jetzt aber nicht wirklich was mit TCP/IP zu tun. ;) Das ist ne andere Schicht :) Und ja, bei HTTPS bzw. bei TLS wurde - einfach ausgedrückt - ein Header ergänzt (server_name) in welchem der Client dem Host mitteilen kann, welchen VHost er auf dem angegebenen Server denn versucht zu erreichen, damit dieser den entsprechenden Host und das zugehörige Zertifikat ausliefern kann. Ohne SNI ist daher bei TLS/SSL Verbindungen pro IP nur ein verschlüsselter Dienst möglich (gewesen). Da HTTPS die Verbindung ja komplett verschlüsselt, war für den Server nicht ersichtlich für welchen VHost die Anfrage ist, deshalb ging damals nur einer (der default VHost). Erst durch einführen des Feldes (server_name) welches ebenfalls nicht verschlüsselt vom Client mitgeschickt wird, klappt das. Deshalb muss es der Client wie Server unterstützten.

    Grüße :)


  • LAYER 8 Moderator

    Hallo DisasterVictim,

    dass keine einzige Anleitung - wie du sagst - passen soll, wage ich jetzt mal grob zu bezweifeln, verweise aber ansonsten auch gern an das HAproxy Forum bzw. das Mod/Addon Forum und an die Doku hier: https://doc.pfsense.org/index.php/Haproxy_package

    Was du als Kleinigkeit bezeichnest ist einfach ein Einsatzzweck, für den du nunmal eben Spezialsoftware wie Squid oder HAproxy brauchst! Du hast eben nur noch eine IP anstatt mehrere für multiple physikalische Server. Also muss der Zugriff von außen über einen Proxy laufen. Punkt. Nein es geht nicht anders, es sei denn du kannst "dreckige" Lösungen via andere Ports benutzen, dann würde dir an dieser Stelle ein einfaches Portforwarding ausreichen (Port 8081 bspw. auf Port 80 Server 1, Port 8082 auf Port 80 Server 2 o.ä.).
    Wenn du das einfach "nur" via Domain Header bzw. URL lösen willst, muss man eben auf Proxys zurückgreifen. pfSense bietet dafür die genannten zwei Pakete an, die diese Proxy Funktionalität enthalten. Ob du das empfindest, als würdest du mit Kanonen auf Spatzen schießen mag dir gegönnt sein, ich sehe in haproxy bspw. keine "Killeranwendung" die Gigabyteweise RAM oder Prozessorlast erzeugt. Natürlich kann ein Proxy noch um ein vielfaches mehr.

    Ob du nun deine jüngste Entdeckung Pound, die noch dazu kein unterstütztes Paket für pfSense bietet, noch ins Rennen wirfst bleibt dir überlassen, für mich macht es keinen Sinn. Diesen Dienst müsstest du aus FreeBSD Quellen selbst installieren und händisch konfigurieren. Gleichzeitig sagst du aber, dass die vorhandenen Lösungen mit GUI Unterstützung zu komplex sind. Da frage ich mich dann doch, wo du mit deiner Lösung eigentlich hin willst. Anstatt nach deiner letzten Nachricht (Testumgebung, melde mich) nochmals nachzufragen, wo es ggf. Probleme bei Squid oder Haproxy gibt (was auch immer du getestet hast), wo wir dir hätten ggf. (weiter)helfen oder auf den richtigen Weg bringen, schreibst du einen kleinen Rant (den ich zwar durchaus generell verstehe aber in deinem Problemfall nicht nachvollziehen kann) und kommst mit einem neuen Tool das potentiell keiner kennt, da es dieses für die Plattform nicht nativ gibt.

    Wäre es möglich, dass du uns erst einmal mitteilst, was angeblich alles nicht funktioniert hat mit den anderen überkomplexen Lösungen? Ich habe bspw. hier schon mind. 3x anderen Probanden HAproxy empfohlen, die ein sehr ähnliches Setup wie du erstellen wollten, und keiner hatte solch riesigen Probleme. Zudem nutze ich haproxy bei einigen Kunden ebenfalls. Wo also hast du Probleme wo dir jemand weiterhelfen kann? Deine letzte Textwand hilft uns zumindest nicht, DIR zu helfen.

    Gruß Jens


  • LAYER 8 Moderator

    Und kurz noch als Anhang bzgl. überkomplex und Kanonen auf Spatzen: Gerade in einer pfsense 2.3 Testumgebung OHNE irgendwelche Doku das Paket "haproxy" installiert und dann in der GUI aufgerufen. Hier gibt es nun neu "Templates", mit denen schon einige Anwendungsfälle vorgestellt und vorkonfiguriert werden. Und was finden wir?

    -> Serving multiple domains from 1 frontend
    Create configuration?

    Damit habe ich zumindest gerade ohne großes konfigurieren 3 Frontends und 3 Backends konfiguriert bekommen, die einem zumindest die grobe Vorstellung vermitteln, warum und was wo konfiguriert wurde. Als Startpunkt um das für sich ans Laufen zu bekommen sollte doch das nicht verkehrt sein? Und ansonsten darf man gerne fragen.


Log in to reply