[SOLVED] Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense

BSA66

Die FB hat nur zwei angemeldete Geräte, ein DECT Telefon das über VoIP funktioniert und die Firewall als Exposed Host. Ein von mir eingerichteter Server läuft da nicht drauf oder drüber. (das Standard VoIP halt nur, was aber hoffe ich kein Problem darstellen sollte, die Ports horchen ja auf 4Kx und 5Kx )

Die Option "Block private Networks" habe ich schon recht früh rausnehmen müssen, weil das anfangs auch schon zu Problemen geführt hat. Und eigentlich (vermutlich unnötigerweise..) ist halt noch die "Block Bogons" Regel drin. Die sollte ja aber meine internen IPs die alle im definierten Bereich liegen eigentlich auch nicht betreffen.

Ich hatte eben noch die Idee, dass der Port vielleicht vom OpenWRT Router geblockt wird, also habe ich da noch schnell ein Portforwarding eingestellt aber bis Stand jetzt funktioniert es immer noch nicht oder ich habe es eben falsch eingestellt.

Wenn ich in der pfSense unter "Diagnostics" - "Test Port" die interne IP und Port 80 angebe kommt auf jeden Fall die Meldung, dass der Port geschlossen ist.

viragomann

Was der OpenWRT für eine Funktion in deinem Netz hat, ist aus obiger Grafik leider nicht ersichtlich. Offenbar ist es eine prägnante und es wäre interessant diese zu kennen.

Diese "Test Port" Funktion habe ich noch nicht verwendet. Ich denke aber nicht, dass sie geeignet ist, um sich selbst zu testen.

Ich würde mal schauen, ob die Pakete überhaupt auf dem WAN Interface der pfSense ankommen.
Das lässt sich mit Diagnostics > Packet Capture prüfen. Interface auf WAN und Port auf 80 setzen und mal starten, während du einen Zugriff von außen versuchst.

BSA66

Oh, stimmt, das ist uneindeutig. Also OpenWRT (auf einem TPLink WDR4300) nutze ich als LAN Interface. Dort hängen grundsätzlich erstmal alle Clients drin (OPT1 ist aktuell ausgeschaltet -> Gästenetz bzw auch Spielwiese), von Drucker über TV bis PC und Smartphone über Wifi.

Die "Test Port" Funktion habe ich mal einfach ausprobiert.
Die Idee mit dem Packet Capture auf WAN und Port 80 werde ich direkt umsetzen, WireShark ist eh schon installiert und von daher direkt mal schauen. Vielleicht sehe ich ja tatsächlich was.

Was mich aber irritiert ist auch, dass sämtliche online Netzwerkscans bescheinigen, dass da keiner der standard Ports offen ist... Eigentlich sollte Port 80 ja wenigstens auf der pfSense offen sein. Aber anscheinend wird der Traffic ja da doch schon geblockt.

Ich starte jetzt jedenfalls erst einmal das vorgeschlagene Packet Capture und schaue, was ich da mal so sehen oder von ableiten kann.

BSA66

Ergebnis vom Packet Capture, gekürzt auf meine ISP IP:

21:23:36.844118 IP 192.168.F-B.LAN.50311 > 88.130.XX.XXX.80: tcp 0
21:23:36.844604 IP 88.130.XX.XXX.50311 > 192.168.F-B.LAN.80: tcp 0
21:23:36.844657 IP 88.130.XX.XXX.50311 > 10.10.WEB.SERVER.80: tcp 0

Kurze Erläuterung hierzu:
Mit 192.168.F-B.LAN meine ich den lokale Port der FB mit dem sich der WAN der pfSense verbindet
88.130.XX.XXX ist meine IP vom ISP
10.10.WEB.SERVER ist der WebServer

Wie ist das ganze zu deuten? Der Port Forward auf den Server wird ja offenbar in 50/100.000 Sekunden ausgeführt oder zumindest versucht auszuführen, wofür steht die 0? Ich vermute keine Verbindung / kein "State" zustande gekommen, oder?

Das war definitiv gut, ich muss es nur noch gleich mal lesen können.

Da aber bei den meisten anderen TCP Verbindungen hinten eine 1 steht, vermute ich dass es da tatsächlich irgendwo hakt. Und wenn ich das richtig verstehe, dann sogar wohl schon beim WAN Interface der pfSense selbst, oder?? Danke! :-)

EDIT: bei dem kurzen Packet Capture sehe ich, dass da bei manchen Verbindungen auch ganz andere Zahlen dahinter stehen, genauer 450, 451, 788, 861 und einmal 862. Allerdings sind das vermutlich weit unter 3% aller Verbindungen, bei allen anderen steht entweder eine 1 oder eine 0. Ich google da gleich mal nach was das bedeutet.
Bis hierher auf jeden Fall schonmal vielen Dank!

