[SOLVED] Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense
-
Zur Statischen Route.
Als Gateway kann ich die FB WAN IP (also sozusagen von der TAE Dose aus) und auch den localhost angeben. Der localhost ist in dem Fall ja die Firewall selbst. Der Weg über die FB WAN IP dürfte vermutlich ein massiver Security Breach sein, wenn die Firewall dann quasi umgangen(?) würde?
Also als Gateway den Localhost. Ich lese mich kurz in die statische Route ein. Mein Bedenken ist jetzt aktuell, dass damit sämtlicher LAN-Traffic einfach nur "an der pfSense vorbei" geleitet würde. Wahrscheinlich liege ich damit falsch. Ich lese mich mal kurz ein.
EDIT
Eben eingelesen. Mea Culpa! Nach dem was ich gelesen habe ist mir sofort eingefallen, dass in einigen Packet Captures oben ja zu sehen war, dass die pfSense versucht 10.SER.VER.IP zu erreichen bzw das Port Forwarding "ausgeführt" hat.
Aktuell ist das grad eine gute Chance, dass es danach klappt :-)Ich versuche es jetzt mit Localhost. Dadurch sollte die pfSense so wie ich das verstehe ja weiter zwischen den beiden bleiben und nur ihre eigene Route zu 10.XXX.XXX.SRV definiert bekommen.
-
@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:
auf derpfSense ist überhaupt keine statische Route eingerichtet...ich werde das gleich mal ausprobieren!
Dies ist nötig, wenn du den Server IP als Ziel in der NAT Regel verwendest, denn die pfSense kennt das Netz nicht. So leitet es Anfragen dahin an ihr Default Gateway.
Alternativ könntest du auch eine NAT-Stufe dazu geben: au der pfSense als NAT-Ziel die IP des OpenWRT und auf diesem wieder eine NAT-Regel.Um die statische Route einzurichten, muss erst die IP des OpenWRT als Gateway eingerichtet werden in System > Routing > Gateways
Dann kannst du eine Route anlegen für das Netz hinter dem OpenWRT und das erst angelegte Gateway auswählen. -
Nachdem ich mich eingelesen hab klingt das auch logisch.
Also ich habe jetzt ein Gateway eingerichtet und eine statische Route von dem Gateway in das Subnetz angelegt.Gateway:
Static Route:
Beim Gateway habe ich beide Varianten probiert, sprich einmal auf die IP des NICs der pfSense und einmal auf die IP des NICs des OpenWRT.
Die Static Route verweist auf die IP des WAN NIC vom OpenWRT Router.
Bisher funktioniert es nicht, logisch klingt das mit der statischen Routingtabelle für mich jetzt aber. Ich schließe mal den Browser um auszuschließen dass es an irgendwelchen Cachings liegt...
-
Du brauchst deine internen IPs nicht zu verschleiern, die kann hier ohnehin niemand erreichen.
Ein Gateway ist in der Netzwerktechnik ein Gerät (die IP des Geräts), das ein Tor zu einem anderen Netz(werksegment) darstellt.
Ein auf einem Geräte verwendetes Gateway muss also immer die (erreichbare) IP eines anderen Geräts sein. Mit erreichbar meine ich hier, dass die IP innerhalb eines auf einem Interface definierten Subnetzes liegen muss (aber anderenfalls beklagt sich die pfSense ohnehin).Die Route sollte so passen.
Du kannst jetzt noch ein Packet Capture am LAN-Interface machen, um dich zu vergewissern, dass die Pakete da auch raus gehen. Wenn ja, was ich vermute, ist die pfSense draußen. D.h., du musst am OpenWRT weitersuchen. Dabei kann ich nicht mehr helfen, ich kenne die SW nicht.
-
Irgendwie ist da der Wurm drin.
Snort ist gestoppt, die Firewall States alle resetted und der Browser Cache löscht sich beim Beenden selbst.
Gateway für LAN ist angelegt, Statische Route auf das Subnetz hinter dem OpenWRT Router mit einer /24er Maske eingerichtet.
Unter "NAT" "Port Forward" habe ich nach eben unter "NAT Reflection" noch "system default", "Pure NAT", "NAT + Proxy" sowie auf gut Glück einfach mal "disabled" (no NAT) ausprobiert. [ zurück auf "System Default" gestellt ]Zugriff ist trotzdem nicht möglich.
Ich glaub, ich mach für heute Schluss. Mir raucht der Kopf und der Wecker klingelt auch schon in 6 Stunden wieder... Jetzt sitze ich hier geschlagene zwei Abende dran, und am Ende wird es irgendwas ganz komisches, wahrscheinlich völlig logisches und doch nicht bemerktes gewesen sein. Wäre ja sonst wahrscheinlich auch einfach zu langweilig...
-
Stimmt, das habe ich vergessen. Noch ein Packet Capture durchzuführen meine ich. Mache ich mal direkt.
Was mir noch eingefallen ist... Wenn Port 80 weiterhin geschlossen sein sollte, könnte das daran liegen dass es das Paket nicht an den WebServer weiterreichen kann und daher quasi nach dem ersten Zustellversuch "dropped" bzw es nach außen so aussieht, dass der Port geschlossen wäre? Oder würde der Port dann schon direkt als offen erkannt werden? Ich vermute nicht, da sie ja nicht die Pakete ablehnen, sondern vermutlich einfach nur verwerfen und loggen dürfte?
Wenn es so sein könnte, hieße das weitergedacht ja unter Umständen, dass das Paket an Port 80 angenommen wird, versucht wird weiterzuleiten, das nicht gelingt und daher die Pakete zwar ankommen, aber da von der IP des Port Forwards keine Antworten kommen die Netzwerkscanner die Pakete als "verworfen / dropped" beurteilen?
Das ist sicher ein wenig um die Ecke gedacht und mag falschen Annahmen von mir geschuldet sein, aber wenn es so wäre hieße das ja uU tatsächlich, dass das Problem nicht ein geschlossener Port auf der pfSense, sondern dann eben das nicht weiterleiten oder auch nicht annehmen auf lokaler Ebene (OpenWRT oder Server) sein könnte.Bisher steht (für mich) nur eines fest:
Ich muss definitiv noch so einiges mehr über Netzwerke lernen.Bis hierher schonmal definitiv Danke @viragomann
-
So, kurze Rückmeldung. Es funktioniert. Und ich hab die Nacht durchgemacht...
Es waren multiple Misskonfigurationen vorhanden...
Ich mache es kurz.
-
in OpenWRT sind Portweiterleitungen von der GUI wohl entweder nicht zu machen oder zumindest wirkungslos.
1.1) ich habe mich über SSH in den OpenWRT Router eingelogged und die Portweiterleitung ("config redirect" - "DNAT") manuell angelegt in der /etc/config/firewall angelegt, zusätzlich habe ich noch die beiden zuvor erstellten Traffic Rules ("config rule" - "accept") als Anweisung für die intern laufende iptables überarbeitet. Ob diese beiden benötigt werden überprüfe ich jetzt nicht mehr, setze diesen Punkt aber auf die ToDo Liste. -
In der pfSense hatte ich auch einen logischen Fehler. Ich habe die Port Forwardings direkt auf die ServerIP geleitet, hier musste ich jedoch das WAN des hinter der pfSense hängenden Routers angeben.
2.1) ob die statische Route und das Gateway noch benötigt werden kann ich nicht genau sagen, ich werde es aber noch überprüfen. Sollten sie aufgrund meiner noch folgenden, nicht völlig unkomplizierten Konfiguration nicht mehr benötigt werden werde ich sie zur besseren Übersichtlichkeit löschen. -
Ich habe permanent versucht auf Port 80 weiterzuleiten und auch den NGINX Server auf Port 80 lauschen lassen. Port 80 ist aber zumindest beim OpenWRT nicht so ganz einfach, die WebGUI lauscht standardmäßig auf beiden und von dieser aus kann man da auch nichts dran rütteln. In den configs geht das natürlich. Ich habe das aber erst einmal nicht angefasst, werde diese aber vermutlich in Zukunft in den Configs auf HTTPS only setzen. Einfach weil ich jetzt weiß wie :)
3.1) Ich habe daher angefangen alles auf 8080 weiterzuleiten, inkl. die Listen Port des Servers selbst. Das habe ich mittlerweile aber wieder Teil-geändert.
Aktuell läuft es so:
pfSense greift auf Port 80 ab und leitet es an das WAN Gateway des Routers über 8080 weiter
der Router greift die Pakete auf 8080 ab und leitet sie (wieder) an den lokalen Server auf Port 80 weiter
Server lauscht (wieder) auf 80@viragomann Du hattest übrigens recht, die extra LAN Rule war nicht nötig, sie ist nun endgültig entfernt (zuvor seit deinem Hinweis immer mal wieder disabled, mal enabled)
Zu guter Letzt: Du warst mir eine riesen Hilfe !!! Dafür mal echt ganz vielen (wenn auch cyberschen :) ) Dank und Anerkennung !!!
Ich glaube, ohne dich wäre ich vorerst mal aus purem Frust temporär einfach auf uberspace umgeswitched um mit meiner Website zu beginnen. Das wäre dann aber eigentlich nicht das was ich gewollt habe - Lernen wie man ein kleines Netzwerk mit IPS (solved) und eigenem Server (just solving) auf eigene Faust hinbekommt.Wenn jemand Fragen hat, könnt ihr gerne in diesen Thread hier schreiben. Vielleicht ist er ja in Zukunft noch jemandem eine Unterstützung.
So, jetzt aber eine Runde Power Napping !
-
-
Hi,
na, die Sache muss dir ja verdammt wichtig gewesen sein.
Freut mich, dass es nun irgendwie läuft.Nein, die Route benötigst du für den Webserver-Zugriff dann nicht mehr, nachdem du jetzt auf die WAN-seitige IP des OpenWRT forwardest. Aber je nach dem, wie der OpenWRT ausgehende Verbindungen handhabt, könntest du sie dafür benötigen.
Wenn er ausgehende Verbindungen nattet (hier S-NAT, source), wird sie nicht benötigt. Denn dann kommen die Pakete mit der WAN-IP des OpenWRT als Source an der pfSense an. Diese schickt Antworten dann wieder dahin zurück.
Macht er nicht NAT, so gehen die Paket mit der originalen IP aus dem 10.1.1.0/24 Netz raus, hier wäre die Route wieder nötig, damit Antworten den Weg zurück finden.@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:
In der pfSense hatte ich auch einen logischen Fehler. Ich habe die Port Forwardings direkt auf die ServerIP geleitet, hier musste ich jedoch das WAN des hinter der pfSense hängenden Routers angeben.
Das war kein Fehler, so macht man das normalerweise in einem gerouteten Netz.
Es hätte auch funktionieren müssen (mit der statischen Route auf der pfSense). Vermutlich wäre noch beim OpenWRT an einer Schraube zu drehen gewesen.Auch sollte der Webserver des OpenWRT dazu zu bewegen sein, auf einem anderen Port zu lauschen als 80 oder 443, ansonsten würde das Ding ja oftmals zu Problemen führen.
Grüße
-
Hi,
ja, ich wollte das unbedingt hinbekommen, dass ich meine Homepage auf einem RaspberryPI (ein 3B+) laufen lasse. Man lernt ja nur durch die gestellten Aufgaben :)
Freut mich, dass es nun irgendwie läuft.
Danke :) Mich definitiv auch. Ich habe das ganze noch weiter gestrickt und meinen ursprünglichen Plan von vor zwei Tagen umgesetzt. Der WebServer ist nun in seinem eigenen VLAN, Static Route im OpenWRT und DNAT sind gesetzt, der Server ist soweit erst einmal in seinem eigenen VLAN und im WWW erreichbar. Tatsächlich isoliert ist er noch nicht, aber das kommt als nächstes. Er soll Zugriff auf das OpenWRT WAN bekommen, wird aber in Zukunft keinen Zugriff auf die anderen VLANs haben, insbesondere das OpenWRT LAN Subnetz möchte ich von ihm aus nicht erreichbar machen. Das wird vermutlich recht fix gehen, ist aber noch nicht geschehen. Das VLAN habe ich eben erst eingerichtet und die anderen Regeln im OpenWRT angepasst. (Anpassung in der pfSense selbst ist nicht nötig, da sie ja die Pakete "nur" an das WAN des OpenWRT schickt und es dort weitergeroutet wird)
Wenn er ausgehende Verbindungen nattet (hier S-NAT, source), wird sie nicht benötigt. Denn dann kommen die Pakete mit der WAN-IP des OpenWRT als Source an der pfSense an. Diese schickt Antworten dann wieder dahin zurück.
Macht er nicht NAT, so gehen die Paket mit der originalen IP aus dem 10.1.1.0/24 Netz raus, hier wäre die Route wieder nötig, damit Antworten den Weg zurück finden.Ja, so wie ich das bisher sehe, läuft der Rückweg über NAT, bzw. ja wohl S-NAT. Die Pakete sollten über die WAN IP des OpenWRT ankommen. Aber das ist eine gute Idee, für mein eigenes Netzwerkverständnis werde ich da noch ein Packet Capture drüber laufen lassen.
Man hat die Funktionen in der pfSense, nutzt sie aber nicht. (bis gestern jedenfalls) Ich werde das später nachholen und gerne hier berichten. Ich vermute aber, so wie ich das sehe, dass es tatsächlich via S-NAT in der pfSense ankommt.Das war kein Fehler, so macht man das normalerweise in einem gerouteten Netz.
Es hätte auch funktionieren müssen (mit der statischen Route auf der pfSense). Vermutlich wäre noch beim OpenWRT an einer Schraube zu drehen gewesen.Ja, das wundert mich ehrlich gesagt auch. Sämtliche Anleitungen im Netz gehen eben genau so vor. Offensichtlich ist bei mir im Netz irgendetwas mit dem NAT, evtl. NATted das OpenWRT nicht. Wie oben beschrieben prüfe ich das aber noch (ToDoList)
Ich möchte später für meine eigene Übersicht und mein Verständnis ein (wohl eher relativ) vollständiges Netzwerkdiagramm erstellen. Ich denke, so versteht man dann auch in 2 Monaten noch am besten, was eigentlich wie im Netzwerk funktioniert. Wäre mein erstes Mal, bis hierher hat es mit Zettel und Stift noch gereicht, aber DIN A4 Seiten haben ja auch begrenzte Größen :D
Vor allem wenn man die VLANs mit ID & Co und den entsprechend verknüpften Regeln eintragen will.Auch sollte der Webserver des OpenWRT dazu zu bewegen sein, auf einem anderen Port zu lauschen als 80 oder 443, ansonsten würde das Ding ja oftmals zu Problemen führen.
Japp, wie geschrieben werden die Pakete vom ISP am Firewall WAN an Port 80 aufgenommen, über Port 8080 and WAN des OpenWRT übertragen, und von dort WebServer VLAN zurück auf Port 80 geschickt.
Zwischenzeitlich hatte ich den WebServer selbst auf 8080 gestellt, aber später bemerkt dass das eine unnötige Veränderung sein könnte und es dann so gelöst.
Man kann den OpenWRT auch auf Port 80 (http) sperren und bspw nur auf 443 lauschen lassen bzw. Port 80 und 443 natürlich auch abändern.Die pfSense lauscht intern nicht mehr auf Port 80, extern eben für die Weiterleitung. Snort läuft seitdem es gestern funktionierte auch wieder im Block-Modus. Soweit ich das verstehe müsste snort bei ausgelösten Rules auch weiterhin blocken, trotz Port Forwarding. Jedenfalls hoffe ich das... Das muss ich noch einmal über einen längeren Zeitraum anhand der Alerts+Blocks überprüfen. Hier käme man in einer Produktivumgebung vermutlich an den Punkt simulierte Attacken von außen gegen das eigene Netz auf Port 80 laufen zu lassen. Aber erstens kann ich das nicht, zweitens wüsste ich nicht ob das noch legal wäre und drittens bin ich glaube ich nicht so das "besondere Ziel" (obwohl natürlich jeder Rechner mit Netzzugang wohl als begehrtes Ziel gilt, vor allem wenn da noch ein Server drauf läuft...dennoch fehlen mir einfach die Möglichkeiten das umzusetzen, evtl wenn es fertig ist div Online Scanner versuchen...mal schauen ob das dann funktioniert, schaden sollte es wohl nicht.... Naja, je nach Scan-"Anbieter" vermutlich. Wie auch immer, Zukunftsmusik :)
Jetzt werde ich erst einmal schauen das aus dem VLAN des WebServers kein Zugriff mehr nach innen möglich ist.Beste Grüße und nochmal vielen Dank
-
@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:
obwohl natürlich jeder Rechner mit Netzzugang wohl als begehrtes Ziel gilt, vor allem wenn da noch ein Server drauf läuft...
Wirklich jeder Rechner? Eine kühne Aussage.
LG