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.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1520138202
Url: https://administrator.de/forum/webserver-hinter-pfsense-nur-aus-lokalen-netzwerken-erreichbar-1520138202.html
Ausgedruckt am: 23.12.2024 um 23:12 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.
Das hiesige Firewall Tutorial weist auch explizit darauf hin bei so einem Kaskaden Setup:
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 !
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 !
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
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
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
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
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.
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!
Lies mein Kommentar oben nochmal eingehend dann solltest du deinen Fehler einsehen, du benutzt einfach eine zu große Subnetzmaske, ganz einfach ...😉
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
Bzw. hier dann die Webseite des Servers beim Client:
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 ?
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🖖.
fehlt 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 !
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!!obwohl 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...
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.