viragomann

Also die LAN Clients hängen aus Sichte der FB hinter dem OpenWRT? Und der OpenWRT hängt im selben Netz wie die pfSense auf der FB?
Wenn ja, sollte er hier keine Rolle spielen.

@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

Was mich aber irritiert ist auch, dass sämtliche online Netzwerkscans bescheinigen, dass da keiner der standard Ports offen ist... Eigentlich sollte Port 80 ja wenigstens auf der pfSense offen sein.

Definitiv, der Port müsste als offen angezeigt werden.
Der Server selbst erlaubt die Zugriffe?

Das Packet Capture verstehe ich nicht.
88.130.XX.XXX ist welche IP? Die der FB extern oder die, die dein Quell-Gerät hat, mit dem du den Zugriff testest?

Die FB macht doch NAT, oder? Dann sollten zu sehen sein:
192.168.F-B.LAN.x > pfSene-WAN.80
pfSene-WAN.80 > 192.168.F-B.LAN.x

Die Zahl am Ende gibt die Länge der Nutzlast an.

BSA66

@viragomann said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

Also die LAN Clients hängen aus Sichte der FB hinter dem OpenWRT? Und der OpenWRT hängt im selben Netz wie die pfSense auf der FB?
Wenn ja, sollte er hier keine Rolle spielen.

Ja, fast. Also die LAN Clients (inkl. Server) hängen hinter dem OpenWRT, welcher wiederum hinter der pfSense hängt, welche ihrerseits wiederum hinter der FB hängt. Es sind in diesem Fall drei verschiedene Netze.
Kurzes Schemata

FB 192.168.1.1
      |
pfSense 172.1.1.1
      |
OpenWRT 10.1.1.1
      |
Clients + Server 10.1.1.0/24 (feste IPs)

Definitiv, der Port müsste als offen angezeigt werden.
Der Server selbst erlaubt die Zugriffe?

Sehe ich eigentlich auch so.
Ja, also zumindest aus dem selben Subnetz (10.1.1.0/24) kann ich über die IP den NGINX Server mit der Standard "It Works!" erreichen. Daraus schließe ich aber, dass der Server auf Port 80 lauscht und dann ja auch antwortet.

88.130.XX.XXX ist welche IP? Die der FB extern oder die, die dein Quell-Gerät hat, mit dem du den Zugriff testest?
Ja, das war missverständlich formuliert. Das ist die externe IP.

Die FB macht NAT, soweit ich weiß. Die pfSense ist unter "System" "Advanced" "NAT Reflection Mode for Port Forwards" im Dropdownmenü auf "Pure NAT" eingestellt. Das sollte, soweit ich das verstehe, auch funktionieren, da ich ja auf jeder Ebene ausschließlich mit fest zugewiesenen lokalen IPs arbeite.

Die FB macht doch NAT, oder? Dann sollten zu sehen sein:
192.168.F-B.LAN.x > pfSene-WAN.80
pfSene-WAN.80 > 192.168.F-B.LAN.x

Hm, ich habe jetzt extra noch einmal wegen der Übersichtlichkeit das Packet Capture in Wireshark geladen und den von dir beschriebenen Ablauf finde ich tatsächlich nicht. Das macht mich nun stutzig. Ich muss aber auch zugeben, dass ich mich in das NAT erst noch einlesen muss...oder meine Kenntnis wie das über die drei Ebenen zusammenhängt eben doch sehr begrenzt ist. Das hat bisher ja immer "einfach so" funktioniert.
Um Probleme mit dem NAT (vermutlich) auszuschließen habe ich es nochmal über das "mobile Daten" Netz auf dem Smartphone versucht (IP 109.xxx.xxx.xxx), aber auch da kommt keine Verbindung zustande. Ein Packet Capture habe ich da noch nicht laufen lassen, werde das aber gleich noch nachholen.

BSA66

Das Packet Capture von den mobilen Daten aus sieht anders aus:

22:58:06.091155 IP 109.41.XXX.XXX.20959 > 192.168.FB-.LAN.80: tcp 0
22:58:07.086155 IP 109.41.XXX.XXX.20959 > 192.168.FB-.LAN.80: tcp 0
22:58:16.317787 IP 109.41.XXX.XXX.22656 > 192.168.FB-.LAN.80: tcp 0
22:58:17.316458 IP 109.41.XXX.XXX.22656 > 192.168.FB-.LAN.80: tcp 0
22:58:33.979860 IP 109.41.XXX.XXX.7042 > 192.168.FB-.LAN.80: tcp 0
22:58:34.980375 IP 109.41.XXX.XXX.7042 > 192.168.FB-.LAN.80: tcp 0
22:58:43.185904 IP 109.41.XXX.XXX.8333 > 192.168.FB-.LAN.80: tcp 0
22:58:44.186635 IP 109.41.XXX.XXX.8333 > 192.168.FB-.LAN.80: tcp 0

