37
Webserver hinter pfSense nur aus lokalen Netzwerken erreichbar
Hallo,
ich habe eine öffentliche IP-Adresse mit zugeordneten Domain xyz.de. Über eine Fritzbox habe ich Freigaben auf Ports 80 und 433 eingerichtet und an einen Webserver weitergeleitet. Das Ganze hat ohne Probleme funktioniert. Habe ca. 10 Jahre Erfahrung in Webentwicklung. Der Apache-Server ist also aus dem Internet erreichbar.
Nun habe ich pfSense dazwischen geschaltet. In der Fritzbox habe unter Freigaben die IP (192.168.178.20) der Firewall so wie die Ports 80 und 443 angegeben.
In pfSense habe ich NAT-Portweiterleitung erstellt. Webserver hat die IP 192.168.1.30. Darauf wird die IP 192.168.178.20 umgeleitet.
Aus dem Netzwerk der Fritzbox (PC mit WLAN, IP 192.168.178.40) kann ich den Apache-Server der hinter der pfSense ist unter 192.168.178.20 aufrufen.
Die Weiterleitung über die Fritzbox vom Internet aus (zweiter DSL-Anschluss) funktioniert nicht.
Habe mit einem anderen Apache probiert der direkt an Fritzbox angeschlossen ist. Dieser wird vom Internet aus angezeigt.
pfSense lässt die Anfragen aus dem Internet nicht durch, von lokalen Netzwerken schon.
pfSense:
- Automatische Regeln eingeschaltet
- NAT Reflektion eingeschaltet
- Bogon-Netze zugelassen (testweise)
- Anfragen von privaten Netzwerken zugelassen (testweise)
- NAT-Weiterleitung Quelle ANY:80 auf Ziel 192.168.1.30:80
Für alle Anregungen bin ich dankbar.
ich habe eine öffentliche IP-Adresse mit zugeordneten Domain xyz.de. Über eine Fritzbox habe ich Freigaben auf Ports 80 und 433 eingerichtet und an einen Webserver weitergeleitet. Das Ganze hat ohne Probleme funktioniert. Habe ca. 10 Jahre Erfahrung in Webentwicklung. Der Apache-Server ist also aus dem Internet erreichbar.
Nun habe ich pfSense dazwischen geschaltet. In der Fritzbox habe unter Freigaben die IP (192.168.178.20) der Firewall so wie die Ports 80 und 443 angegeben.
In pfSense habe ich NAT-Portweiterleitung erstellt. Webserver hat die IP 192.168.1.30. Darauf wird die IP 192.168.178.20 umgeleitet.
Aus dem Netzwerk der Fritzbox (PC mit WLAN, IP 192.168.178.40) kann ich den Apache-Server der hinter der pfSense ist unter 192.168.178.20 aufrufen.
Die Weiterleitung über die Fritzbox vom Internet aus (zweiter DSL-Anschluss) funktioniert nicht.
Habe mit einem anderen Apache probiert der direkt an Fritzbox angeschlossen ist. Dieser wird vom Internet aus angezeigt.
pfSense lässt die Anfragen aus dem Internet nicht durch, von lokalen Netzwerken schon.
pfSense:
- Automatische Regeln eingeschaltet
- NAT Reflektion eingeschaltet
- Bogon-Netze zugelassen (testweise)
- Anfragen von privaten Netzwerken zugelassen (testweise)
- NAT-Weiterleitung Quelle ANY:80 auf Ziel 192.168.1.30:80
Für alle Anregungen bin ich dankbar.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1520138202
Url: https://administrator.de/contentid/1520138202
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
37 Kommentare
Neuester Kommentar
Hallo,
Viele Grüße, commodity
- NAT Reflektion eingeschaltet
- wirkt nur von innen- Bogon-Netze zugelassen (testweise)
- ist Quatsch- Anfragen von privaten Netzwerken zugelassen (testweise)
- brauchst Du nur von innen- NAT-Weiterleitung Quelle ANY:80 auf Ziel 192.168.1.30:80
Das war an sich korrekt. Du hast aber beim Weiterleitungsziel geschludert. WAN Address ist nur die Firewall selbst. Gib den Webserver an.Viele Grüße, commodity
In pfSense habe ich NAT-Portweiterleitung erstellt.
Das ist bei einer Firewall bekanntlich nur die halbe Miete, denn du musst auch auf dem WAN Port ebenso ein Regelwerk erstellen was die Ports TCP 80 und TCP 443 auf die "WAN_ip_address" freigibt. Generell blockiert die Firewall wie es üblich ist alles an eingehenden Sessions am WAN Port.Du arbeitest ja auch mit der FritzBox in einer klassischen Router Kaskade wie sie HIER im Detail beschrieben ist.
Da dein Koppelnetz zudem ein privates RFC_1918_IP Netz ist solltest du im globalen Setup des WAN Ports, dort auch den entsprechenden Haken entfernen um diese IP Netze am WAN Port zu erlauben.
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät
Passt du das entsprechend an im Setup wird auch dein Port Forwarding auf Anhieb funktionieren !
- Das Weiterleitungsziel war schon richtig angegeben. Quelle soll WAN-Adresse sein, als Ziel ist Apache-Server angegeben. Im Lokalen Netz der Fritzbox funktioniert die Umleitung ohne Probleme.
Außerdem habe schon Einiges durchprobiert, das hat alles nicht funktioniert.
- Block private Networks - das war schon ausgeschaltet.
- Habe auch in der Fritzbox probiert pfSense auf "Exposed Host" zu stellen, gleiches Ergebnis.
- Ebenfalls OPNSense probiert. OPNSense ist von der Bedienung und Funktionsumfang eine Katastrophe. Da hat die Weiterleitung der Ports gar nicht funktioniert obwohl ich alles von pfSense nachgebildet habe.
- Regel "Alles freigeben" auf beiden Schnittstellen hinzugefügt. Gleiches Ergebnis.
Mich hat aber gewundert, was die Fritzbox alles durchlässt. In pfSense habe ich Protokoll eingeschaltet. In der Fritzbox waren nur die Prts 80 und 443 freigegeben. Das Protokoll der ofSense hat Sachen angezeigt, als ob Firewall auf Exposed Host geschaltet wäre.
Eine Woche lang probiert, nicht weiter gekommen. Es scheint mir so, dass weder pfSense noch OPNSense für meine Anwendung auf Anhieb funktioniert. Obwohl die Anwendung relativ einfach ist - Apache hinter pfSense (+ Fritzbox Kaskade). Kleinkram funktioniert, aber sobald es mit http nach draußen geht...
Außerdem habe schon Einiges durchprobiert, das hat alles nicht funktioniert.
- Block private Networks - das war schon ausgeschaltet.
- Habe auch in der Fritzbox probiert pfSense auf "Exposed Host" zu stellen, gleiches Ergebnis.
- Ebenfalls OPNSense probiert. OPNSense ist von der Bedienung und Funktionsumfang eine Katastrophe. Da hat die Weiterleitung der Ports gar nicht funktioniert obwohl ich alles von pfSense nachgebildet habe.
- Regel "Alles freigeben" auf beiden Schnittstellen hinzugefügt. Gleiches Ergebnis.
Mich hat aber gewundert, was die Fritzbox alles durchlässt. In pfSense habe ich Protokoll eingeschaltet. In der Fritzbox waren nur die Prts 80 und 443 freigegeben. Das Protokoll der ofSense hat Sachen angezeigt, als ob Firewall auf Exposed Host geschaltet wäre.
Eine Woche lang probiert, nicht weiter gekommen. Es scheint mir so, dass weder pfSense noch OPNSense für meine Anwendung auf Anhieb funktioniert. Obwohl die Anwendung relativ einfach ist - Apache hinter pfSense (+ Fritzbox Kaskade). Kleinkram funktioniert, aber sobald es mit http nach draußen geht...
dass weder pfSense noch OPNSense für meine Anwendung auf Anhieb funktioniert.
Gerade hier mal aufgesetzt mit einer FritzBox 7430 und pfSense als auch OPNsense...Funktioniert auf Anhieb !
Statt Exposed Host die dedizierten Ports geforwardet.
Irgendwas hast du also falsch gemacht... ?!
Bedenke das du in der FritzBox zwingend den WebZugriff aufs GUI übers Interne (WAN Port) deaktivierst !
Andernfalls "denkt" die FB das der eingehende Webtraffic für sie selber ist und blockiert das Port Forwarding auch wenn es konfiguriert ist.
Du kannst selber checken ob eingehender TCP 80 und 443 Traffic an der Firewall ankommt indem du ganz einfach mal ins Diagnostics Menü gehst und über die Pakte Capture Funktion dir einfach mal allen eingehenden TCP 80 und 443 Traffic am WAN Port ansiehst.
Damit kannst du dann genau sehen ob die FB davor überhaupt eingehenden HTTP Traffic an die Firewall weiterleitet !
Ein einfacher und simpler Check auf den man doch eigentlich auch von selber kommt !
Habe eine Testseite bei Apache auf Port 82 gelegt damit es mit WebGui der Fritzbox nicht zu Übersprechung kommt. Wie man sieht kommen Anfragen durch haben aber beim Loggen scheinbar eine Länge von 0 byte.
Mitschnitt einer Anfrage über externe IP. Es ist nur ein betreffender Teil der Anfrage. Externe IP ist mit ___.___.___.___ ausgeblendet:
Mitschnitt derselben Seite über domain der Fritzbox vom PC mit IP 192.168.177.26:
Pakete kommen an. Es sieht so aus als ob die verworfen werden. Wenn das im lokalen Netzwerk wäre könnte man sagen, dass die Subnetzmaske nicht stimmt.
Ja, es ist das Netz mit IP 192.168.177 nicht 192.168.178. Habe zuvor nur zu Vereinfachung angegeben.
Mitschnitt einer Anfrage über externe IP. Es ist nur ein betreffender Teil der Anfrage. Externe IP ist mit ___.___.___.___ ausgeblendet:
16:59:20.726412 IP 192.168.177.20.37412 > ___.___.___.___.82: tcp 0
16:59:20.727115 IP ___.___.___.___.37412 > 192.168.177.20.82: tcp 0
16:59:20.986390 IP 192.168.177.20.24853 > ___.___.___.___.82: tcp 0
16:59:20.987118 IP ___.___.___.___.24853 > 192.168.177.20.82: tcp 0Mitschnitt derselben Seite über domain der Fritzbox vom PC mit IP 192.168.177.26:
17:01:23.913648 ARP, Request who-has 192.168.177.20 tell 192.168.177.26, length 46
17:01:23.913658 ARP, Reply 192.168.177.20 is-at 00:f1:f3:1f:ee:16, length 28
17:01:23.927680 IP 192.168.177.26.49968 > 192.168.177.20.82: tcp 0
17:01:23.927966 IP 192.168.177.20.82 > 192.168.177.26.49968: tcp 0
17:01:23.932172 IP 192.168.177.26.49968 > 192.168.177.20.82: tcp 0
17:01:23.932199 IP 192.168.177.26.49968 > 192.168.177.20.82: tcp 435
17:01:23.932391 IP 192.168.177.20.82 > 192.168.177.26.49968: tcp 0
17:01:23.988750 IP 192.168.177.20.82 > 192.168.177.26.49968: tcp 1212
17:01:24.013863 IP 192.168.177.26.49968 > 192.168.177.20.82: tcp 405
17:01:24.014017 IP 192.168.177.20.82 > 192.168.177.26.49968: tcp 0
17:01:24.014167 IP 192.168.177.20.82 > 192.168.177.26.49968: tcp 396Pakete kommen an. Es sieht so aus als ob die verworfen werden. Wenn das im lokalen Netzwerk wäre könnte man sagen, dass die Subnetzmaske nicht stimmt.
Ja, es ist das Netz mit IP 192.168.177 nicht 192.168.178. Habe zuvor nur zu Vereinfachung angegeben.
Kollege @aqui hatte natürlich Recht, die Regel/Weiterleitung war schon i.O. Da lag ich falsch.
OPNSense auszuprobieren ging natürlich am Problem vorbei. Wenn man beim Autofahren rechts rum den Weg nicht findet, fährt man ja auch nicht einfach links und hofft dann, dass man ankommt. Wenn Du verstehen willst, musst Du dran bleiben und suchen. Ist doch wohl in der Webentwicklung nicht anders. Firewalling ist (wie Du siehst) komplex, das macht sich nicht in 5 Minuten. Hast Du keine Zeit/Elan dafür, lass es bleiben.
Den Satz von Dir ganz oben verstehe ich nicht:
Klingt ja so, als ob Du den Webserver unter 192.168.178.20 erreichst. Das kann/darf ja nicht sein, wenn das die Adresse der Pfsense ist. Nur Falsch beschrieben oder doch was verdreht eingestellt?
Hier nochmal zum Abgleich meine (funktionierende) Konfig.
NAT:
Rule:
Viele Grüße, commodity
TO:
Quelle soll WAN-Adresse sein, als Ziel ist Apache-Server angegeben.
Das wiederum ist Quatsch. Deine obigen Regel und das Forwarding (Bilder) sind korrekt. Das Problem steckt wahrscheinlich außerhalb. Mit dem Exposed Host hätte das aber erledigt sein sollen.Quelle soll WAN-Adresse sein, als Ziel ist Apache-Server angegeben.
OPNSense auszuprobieren ging natürlich am Problem vorbei. Wenn man beim Autofahren rechts rum den Weg nicht findet, fährt man ja auch nicht einfach links und hofft dann, dass man ankommt. Wenn Du verstehen willst, musst Du dran bleiben und suchen. Ist doch wohl in der Webentwicklung nicht anders. Firewalling ist (wie Du siehst) komplex, das macht sich nicht in 5 Minuten. Hast Du keine Zeit/Elan dafür, lass es bleiben.
Den Satz von Dir ganz oben verstehe ich nicht:
Aus dem Netzwerk der Fritzbox (PC mit WLAN, IP 192.168.178.40) kann ich den Apache-Server der hinter der pfSense ist unter 192.168.178.20 aufrufen.
Klingt ja so, als ob Du den Webserver unter 192.168.178.20 erreichst. Das kann/darf ja nicht sein, wenn das die Adresse der Pfsense ist. Nur Falsch beschrieben oder doch was verdreht eingestellt?
Hier nochmal zum Abgleich meine (funktionierende) Konfig.
NAT:
Rule:
Viele Grüße, commodity
Wie man sieht kommen Anfragen durch haben aber beim Loggen scheinbar eine Länge von 0 byte.
Ist nun die .177.20 die Firewall oder der Webserver? Ich denke, dieser steht im LAN der Pfsense?Was in aller Welt soll dann die Regel auf 192.168.1.30:80? Welches Gerät soll das sein?
Öffenliche IP: ___.___.___.___
Fritzbox: 192.168.177.1
Firewall WAN: 192.168.177.20
Firewall LAN: 192.168.1.1
WebServer: 192.168.1.30
Apache läuft in dem Protokoll auf Port 82 damit es sich nicht mit Webgui von Fritzbox überspricht.
Fritzbox: 192.168.177.1
Firewall WAN: 192.168.177.20
Firewall LAN: 192.168.1.1
WebServer: 192.168.1.30
Apache läuft in dem Protokoll auf Port 82 damit es sich nicht mit Webgui von Fritzbox überspricht.
kann ich den Apache-Server der hinter der pfSense ist unter 192.168.178.20 aufrufen.
wie bringst Du das mit dieser InfoFirewall WAN: 192.168.177.20
in Deckung?Findest Du es normal, dass Du Deinen Webserver unter der Adresse der Firewall erreichst?
Das sind zwei unterschiedliche Posts. Ja, ich finde es richtig dass, ich den Webserver unter der Adresse der Firewall aufrufen kann. Das ist auch so gewünscht. Webserver wird am WAN Anschluß der Firewall bereitgestellt.
Habe gerade ipFire, eine weitere opencource Firewall installiert. Ergebnis ist gleich.
Lokal sind die Seiten abrufbar, extern nicht.
Es muss am Provider oder an der vom Provider modifizierten Fritzbox liegen.
Ich werde versuchen eine nicht gebrandete Fritzbox zu besorgen.
Habe gerade ipFire, eine weitere opencource Firewall installiert. Ergebnis ist gleich.
Lokal sind die Seiten abrufbar, extern nicht.
Es muss am Provider oder an der vom Provider modifizierten Fritzbox liegen.
Ich werde versuchen eine nicht gebrandete Fritzbox zu besorgen.
Das sind zwei unterschiedliche Posts. Ja, ich finde es richtig dass, ich den Webserver unter der Adresse der Firewall aufrufen kann. Das ist auch so gewünscht. Webserver wird am WAN Anschluß der Firewall bereitgestellt.
Also mein Verständnis ist da anders:
Anschluss und Adresse sind zwei Paar Schuhe.
An der Adresse der Firewall erreicht man: Die Firewall
An der Adressse des Webservers: Den Webserver
Am WAN-Anschluss der Firewall hängt: Das Modem bzw. der Koppelnetz - Router
Du beschreibst es nach meinem Verständnis widersprüchlich: Wenn Dein Webserver am WAN-Anschluss der Firewall hinge (*), wäre er im Koppelnetz 177.0. Dann könnte man ihn vielleicht unter 177.20 erreichen (nicht aber unter 192.168.1.30), was natürlich fehlerhaft wäre, wenn 177.20 die Adresse der Firewall ist.
Jedenfalls wäre in diesem Fall die Firewall gar nicht an der Adressierung beteiligt. Geräte im 177.0 Koppelnetz erreicht die FB ja direkt.
Dein Webserver gehört in irgend ein Netz der Firewall, vorzugsweise eine DMZ und hat dort eine Adresse des Netzes (von Dir ja eigentlich auch angegeben mit 192.168.1.30). Kläre erst einmal, ob Du das so umgesetzt hast und ob Du von einem Gerät, das im Koppelnetz 177.0 hängt, den Webserver unter 192.168.1.30 auch erreichst. Wenn das der Fall ist, sollten auch die obigen Regeln klappen.
(*) Wie machst Du das eigentlich? Ich habe genau einen WAN-Anschluss, da hängt das Modem dran (bei Dir die Fritzbox). Wo genau kabelst Du da den Webserver rein?
Ein Plan sagt mehr als 1000 Worte. Vielleicht zeichnest Du mal Deine Verbindungen zwischen FB, Firewall, Webserver und anfragenden Clients in einen kleinen Plan?
Viele Grüße, commodity
Hier ist die vereinfachte Darstellung:
Doppeltes NAT funktioniert nicht. Die Clients kommen vom unbestimmten Port an. Der Router gibt an Port 80 adressierte Pakete an Firewall weiter, Firewall bzw. NAT an den Webserver. Bei Antwort des Webservers versucht die Firewall die Pakete bei dem Router abzuladen. Dieser weiß jedoch nicht wohin damit. So werden sie verworfen.
Doppeltes NAT funktioniert nur wenn beide Richtungen ge-NAT-et sind. Da Clients von beliebigen Adressen und Ports ankommen funktioniert das nicht.
Ich weiß, dass manche Profis sich über diese Diskussion kaputt lachen werden. Da wider einer den "Double Trouble" kennenlernen musste.
Beispiel aus dem Protokoll:
Der Fall ist erledigt. Die Antwort lautet "Interfacrs -> Assignments -> Bridges".
Doppeltes NAT funktioniert nur wenn beide Richtungen ge-NAT-et sind. Da Clients von beliebigen Adressen und Ports ankommen funktioniert das nicht.
Ich weiß, dass manche Profis sich über diese Diskussion kaputt lachen werden. Da wider einer den "Double Trouble" kennenlernen musste.
Beispiel aus dem Protokoll:
17:01:23.927680 IP 87.179.123.251.49968 > 192.168.177.20.82: tcp 0
17:01:23.927966 IP 192.168.177.20.82 > 192.168.177.1.49968: tcp 0Der Fall ist erledigt. Die Antwort lautet "Interfacrs -> Assignments -> Bridges".
Na prima. Du hast zwar den Client im Koppelnetz vergessen, aber den kann man sich ja denken.
Ich fasse mal zusammen, was ich von Deinen obigen Ausführungen verstehe:
1. Du kannst von einem Client im Netz 177.0 die Adresse 177.20 erreichen.
2. Du erreichst dort nicht die Pfsense, sondern den Webserver
3. Web Ports werden durch die Fritzbox und die Pfsense auf den Webserver im 1.0 Netz weitergeleitet
4. Aus dem Web erreichst Du den Webserver nicht (per Http/s).
Korrekt?
1. ist ja logisch
2. ist schräg
3. ist korrekt
4. ist jetzt klarer. Du hast offenbar irgend eine Umleitung in der Pfsense oder im Webserver, die den Webserver auf die 177.20 leitet. Das wiederum funktioniert offenbar nicht aus dem Web. Die Ursache dürfte 2. sein (siehe aber auch alternativ unten). Auch aus dem Koppelnetz muss der Webserver unter seiner 1.30-Adresse erreicht werden. Eine andere Adresse hat er ja nicht. Die krude Umleitung, die dazu führt, dass dieser unter der Adresse der Firewall erreicht wird, musst Du finden und eliminieren.
Beim Mailserver musst Du doch fast identische Regeln haben. Wenn der funktioniert, gleich das einfach ab.
Vielleicht entsteht dein Problem auch aus der verwendeten Subnetzmaske. Wenn Du die Netze 1.0 und 2.0 ähnlich wie in der Fritzbox mit einer 16er Subnetzmaske angegeben hast (im Plan steht dazu nichts), sind 177.20 und 1.30 im selben Netz, die Pfsense wird dann nicht ins andere Interface routen, sondern die 1.30 im WAN-Interface suchen (und dort nicht finden, denn diese ist ja in LAN1). Die IP-Ranges, die Du angibst, auch bei der FB, gehören zu einem 24er Netz.
Viele Grüße, commodity
Ich fasse mal zusammen, was ich von Deinen obigen Ausführungen verstehe:
1. Du kannst von einem Client im Netz 177.0 die Adresse 177.20 erreichen.
2. Du erreichst dort nicht die Pfsense, sondern den Webserver
3. Web Ports werden durch die Fritzbox und die Pfsense auf den Webserver im 1.0 Netz weitergeleitet
4. Aus dem Web erreichst Du den Webserver nicht (per Http/s).
Korrekt?
1. ist ja logisch
2. ist schräg
3. ist korrekt
4. ist jetzt klarer. Du hast offenbar irgend eine Umleitung in der Pfsense oder im Webserver, die den Webserver auf die 177.20 leitet. Das wiederum funktioniert offenbar nicht aus dem Web. Die Ursache dürfte 2. sein (siehe aber auch alternativ unten). Auch aus dem Koppelnetz muss der Webserver unter seiner 1.30-Adresse erreicht werden. Eine andere Adresse hat er ja nicht. Die krude Umleitung, die dazu führt, dass dieser unter der Adresse der Firewall erreicht wird, musst Du finden und eliminieren.
Beim Mailserver musst Du doch fast identische Regeln haben. Wenn der funktioniert, gleich das einfach ab.
Vielleicht entsteht dein Problem auch aus der verwendeten Subnetzmaske. Wenn Du die Netze 1.0 und 2.0 ähnlich wie in der Fritzbox mit einer 16er Subnetzmaske angegeben hast (im Plan steht dazu nichts), sind 177.20 und 1.30 im selben Netz, die Pfsense wird dann nicht ins andere Interface routen, sondern die 1.30 im WAN-Interface suchen (und dort nicht finden, denn diese ist ja in LAN1). Die IP-Ranges, die Du angibst, auch bei der FB, gehören zu einem 24er Netz.
Viele Grüße, commodity
Der Fall ist erledigt. Die Antwort lautet "Interfacrs -> Assignments -> Bridges".
Dein Problem hat gar nichts mit NAT und Double-NAT zu tun, sondern bestätigt meine Annahme der fehlerhaften Subnetzmaske. Mit dem Bridging hast Du nun die Adresse 1.30 im WAN verfügbar gemacht nach der die Pfsense sich vorher einen Wolf gesucht hatte, weil Du ihr gesagt hast, die Adresse läge am WAN-Interface an.Mit der Bridge tut sie das dann natürlich und für Dich funktioniert es. Das Subnetting ist dennoch fehlerhaft und hat sicherlich noch weitere "Freuden" für Dich auf Lager.
Wenn es für Dich aber so reicht, kann der Fred geschlossen werden
Viele Grüße, commodity
Verstehe immer noch nciht was Du unter Punkt 2 schräg findest. Ich arbeite täglich mit solchen Umleitungen. Man denke an Proxys (Apache hinter Nginx), Routing und was weiß ich noch was es da so gibt. Aus dem Web frage ich die Adresse des Routers und bekomme die Antwort vom Webserver.
www.practicallynetworked.com/fixing-double-nat/
www.practicallynetworked.com/fixing-double-nat/
Umleitungen sind natürlich kein Problem und gerade in der Welt der Webserver völlig normal.
Schräg ist es, den Webserver auf eine Adresse (und Port) umzuleiten, wo die Firewall ihren eigenen Webserver anbietet.
Aber leite wohin Du magst, ich denke, das Problem ist lokalisert und Du hast es über einen (weiteren) Umweg nicht gelöst, aber umgangen. Obgleich es natürlich sauberer wäre, die Netze korrekt zu teilen und über die Firewall zu routen (mit oder ohne NAT). Warum einfach, wenn es kompliziert geht Was wäre die Welt ohne Probleme?
Auch wenn Du im bösen Double-Nat den Übeltäter siehst. Das war nicht das Problem. Double-Nat ist auch heute noch häufig und bringt (außer geringen Performancenachteilen) bei den meisten Protokollen keine Probleme, nur etwas mehr Aufwand bei den Weiterleitungen. Steht so auch in dem von Dir verlinkten beitrag bei
Viele Grüße, commodity
Schräg ist es, den Webserver auf eine Adresse (und Port) umzuleiten, wo die Firewall ihren eigenen Webserver anbietet.
Aber leite wohin Du magst, ich denke, das Problem ist lokalisert und Du hast es über einen (weiteren) Umweg nicht gelöst, aber umgangen. Obgleich es natürlich sauberer wäre, die Netze korrekt zu teilen und über die Firewall zu routen (mit oder ohne NAT). Warum einfach, wenn es kompliziert geht
Was wäre die Welt ohne Probleme?Auch wenn Du im bösen Double-Nat den Übeltäter siehst. Das war nicht das Problem. Double-Nat ist auch heute noch häufig und bringt (außer geringen Performancenachteilen) bei den meisten Protokollen keine Probleme, nur etwas mehr Aufwand bei den Weiterleitungen. Steht so auch in dem von Dir verlinkten beitrag bei
One way to compensate for double NAT ....
Es war früher im KMU-Bereich durchaus gängig eine DMZ durch eine Routerkaskade zu bilden und es gilt noch heute als die "DMZ des kleinen Mannes". Netzwerktechnisch ist es völlig Wurst, ob eine IP-Adresse einmal oder zweimal umgeschrieben wird. Wenn Du die Portweiterleitungen korrekt machst, kommen auch alle Pakete an, kannst sie auch fünfmal kaskadieren, das ändert nichts.Viele Grüße, commodity
Ich finde Deine Anregungen gut. pfSense bietet doch nicht am WAN einen Webserver an. Außerdem kann ich den Webserver auch am Port :81 oder :82 durch NAT leiten. An dieser Stelle hatte ich nie Probleme gehabt.
Wie würdest Du es lösen?
Wie würdest Du es lösen?
Erstens lass den Müll mit der Bridge ...
Btw. Deine pfSense liegt im DHCP Bereich deiner Fritzbox , dss ist nur empfehlenswert wenn man dieser per fester DHCP Reservierung immer die selbe Adresse zuweist, ansonsten gilt die Regel Router nur mit statischen Adressen außerhalb des DHCP Adressbereichs zu versehen.
Wie würdest Du es lösen?
Mach es folgendermaßen dann ist das ordentlich :- Outbound NAT an der pfSense für die beiden Subnetze hinter der pFSense deaktivieren
- Auf der Fritzbox zwei statische Routen anlegen die so aussehen :
Zielnetz 192.168.1.0Maske 255.255.255.0Gateway 192.168.177.20Zielnetz 192.168.2.0Maske 255.255.255.0Gateway 192.168.177.20- Nun können die Portweiterleitungen auf der Fritzbox direkt auf die Ziel-IP des Webservers (192.168.1.30) zeigen (nicht mehr auf die pFSense!!), doppeltes NAT entfällt nun da geroutet statt geNATet wird.
- Firewall-Regeln auf der pfSense müssen natürlich passen so dass der Traffic von ANY am WAN Port der pfSense an den Webserver und dessen Ports fließen darf .
- Schon wird ein Schuh draus.
Btw. Deine pfSense liegt im DHCP Bereich deiner Fritzbox , dss ist nur empfehlenswert wenn man dieser per fester DHCP Reservierung immer die selbe Adresse zuweist, ansonsten gilt die Regel Router nur mit statischen Adressen außerhalb des DHCP Adressbereichs zu versehen.
In der Fritzbox Portweiterleitung auf 192.168.30 Port 80 eingerichtet.
Beide statische Routen in der Fritzbox hinzugefügt.
Ich kann im Moment den Webserver weder aus dem Netz der Fritzbox noch aus dem Internet erreichen.
Wenn ich die Subnetzmaske bei der statischen Route auf 255.255.0.0 ändere kann ich den Webserver aus dem Netzwerk der Fritzbox erreichen. Kann dann aber die Portweiterleitung nicht einrichten. Fritzbox erzählt, dass die IP 192.168.1.30 nicht im ihren Netz liegt.
Webserver hat bei mir feste IP mit Subnetzmaske 255.255.0.0 (/16).
Ich stelle wahrscheinlich dumme Fragen. Wenn du einen "Donate Button" hättest könnte ich mich bedanken.
Beide statische Routen in der Fritzbox hinzugefügt.
Ich kann im Moment den Webserver weder aus dem Netz der Fritzbox noch aus dem Internet erreichen.
Wenn ich die Subnetzmaske bei der statischen Route auf 255.255.0.0 ändere kann ich den Webserver aus dem Netzwerk der Fritzbox erreichen. Kann dann aber die Portweiterleitung nicht einrichten. Fritzbox erzählt, dass die IP 192.168.1.30 nicht im ihren Netz liegt.
Webserver hat bei mir feste IP mit Subnetzmaske 255.255.0.0 (/16).
Ich stelle wahrscheinlich dumme Fragen. Wenn du einen "Donate Button" hättest könnte ich mich bedanken.
Fritzbox erzählt, dass die IP 192.168.1.30 nicht im ihren Netz liegt.
Die FritzBox supportet generell kein Port Forwarding auf Zieladressen die nicht in ihrem lokalen IP Netz liegen. Technisch ist das unsinnig wenn es eine Route dahin gibt aber die FritzBox supportet es dennoch nicht.Zitat von @hruendel:
In der Fritzbox Portweiterleitung auf 192.168.30 Port 80 eingerichtet.
Falsche Adresse .... Da fehlt ein Oktet .In der Fritzbox Portweiterleitung auf 192.168.30 Port 80 eingerichtet.
Beide statische Routen in der Fritzbox hinzugefügt.
Ich kann im Moment den Webserver weder aus dem Netz der Fritzbox noch aus dem Internet erreichen.
Wunder nicht wenn die Adresse falsch ist.Ich kann im Moment den Webserver weder aus dem Netz der Fritzbox noch aus dem Internet erreichen.
Wenn ich die Subnetzmaske bei der statischen Route auf 255.255.0.0 ändere kann ich den Webserver aus dem Netzwerk der Fritzbox erreichen. Kann dann aber die Portweiterleitung nicht einrichten. Fritzbox erzählt, dass die IP 192.168.1.30 nicht im ihren Netz liegt.
Webserver hat bei mir feste IP mit Subnetzmaske 255.255.0.0 (/16).
Das wusste hier ja keiner das du hier ne 16er Maske benutzt das kann ja so nie funktionieren da du im Netz der Fritzbox schon eine Adresse aus dem Subnetz benutzt das ist also dein grober Fehler den du hier begehst!!! Das ist dein Fehler das Netzdesign ist Bullshit!Webserver hat bei mir feste IP mit Subnetzmaske 255.255.0.0 (/16).
Setze das Netz der Fritzbox auf eine 24er Maske und die Netze hinter der pFSense jeweils auch auf ein 24er Netz dann klappt das auf Anhieb!
Zitat von @aqui:
Fritzbox erzählt, dass die IP 192.168.1.30 nicht im ihren Netz liegt.
Die FritzBox supportet generell kein Port Forwarding auf Zieladressen die nicht in ihrem lokalen IP Netz liegen. Technisch ist das unsinnig wenn es eine Route dahin gibt aber die FritzBox supportet es dennoch nicht.Da bist du nicht mehr auf dem aktuellen Stand inzwischen funktioniert das auch auf einer Fritzbox wenn die entsprechende statische Route vorhanden ist! Funktioniert und wurde getestet!
Ich stelle den Webserver und den Mail-Server wieder in DMZ (Fritzboxnetz). Administrative Sachen und Windows hinter pfSense und gut ist. Die interne Firewall des Webservers (Ubuntu) und des Mailservers muss ich entsprechend konfigurieren. Datenbank vom Webserver eventuell auch hinter die Firewall. Hoffe das es performant genug ist.
Bis jetzt hat sich das Sicherheitskonzept auf dem Webserver gut geschlagen.
Wie immer - weniger ist mehr!
Wenn ich jemanden finde der mir das Netz fürs Geld vernünftig konfigurieren kann lasse ich es machen. Mit Proxys von der pfSense möchte ich mich jetzt nicht auseinander setzen. Außerdem wenn man eine Anwendung über sämtliche Server verteil ist die Wahrscheinlichkeit eines langen Ausfalls höher.
Bis jetzt hat sich das Sicherheitskonzept auf dem Webserver gut geschlagen.
Wie immer - weniger ist mehr!
Wenn ich jemanden finde der mir das Netz fürs Geld vernünftig konfigurieren kann lasse ich es machen. Mit Proxys von der pfSense möchte ich mich jetzt nicht auseinander setzen. Außerdem wenn man eine Anwendung über sämtliche Server verteil ist die Wahrscheinlichkeit eines langen Ausfalls höher.
Lies mein Kommentar oben nochmal eingehend dann solltest du deinen Fehler einsehen, du benutzt einfach eine zu große Subnetzmaske, ganz einfach ...😉
Subnetzmasken auf allen Geräten auf 255.255.255.000 /24 umgestellt, alles neu gestartet. Webserver ist weder aus Fritzbox-Netz noch aus dem Internet erreichbar. Mit Subnetzmasken habe ich angefangen als alles andere nicht funktioniert hat.
Ich könnte noch Sophos XG ausprobieren. Nach drei Wochen habe aber kein Bock mehr. Ich glaube, es ist zu speziell. Baue alles zurück auf DMZ und gut ist.
Ich könnte noch Sophos XG ausprobieren. Nach drei Wochen habe aber kein Bock mehr. Ich glaube, es ist zu speziell. Baue alles zurück auf DMZ und gut ist.
Zitat von @hruendel:
Subnetzmasken auf allen Geräten auf 255.255.255.000 /24 umgestellt, alles neu gestartet. Webserver ist weder aus Fritzbox-Netz noch aus dem Internet erreichbar. Mit Subnetzmasken habe ich angefangen als alles andere nicht funktioniert hat.
Tja wäre vielleicht mal ein Anfang hier deine Konfiguration im Klartext zu Posten anstatt uns immer wieder nur etwas vom Pferd zu erzählen, so kann man nicht helfen, weil das ein absolut simples Szenario ist das 100% funktioniert, du hast nur eben eine Blockade im Hirn was man ja schon an der zu groß konfigurierten Subnetzmaske sieht ...Subnetzmasken auf allen Geräten auf 255.255.255.000 /24 umgestellt, alles neu gestartet. Webserver ist weder aus Fritzbox-Netz noch aus dem Internet erreichbar. Mit Subnetzmasken habe ich angefangen als alles andere nicht funktioniert hat.
Ich könnte noch Sophos XG ausprobieren.
😆Also wenn du mit einer pfSense schon nicht klar kommst dann erst Recht nicht mit einer Sophos, wenn die Grundlagen zum Routing nicht vorhanden sind bringt dir ein anderes Gerät nix.Nach drei Wochen habe aber kein Bock mehr.
Wow so viel Zeit für etwas was in 2 Minuten erledigt ist 🤪.Ich glaube, es ist zu speziell.
Nä simpler einfachster Standardkrams, den dir ein Routing-Anfänger nach der ersten Lernstunde im Schlaf konfiguriert.Inhaltsverzeichnis
wenn die entsprechende statische Route vorhanden ist! Funktioniert und wurde getestet!
Ohh, cool ! Wieder was gelernt. Weisst du in welcher OS Version das eingeführt wurde ?
Damit das hiesige Drama nun endlich auch mal zu einem Ende kommt...
Test Setup
(10.99.1.0er Netz emuliert hier das Internet)
Geräte Übersicht FritzBox
Port Forwarding FritzBox
Alias Port Definition pfSense Firewall
Das Erleichtert das TCP Port Handling. Ohne Alias müsste man alles doppelt für die 2 HTTP Ports eintragen !
Port Forwarding pfSense Firewall
WAN Port Regelwerk
Wird durch das o.a. NAT automatisch erstellt !
Check der durch die FritzBox geforwardeten HTTP Pakete mit Capture Tool (Diagnostics)
Hier sieht man das die TCP 80 und 443 IP Pakete vom Port Forwarding der FritzBox sauber an der pfSense (WAN Port) ankommen und die Firewall diese an die .1.108 des lokalen Webservers weiter forwardet.
Absender Port des Browser Clients = 42016
Zielport der Destination WAN IP der pfSense = 80
Browser Client Check
tcpdump Output auf dem Webserver (Nginx). Der Webserver gibt eine Webseite mit der IP Adresse des Clients zurück. Zum Code dazu siehe hier. root@webserver:/home/# tcpdump -i eth0 -s 65535 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:25:07.525714 IP 10.99.1.146.40696 > 192.168.1.109.http: Flags [.], ack 2852505856, win 501, options [nop,nop,TS val 33138037 ecr 2566144506], length 0
16:25:07.525872 IP 192.168.1.109.http > 10.99.1.146.40696: Flags [.], ack 1, win 470, options [nop,nop,TS val 2566154746 ecr 33117713], length 0
16:25:09.421958 IP 10.99.1.146.40696 > 192.168.1.109.http: Flags [P.], seq 1:383, ack 1, win 501, options [nop,nop,TS val 33139934 ecr 2566154746], length 382: HTTP: GET / HTTP/1.1
16:25:09.432813 IP 192.168.1.109.http > 10.99.1.146.40696: Flags [.], seq 1:1449, ack 383, win 486, options [nop,nop,TS val 2566156653 ecr 33139934], length 1448: HTTP: HTTP/1.1 200 OK 
Fazit
Works as designed !!!Zitat von @aqui:
Weisst du in welcher OS Version das eingeführt wurde ?
Leider nein.wenn die entsprechende statische Route vorhanden ist! Funktioniert und wurde getestet!
Ohh, cool ! Wieder was gelernt. Weisst du in welcher OS Version das eingeführt wurde ?
Vielen Dank für eure Mühe.
Bei dem Beispiel von aqui (hat sich sehr viel Mühe gemacht) fehlt jedoch die Antwort von dem Webserver, eine Seite mit "It works!" von Apache. Das Protokoll zeigt nur die Anfrage, nicht die Antwort. Das habe ich auch schon so ähnlich gemacht mit gleichen Ergebnissen, sehe Post oben.
Bei dem Beispiel von aqui (hat sich sehr viel Mühe gemacht) fehlt jedoch die Antwort von dem Webserver, eine Seite mit "It works!" von Apache. Das Protokoll zeigt nur die Anfrage, nicht die Antwort. Das habe ich auch schon so ähnlich gemacht mit gleichen Ergebnissen, sehe Post oben.
Zitat von @hruendel:
Das Protokoll zeigt nur die Anfrage, nicht die Antwort. Das habe ich auch schon so ähnlich gemacht mit gleichen Ergebnissen, sehe Post oben.
Das Protokoll zeigt nur die Anfrage, nicht die Antwort. Das habe ich auch schon so ähnlich gemacht mit gleichen Ergebnissen, sehe Post oben.
Wenn der Apache nicht antwortet dann ist der wohl das Problem (checke per tcpdump oder wireshark am Apache ob die Anfragen dort ebenfalls eintreffen und ob er sie auch beantwortet) wohl weil die Anfragen hier entweder per "Allow from" auf einen IP Bereich eingeschränkt wurden oder die vhosts bzw. Server names nicht korrekt konfiguriert wurden.
Hier läuft das ja ebenfalls einwandfrei, bitte tu uns doch einen Gefallen und rede nicht immer nur von "habe ich genau so gemacht" sondern poste harte Fakten und deine exakte Config von allen beteiligten Geräten dann sehen wird den Fehler sehr wahrscheinlich direkt. Wenn wir uns hier die Mühe machen solltest du das auch können. Danke🖖.
1fehlt jedoch die Antwort von dem Webserver, eine Seite mit "It works!" von Apache.
Auf besonderen Wunsch eines einzelnen Herrn und weil heute Sonntag ist oben nochmals in der Doku nun auch diese Daten der Vollständigkeit halber ergänzt.Das simple und einfache Setup ist in FB und pfSense mit 3 Mausklicks auch für Laien in nichtmal 10 Minuten zusammengeklickt und rennt auf Anhieb !
Eben...works as designed !
Ich habe den Beispiel von aqui durchgespielt - es funktioniert! Das durch-NAT-etn funktioniert.
Statt Apache habe ich Web-GUI vom Cisco Router genommen. Das hat auf Anhieb geklappt.
Bei Apache ist das Thema etwas komplexer. Am geplanten Server funktioniert immer noch nicht.
pfSense ist ganz schön wählerisch. Ich habe es mittlerweile mit mehreren Geräten getestet, manche Web-Guis gehen durch, manche nicht, obwohl alles mit Sternchen (*) in NAT und Regeln freigegeben ist. Firewall ist ebenfalls komplett ausgeschaltet.
Meine Vermutungen:
1. Automatischer Wechsel von Port 80 zu 443 (HTTP zu HTTPS) kann von der Firewall missverstanden werden.
2. Header vom Apache gefehlt dem pfSense nicht. Habe am Webserver einiges getrimmt (ServerSignature Off, Header unset Server, no-sniff usw.). Obwohl ich alles wieder ausgeschaltet habe funktioniert es mit Apache immer noch nicht. Verbiege jetzt aber deswegen nicht den Webserver.
3. Eventuell versucht pfSense den Apache durch seinen Proxy zu schicken.
4. Es ist besser die Ports 80, 443 um pfSense umzuleiten. Das kann sich tatsächlich in manchen Fällen mit Web-Gui von pfSense übersprechen. Wenn zum Beispiel alle Ports freigegeben sind ist Gui von pfSense am WAN auf dem Port 443 verfügbar. Man kann zwar den Port von Web-Gui umstellen bin mir aber nicht sicher dass, das vernünftig funktioniert und ob es nicht irgendwelche defaults auf Ports 80 und 443 noch laufen.
Also so richtig ausgereift mit dem Betrieb von Apache ist es nicht. Auf jeden Fall es ist nicht einfach "plug and play". Bei komplexeren Anwendungen will pfSense nicht.
Ich gebe zu dass, ich mich mit Routing nicht auskenne. Ich habe auch die Fritzbox bei den Veruchen neu gestartet. Dabei wird die Verbindung zu Vodafone getrennt. Nach Trennung dauert es oft bis zu einem Tag bis die Fritzbox unter der öffentlichen IP-Adresse erreichbar ist und die IP in der Fritzbox erscheint. Das habe ich vergessen. Aus diesem Grund waren die Seiten öffentlich zeitweise nicht erreichbar. Habe gestern um ca. 10:00 die Fritzbox neu getartet, ich kann Fritzbox seit gestern Abend erreichen. Die IP wird nach zwanzig Stunden in der Fritzbox immer noch nicht angezeigt. Aber mit den Sachen wollte ich euch nicht beschäftigen. Die Sache ist halt etwas komplexer.
Ich muss das Ganze noch überdenken und werde dann entscheiden wie ich das Netz aufbaue.
Statt Apache habe ich Web-GUI vom Cisco Router genommen. Das hat auf Anhieb geklappt.
Bei Apache ist das Thema etwas komplexer. Am geplanten Server funktioniert immer noch nicht.
pfSense ist ganz schön wählerisch. Ich habe es mittlerweile mit mehreren Geräten getestet, manche Web-Guis gehen durch, manche nicht, obwohl alles mit Sternchen (*) in NAT und Regeln freigegeben ist. Firewall ist ebenfalls komplett ausgeschaltet.
Meine Vermutungen:
1. Automatischer Wechsel von Port 80 zu 443 (HTTP zu HTTPS) kann von der Firewall missverstanden werden.
2. Header vom Apache gefehlt dem pfSense nicht. Habe am Webserver einiges getrimmt (ServerSignature Off, Header unset Server, no-sniff usw.). Obwohl ich alles wieder ausgeschaltet habe funktioniert es mit Apache immer noch nicht. Verbiege jetzt aber deswegen nicht den Webserver.
3. Eventuell versucht pfSense den Apache durch seinen Proxy zu schicken.
4. Es ist besser die Ports 80, 443 um pfSense umzuleiten. Das kann sich tatsächlich in manchen Fällen mit Web-Gui von pfSense übersprechen. Wenn zum Beispiel alle Ports freigegeben sind ist Gui von pfSense am WAN auf dem Port 443 verfügbar. Man kann zwar den Port von Web-Gui umstellen bin mir aber nicht sicher dass, das vernünftig funktioniert und ob es nicht irgendwelche defaults auf Ports 80 und 443 noch laufen.
Also so richtig ausgereift mit dem Betrieb von Apache ist es nicht. Auf jeden Fall es ist nicht einfach "plug and play". Bei komplexeren Anwendungen will pfSense nicht.
Ich gebe zu dass, ich mich mit Routing nicht auskenne. Ich habe auch die Fritzbox bei den Veruchen neu gestartet. Dabei wird die Verbindung zu Vodafone getrennt. Nach Trennung dauert es oft bis zu einem Tag bis die Fritzbox unter der öffentlichen IP-Adresse erreichbar ist und die IP in der Fritzbox erscheint. Das habe ich vergessen. Aus diesem Grund waren die Seiten öffentlich zeitweise nicht erreichbar. Habe gestern um ca. 10:00 die Fritzbox neu getartet, ich kann Fritzbox seit gestern Abend erreichen. Die IP wird nach zwanzig Stunden in der Fritzbox immer noch nicht angezeigt. Aber mit den Sachen wollte ich euch nicht beschäftigen. Die Sache ist halt etwas komplexer.
Ich muss das Ganze noch überdenken und werde dann entscheiden wie ich das Netz aufbaue.
Zitat von @hruendel:
Bei Apache ist das Thema etwas komplexer. Am geplanten Server funktioniert immer noch nicht.
Palawer rabarber ... Config posten dann sieht man auch was ...Bei Apache ist das Thema etwas komplexer. Am geplanten Server funktioniert immer noch nicht.
pfSense ist ganz schön wählerisch.
Nö es steht und fällt mit dem Bediener 😉.Ich habe es mittlerweile mit mehreren Geräten getestet, manche Web-Guis gehen durch, manche nicht, obwohl alles mit Sternchen (*) in NAT und Regeln freigegeben ist. Firewall ist ebenfalls komplett ausgeschaltet.
Das liegt meistens daran das die Web-GUIs Traffic aus Sicherheitsgründen nur aus dem selben Subnetz oder privaten Adressbereichen annehmen. Das muss man dann am Gerät konfigurieren/freischalten!
Meine Vermutungen:
1. Automatischer Wechsel von Port 80 zu 443 (HTTP zu HTTPS) kann von der Firewall missverstanden werden.
2. Header vom Apache gefehlt dem pfSense nicht.
Gibt es auch nicht die pFSense rührt den Inhalt der Pakete bis auf das NAT (Umschreiben der Ziel und Quelladresse) im Default gar nicht an.3. Eventuell versucht pfSense den Apache durch seinen Proxy zu schicken.
Wenn du an der pFSense natürlich weitere Packages installiert und aktiviert hast die Man in the Middle den Traffic inspizieren nur dann , ansonsten nein!4. Es ist besser die Ports 80, 443 um pfSense umzuleiten. Das kann sich tatsächlich in manchen Fällen mit Web-Gui von pfSense übersprechen. Wenn zum Beispiel alle Ports freigegeben sind ist Gui von pfSense am WAN auf dem Port 443 verfügbar.
Logisch, aber da DNAT in der Prerouting-Chain schon vor der INPUT-Chain im PacketFlow liegt macht das überhaupt nichts denn durch das Umschreiben der Zieladresse dort kommt das Paket gar nicht erst an der Input Chain des Routers an sondern wird direkt in die Forward-Chain der Firewall geleitet, somit ist das egal ob das Web-IF der PFsense auf den üblichen Ports weiter läuft, die einzige Einschränkung die du dann hast ist eben das du das WebIF der pFSense am WAN nicht mehr erreichst sondern direkt auf dem genNATeten Host landest!!
Man kann zwar den Port von Web-Gui umstellen bin mir aber nicht sicher dass, das vernünftig funktioniert und ob es nicht irgendwelche defaults auf Ports 80 und 443 noch laufen.
Klar geht das und das ist auch kein Problem.Also so richtig ausgereift mit dem Betrieb von Apache ist es nicht.
Auf jeden Fall es ist nicht einfach "plug and play". Bei komplexeren Anwendungen will pfSense nicht.
Ebenso Blödsinn. pFSense ist eine Millionenfach getestete Firewall bei der es solche Spirenzchen nicht mehr gibt, das Backend verwendet absolute Standard- Firewall Packages, Fehler solcher Art würden der riesen Community sofort auffallen.Ich gebe zu dass, ich mich mit Routing nicht auskenne.
Genau hier liegt das Problem und das du dir nicht helfen lassen willst weil du null Configs von deiner Seite postest!!1obwohl alles mit Sternchen (*) in NAT und Regeln freigegeben ist.
Vielleicht ist genau DAS der Fehler, denn man gibt ja immer nur das frei was man wirklich da durchhaben will. Die Firewall arbeitet max. nur auf Layer 4 also wenn der Port 80 oder 443 stimmt forwardet sie es und ist dabei definitiv NICHT wählerisch. Was sollte sie denn auch noch groß wählen können wenn sie lediglich nur auf den TCP Port sieht ?! 1.)
Nope. Port ist Port. Die FW geht strikt danach was man ihr sagt wann und wie oft das wecheslt ist dabei vollkommen Wumpe.
2.)
Ist auch Unsinn, sorry. Kollege @149569 hat es oben schon gesagt. Die FW "sieht" max. bis zum OSI Layer 4 also gerade noch den Port. Alles was oben drüber ist wie Header usw. kann sie physisch gar nicht sehen (und tut es auch nicht). Ihr ist also völlig egal was da als Content drin ist.
3.)
Kollege @149569 hat es ja auch hier schon gesagt: Solange du keinen Proxy über die Paket Verwaltung nachinstalliert hast hat sie ja physisch gar keinen Proxy den sie nutzen kann. Also ist das Argument auch unsinnig.
4.)
Das WebGUI ist deaktiviert auf dem WAN Port also dann das niemals zutreffen was du da sagst.
Es rennt hier völlig unabhängig ob man einen NGINX oder Apachen dahinter betreibt. Der Apache verhält sich ganz genau so. Die Wireshark und tcpdump Traces vom Server selber sprechen ja auch eine absolut eindeutige Sprache !!!
Genau deshalb ist im Wireshark oben der Trace mit dem kompletten HTTP Header auch gepostet. Wie du ja selber sehen kannst wird dort absolut gar nix umgeschrieben, blockiert oder was auch immer du da vermutest. Wie auch wenn die FW OSI Layer über 4 gar nicht anfasst.
Ich gebe zu dass, ich mich mit Routing nicht auskenne.
Na ja, mal ehrlich...richtiges Routing ist doch so einen banale und piffige Einfach Kaskade aus FB und Firewall nun wirklich nicht. Einfacher als sowas geht es ja kaum noch. Um reine Routing Belange muss man sich da wahrlich nicht kümmern.Ich muss das Ganze noch überdenken
Da ist sicher etwas absolut Wahres dran ! Dann aber eine Skizze hier posten damit wir auch wirklich verstehen was du da verzapfst und nicht wie oben immer nachfragen müssen...
1
Dank eurer Hilfe läuft die Firewall jetzt.
- Firewall zum 25-en Mal auf Grundeinstellungen zurückgesetzt. Diesmal nichts umgestellt.
- Webserver per NAT durch Fritzbox und pfSense durch verbunden.
- Ports um Firewall umgeleitet ( 80 > 81 > 80, 443 > 444 > 443)
- Webserver von fester IP auf DHCP umgestellt und an Firewall angemeldet.
Ich danke euch für eure Hilfe! Und sehr hilf- und lehrreiche Kommentare!
- Firewall zum 25-en Mal auf Grundeinstellungen zurückgesetzt. Diesmal nichts umgestellt.
- Webserver per NAT durch Fritzbox und pfSense durch verbunden.
- Ports um Firewall umgeleitet ( 80 > 81 > 80, 443 > 444 > 443)
- Webserver von fester IP auf DHCP umgestellt und an Firewall angemeldet.
Ich danke euch für eure Hilfe! Und sehr hilf- und lehrreiche Kommentare!
Webserver von fester IP auf DHCP umgestellt und an Firewall angemeldet.
Keine intelligente Idee !! Zumindestens solltest du dann über die Server Mac Adresse eine feste IP Reservierung machen. Ansonsten läuft ggf. das Port Forwarding ins Leere wenn sich die DHCP IP ändert. Server haben immer feste statische IPs. Solltest du als Server Admin eigentlich auch wissen.
