Hallo Zusammen,
ich bin seit kurzem auf die OpnSense umgestiegen und habe da eine Situation die ich nicht verstehe.
Ich hänge mit der OpnSense an einem DSLite-Anschluss und möchte via Reverse Proxy auf der OpnSense meinen Webserver aus dem LAN (IPv4) im Internet zur Verfügung stellen.
Der ReverseProxy ist mit nginx bereits aufgesetzt.
Eine entsprechende Regel habe ich unter Firewall -> Rules -> WAN angelegt (vgl. Screenshot1).
Gateway steht auf "default"
Leider werden eingehende Pakete trotzdem geblockt (vgl. Screenshot2)
Vielleicht könnt ihr hier weiter helfen ?
Vielleicht besser als Destination "This Firewall".
Nein.
Quote from: bimbar on November 11, 2021, 10:50:16 AM
Vielleicht besser als Destination "This Firewall".
Hatte ich auch schon probiert. Leider ohne Erfolg :(
Quote from: chemlud on November 11, 2021, 11:11:33 AM
Nein.
Korrekt :) Hast du eine Idee, was hier falsch ist ?
...leider nein.
PS: Äh, doch! Probier mal UDP statt TPC in der FW-Regel...
Schau mal im Dashboard im "Interfaces" Widget nach, was WAN tatsächlich für eine IPv6 Adresse hat. Oft ist die nämlich link local. Dann geht das so mit der Regel nicht sondern Du musst Deine Global Unicast Adresse da explizit reinschreiben.
UDP statt TCP bei HTTP als Protokoll? Das würde mich doch stark wundern. HTTPS - ja OK. Da wird inzwischen einiges via QUIC via 443/udp versucht, aber selbst dann ist der Aufbau eigentlich tcp.
Ansonsten scheint mir der Punkt von Patrick plausibler. In deinem Debug Shot steht ne externe public IP6 drin. Du nutzt WAN address - da ist es aber abhängig davon, was dein WAN als IP6 definiert hat. Und je nach Konfiguration kann die dazu noch abweichen. Daher war der Gedanke mit This Firewall (self) gar nicht so abwegig.
Aber wenn du schreibst du hast DSlite - hast du überhaupt eine statische IP6 oder ändert sichd as Prefix nicht eh alle Nase lang? Dann kannst du da recht viel reinschreiben, aber die IP6 wird sich ständig ändern.
Cheers
Quote from: chemlud on November 11, 2021, 10:02:28 PM
...leider nein.
PS: Äh, doch! Probier mal UDP statt TPC in der FW-Regel...
Angefragt wird von extern gans normales http also tcp port 80.
Der Screenshot besagt ja auch, dass ein TCP Paket mit dem Ziel Port 80 verworfen wird.
Daher erscheint mir der Anratz unwahrscheinlich.
ICh habe trotzdem mal probiert das Protokoll auf any zu stellen ... leider ohne Erfolg :(
Quote from: pmhausen on November 11, 2021, 10:07:47 PM
Schau mal im Dashboard im "Interfaces" Widget nach, was WAN tatsächlich für eine IPv6 Adresse hat. Oft ist die nämlich link local. Dann geht das so mit der Regel nicht sondern Du musst Deine Global Unicast Adresse da explizit reinschreiben.
Guter Hinweis. Vielen Dank leider sehe ich im Dashboard unter WAN genau die IPv6 Adresse, an die auch das verworfene Paket geht.
Dieses wird also aus dem Internet korrekt zur OpnSense geroutet und erst dort verworfen.
Ich habe daher versucht, die Regel auf Destination "any" zu schalten.
Auch das bringt keinen Effekt... Ich bin da echt ratlos... aber vielleicht verstehe ich die Grundlagen von OpnSense nicht gut genug.
Quote from: JeGr on November 12, 2021, 01:59:10 PM
UDP statt TCP bei HTTP als Protokoll? Das würde mich doch stark wundern. HTTPS - ja OK. Da wird inzwischen einiges via QUIC via 443/udp versucht, aber selbst dann ist der Aufbau eigentlich tcp.
Ansonsten scheint mir der Punkt von Patrick plausibler. In deinem Debug Shot steht ne externe public IP6 drin. Du nutzt WAN address - da ist es aber abhängig davon, was dein WAN als IP6 definiert hat. Und je nach Konfiguration kann die dazu noch abweichen. Daher war der Gedanke mit This Firewall (self) gar nicht so abwegig.
Aber wenn du schreibst du hast DSlite - hast du überhaupt eine statische IP6 oder ändert sichd as Prefix nicht eh alle Nase lang? Dann kannst du da recht viel reinschreiben, aber die IP6 wird sich ständig ändern.
Cheers
Es handelt sich um einen Anschluss von Unitymedia...
Ich habe das Thema jetzt länger beobachtet und habe schon das Gefühl, dass sich die IPv6 sehr selten ändert ...
von außen greife ich btw. per dynamischem dns zu ...
Wenn sich die IPv6 aktualisieren würde, müsste die Regel mit Destination WanAdress ja trotzdem weiter funktionieren oder ?
Aber ganz abgesehen davon wundert es mich halt, dass das Paket ja offensichtlich tatsächlich bei der Firewall ankommt und dann verworfen wird.. und das sogar wenn ich Destination any einstelle ...
Kann es sein, dass ich unter Firewall --> Rules --> WAN einfach an der falschen Stelle die Regel eintrage ?
Müsste es unter floating sein ? Soetwas hatte ich mal irgendwo gelesen...
Kann sich jemand von euch einen Reim darauf machen, warum das hier nicht funktioniert ?
> Es handelt sich um einen Anschluss von Unitymedia...
Die es ja nicht mehr gibt. Also Vodafone-Crap. Somit IMHO - wenn kein Business Anschluß - dann wechselnde Prefixe. Welch Spaß :)
> von außen greife ich btw. per dynamischem dns zu ...
Welche normalerweise dann diejenige ist, die auf dem WAN deiner Sense anliegt. So weit so gut. Ich bin mir zwar nicht sicher, wie sich der Reverse Proxy verhält wenn ihm im laufenden Betrieb einfach mal die IP6 weggezogen und geändert wird, aber gehen wir davon aus, dass er neugestartet wird, es mitbekommt und noch funktioniert :)
> Wenn sich die IPv6 aktualisieren würde, müsste die Regel mit Destination WanAdress ja trotzdem weiter funktionieren oder ?
Wenn wie gesagt der Reverse Proxy auf WAN und die WAN IP6 lauscht - ja. Und er sich bei einem Wechsel neustartet und aktualisiert. Da bin ich überfragt ob er das macht. Andernfalls könnte man ihn immer noch auf Localhost konfigurieren und eine Weiterleitung von WAN Address auf localhost einrichten, die müsste dann eigentlich immer passen.
> Aber ganz abgesehen davon wundert es mich halt, dass das Paket ja offensichtlich tatsächlich bei der Firewall ankommt und dann verworfen wird.. und das sogar wenn ich Destination any einstelle ...
Dazu brauchts mehr Logs und mehr Konfigurationsdetails auch wie der Reverse Proxy konfiguriert ist. Und ob der DynDNS der genutzt wird überhaupt auf die richtige IP6 konfiguriert ist, etc. etc. - aus den 2 kleinen Shots lässt sich das leider alles nicht so ganz entnehmen.
DynDNS IP6 muss mit WAN IP6 übereinstimmen, Regel auf WAN muss passen, Reverse Proxy muss richtig zuhören etc. die ganze Kette durch.
> Müsste es unter floating sein ? Soetwas hatte ich mal irgendwo gelesen...
Nein. Dein erstes Log Screenshot war "Default deny" - das würde heißen es hat nichts gematcht, deshalb ists rausgeflogen weil es keine Regel dazu gab. Ohne mehr Details und Screens kann man dazu leider nix sagen. Wir sehen zu wenig.
Cheers
IPv6 arbeitet nicht so mit Ports wie du es bei IPv4 gewöhnt bist, daher musst du den Trafic ohne Revers-Proxy auf deinen WEB-Server lassen.
Quote from: osmom on November 18, 2021, 09:24:35 PM
IPv6 arbeitet nicht so mit Ports wie du es bei IPv4 gewöhnt bist, daher musst du den Trafic ohne Revers-Proxy auf deinen WEB-Server lassen.
IPv6 arbeitet exakt so mit Ports wie IPv4. UDP und TCP wurden kein Stück geändert.
Was sich geändert hat, ist der praktisch vollständige Wegfall von NAT. Und das ist auch gut so.
Um also einen Webserver "im Internet" erreichbar zu machen, legst Du eine Regel an:
Interface: WAN
Source: any
Source Port: any
Destination: IPv6 Adresse von Deinem Webserver
Destination Port: 80 (aha!) ;)
Gruß
Patrick
Hallo Zusammen,
meine Frage hat sich nun aufgeklärt.
Offensichtlich ist es so, dass OPNSense das Paket rejected, wenn der Service (Ziel) für den die Regel konfiguriert ist, nicht erreichbar ist.
Das bedeutet, im LOG erscheint die Meldung, dass das Paket abgewiesen wurde, obwohl die Regel (pass) richtig konfiguriert ist. Dieses Verhalten kenne ich von anderen Firewalls so nicht.
In meinem Fall war der ReverseProxy nicht gestartet und die Pakete wurden als rejected gelogged... als matched rule wurde die "default deny" angegeben (wie gesagt trotz existierender und richtig konfigurierter "pass" Regel)
Ich finde dieses Verhalten ziemlich verwirrend ...
Ist dieses VErhalten so bekannt ?
Passiert das auch, wenn der Service nicht direkt auf der OPNSense liegt, sondern auf einem Host in der DMZ ?
> Offensichtlich ist es so, dass OPNSense das Paket rejected, wenn der Service (Ziel) für den die Regel konfiguriert ist, nicht erreichbar ist.
So funktioniert ein Paketfilter nicht. OPNsense bzw. die Filterregeln machen mit dem Paket genau das, was konfiguriert ist. Wenn das durchgelassen werden soll, wird es das auch. Nur weil der angegebene Port ggf. nicht erreichbar ist - was der Filter überhaupt nicht weiß! - wird nicht plötzlich die Firewall Regeln von allow auf reject umgeschaltet.
> Ist dieses VErhalten so bekannt ?
Nein, da "siehe oben". PF funktioniert so nicht.
> Passiert das auch, wenn der Service nicht direkt auf der OPNSense liegt, sondern auf einem Host in der DMZ ?
Dito nein.