Das Log ist "ungekürzt", das sind also tatsächlich sämtliche aufgezeichneten Verbindungen (über etwa 10 Sekunden mit zwei "load page" Versuchen im Browser auf dem Smartphone)

Im vorigen sah das noch anders aus, da wurde eine Port Weiterleitung zum Web Server (10.IP-.WEB.SRV im LAN Port des OpenWRT im 10.er Subnetz) versucht oder angewiesen. Hier nicht mehr. So wie ich das bisher verstehe, blockt also die FB den Port 80. Was eigentlich nicht sein sollte, da die pfSense ja als Exposed Host in der FB hinterlegt ist.

EDIT
Ich habe eben mal unter "System Logs" "Firewall" "Normal View" nach der IP des Smartphones gesucht und herausgefunden, dass offensichtlich snort etwas damit zu tun hat. In den snort Logs habe ich die IP allerdings wieder nicht gefunden...vielleicht habe ich was übersehen. Ich schaue es mir gleich noch einmal genauer an...

Nov 22 22:58:44 WAN Block snort2c hosts (1000000110) 109.41.MOB.-IP:8333 10.10.WEB.SRV:80 TCP:S

EDIT 2
Scheint falscher Alarm gewesen zu sein. Snort hatte wohl zwar die mobile Daten IP geblockt, aber nach zurücksetzen der Firewall States und der Blocklist in snort tauchte die IP nicht wieder erneut in den Firewall Logs auf.

Jetzt bin ich mit meinem Latein grade wieder am Ende.

________________________________

Festhalten lässt sich bisher folgendes:

Starte ich einen online Port Scan auf meine externe IP erscheint folgendes:

Closed Port 80 is closed on 88.130.EXT.-IP

Wieso kommt durch Port 80 nichts durch? Die Portweiterleitung sieht bei mir folgendermaßen aus:

Folgend die entsprechende Firewall Regel auf WAN:

Und zu guter Letzt eine von mir zu Testzwecken eingerichtete Regel für LAN, ob die so nötig ist wage ich zu bezweifeln...aber es funktioniert ohne auch nicht

Über Tipps, Anregungen, Ideen und Erfahrungswerte freue ich mich. :-) Danke!

viragomann

Den Sinn des Aufbaus verstehe ich aber nicht. Wozu der OpenWRT hinter der pfSense, die ja selbst auch ein Router ist? Hängt da noch was dazwischen, was auf der pfSense Box keinen Platz hat?
Wie auch immer, auch in diesem Aufbau muss der Webserver erreichbar sein.

192.168.FB-.LAN ist die WAN-IP der pfSense? Ich war zuerst von der der FB ausgegangen.
So macht das letzte Capture wenigsten Sinn und es fehlen nur die Antworten vom Server.

Snort od. ähnliches sollte man fürs Troubleshooting generell deaktivieren. Solange hinter der pfSense nichts erreichbar ist, hat der ohnehin nichts zu tun, oder untersuchst du etwa Upstream-Traffic?

Bei deinem Aufbau müssen ein paar Punkte gegeben sein:

am OpenWRT ist die pfSense das Default Gateway (natürlich die IP der NIC, an dem der OpenWRT hängt)
auf der pfSense ist die FB das Default Gateway
auf der pfSense ist eine statische Route für das Netz 10.1.1.0/24 eingerichtet mit Ziel OpenWRT NIC
auf der FB ist die WAN-IP der pfSense als Exposed Host gesetzt
auf der pfSense ist eine D-NAT (destination) Portforwarding Regel für Port 80 auf den Webserver gesetzt
der OpenWRT erlaubt die Durchleitung von Port 80 auf den Webserver

@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

Ja, also zumindest aus dem selben Subnetz (10.1.1.0/24) kann ich über die IP den NGINX Server mit der Standard "It Works!" erreichen. Daraus schließe ich aber, dass der Server auf Port 80 lauscht und dann ja auch antwortet.

Das sagt hier nicht viel. Standardeinstellung fast jeder System-Firewall: Zugriffe aus dem eigenen Netzwerksegment werden erlaubt, welche aus anderen nicht.

Firewall-Regeln der pfSense wirken sich immer auf den Traffic aus, der auf dem Interface reinkommt. Die letzte Firewall-Regel am LAN ist sinnlos. Das LAN Interface dürfte kein eingehendes Paket mit Ziel 10.10.x.x erreichen.

BSA66

@viragomann said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

Den Sinn des Aufbaus verstehe ich aber nicht. Wozu der OpenWRT hinter der pfSense, die ja selbst auch ein Router ist? Hängt da noch was dazwischen, was auf der pfSense Box keinen Platz hat?
Wie auch immer, auch in diesem Aufbau muss der Webserver erreichbar sein.

Ich habe die pfSense auf einem APU2D4 Board, das hat insgesamt drei Intel NICs, einen nutze ich als WAN, einen als LAN und den letzten hin und wieder als OPT1.

192.168.FB-.LAN ist die WAN-IP der pfSense? Ich war zuerst von der der FB ausgegangen.
So macht das letzte Capture wenigsten Sinn und es fehlen nur die Antworten vom Server.

Genau, das ist richtig. Ich hätte auch FW-.WAN schreiben können.

Snort od. ähnliches sollte man fürs Troubleshooting generell deaktivieren. Solange hinter der pfSense nichts erreichbar ist, hat der ohnehin nichts zu tun, oder untersuchst du etwa Upstream-Traffic?

Ich habe snort auf Block seit ich die Suppress Regeln ausreichend gut eingestellt habe um seitdem die Firewall als Exposed Host laufen lassen zu können.
Du hast aber natürlich recht, da die FW sowieso quasi alles von außen stammende blockt könnte ich sie zu Testzwecken auch ausschalten. Das "Hintergrundrauschen" bei mir ist aber (für einen Anschluss der noch nichts anbietet nach außen) recht groß, und auch auf LAN blockt snort hin und wieder mal komische Dinge, allerdings seit Anpassung der Suppress Liste schon sehr viel weniger.
Theoretisch könnte ich es also für Testzwecke mal ausschalten. Ich vermute solange der Server noch nicht online ist wird auch nicht viel passieren dank pfSense.

am OpenWRT ist die pfSense das Default Gateway (natürlich die IP der NIC, an dem der OpenWRT hängt)

[ X ]
Auf WAN im OpenWRT ist die pfSense das so eingestellt

auf der pfSense ist die FB das Default Gateway

[ X ]
Auf WAN ist die FB das Default Gateway

auf der pfSense ist eine statische Route für das Netz 10.1.1.0/24 eingerichtet mit Ziel OpenWRT NIC

[ - ]
auf derpfSense ist überhaupt keine statische Route eingerichtet...ich werde das gleich mal ausprobieren!
Ich vermute die statische Route ist nur für eingehenden Traffic? Also pfsense >INCOMING> OpenWRT ? Sofern die für ausgehenden Verkehr nicht benötigt wird, könnte das vielleicht wirklich das Problem sein...ich probiers gleich!

auf der FB ist die WAN-IP der pfSense als Exposed Host gesetzt

[ X ]
japp

auf der pfSense ist eine D-NAT (destination) Portforwarding Regel für Port 80 auf den Webserver gesetzt

[ X ]
Ich kannte den Namen nicht, aber genau so ist das (src: any:any Dest ServerIP : Dest-Port 80)

der OpenWRT erlaubt die Durchleitung von Port 80 auf den Webserver

Das habe ich im OpenWRT im Laufe des heutigen Abends noch so eingestellt, unter "Firewall" "Traffic Rules" ein "Accept Forward" für "Any TCP From any host in wan to IP [WEBSERVER] on port 80 in lan"

@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

Ja, also zumindest aus dem selben Subnetz (10.1.1.0/24) kann ich über die IP den NGINX Server mit der Standard "It Works!" erreichen. Daraus schließe ich aber, dass der Server auf Port 80 lauscht und dann ja auch antwortet.

Das sagt hier nicht viel. Standardeinstellung fast jeder System-Firewall: Zugriffe aus dem eigenen Netzwerksegment werden erlaubt, welche aus anderen nicht.

Ich habs befürchtet.

Firewall-Regeln der pfSense wirken sich immer auf den Traffic aus, der auf dem Interface reinkommt. Die letzte Firewall-Regel am LAN ist sinnlos. Das LAN Interface dürfte kein eingehendes Paket mit Ziel 10.10.x.x erreichen.

Okay, ich hatte das vor einigen Stunden versucht und dann erst einmal dringelassen. Ich nehme sie gleich raus. Ich bin eigentlich auch ein Freund von so wenig Regeln in der Firewall wie möglich und das hier ist wirklich doppelt gemoppelt...kommt raus.

Danke soweit erstmal!!

Ich werde jetzt gleich eine Static Route wie von dir oben beschrieben einrichten.

BSA66

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.

viragomann

@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.

BSA66

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...

viragomann

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.

BSA66

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...

BSA66

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

BSA66

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 !

viragomann

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

BSA66

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

Gladius

@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