Hallo OPNsense User,
normalerweise höre ich immer "ich habe da mal eine Frage", heute muss ich mich aber mit einer Frage/Problem an Euch wenden und um Hilfe bitten.
In meiner Zweitwohnung steht seit 2 Jahren eine Sophos-Firewall, wo aber nun die Lizenz ausläuft. Die Sophos habe ich nicht installiert und dazu auch keine Zugangsdaten. Diese läuft aber bis heute problemlos. Als Ersatz habe ich mir eine OPNwall genommen und das aktuelle OPNsense (serial) installiert, ging problemlos. Das System habe ich vorkonfiguriert und bin damit in die Zweitwohnung gefahren. Alte FW abgeklemmt und OPNsense angeschlossen. Sofort war der Zugang zur WebGUI verfügbar. Auf der WAN Seite habe ich eine feste öffentliche IP und auf der LAN Seite eine feste interne IP. Von extern komme ich auch problemlos bis zur WAN, so die Protokolle.
Vorkonfiguriert hatte ich auch gleich 5 Portweiterleitungen von extern:
Webserver NAS Ports extern/internen: 80 und 443
3 Webcam Ports extern/intern: 15010, 15011 und 15012
Die entsprechenden Regeln wurden während der Konfiguration der Portweiterleitungen gleich mit angelegt.
Eigentlich sollte die Konfiguration eines derartigen Szenarios kein Problem darstellen. Aber es geht keine einzige Regel! Im Protokoll sehe ich die Anfragen und gleichzeitig den Hinweis "default deny/ state violation rule".
Mit OPNsense habe ich noch keine Erfahrungen. Eine Recherche in allen Einstellungen und verschiedene Änderungen haben nichts gebracht.
Jetzt hoffe ich auf Euch. Könnt Ihr mir bitte "mögliche" Ursachen nennen? Morgen bin ich wieder in der Zweitwohnung und würde einen weiteren Anlauf mit der OPNsense nehmen wollen.
Ich danke Euch schon jetzt.
Thomas
Bei Portweiterleitungen muss auch eine passende WAN-Regel erstellt werden, die das ganze durchlässt. Man kann dies normalerweise automatisch mit einstellen über die Filterzuordnung. Bitte prüfen, ob diese Regel existiert und ggf. die Portweiterleitung nochmal neu einrichten und auf zugeordnete Regel achten oder die passende Regel auf der WAN Schnittstelle in der Firewall hinzufügen.
https://docs.opnsense.org/manual/nat.html#port-forwarding Stichwort Filter rule association
Erst wenn du nichts mehr im Live View siehst, was geblockt wird, kannst du weiter machen.
Hallo Saarbremer,
danke für den Hinweis zu den Rules. Diese wurden mit der Erstellung der Portweiterleitung erstellt. Angesehen habe ich mir diese, war aber nichts auffällig. Morgen kann ich nochmals tiefer schauen. Im Protokoll steht die Filternummer 6. Wie muss ich dies zählen bzw. wie finde ich diese? Zudem existieren eine Menge an automatisch erstellten Rules, die aber nicht editierbar sind.
Danke.
Thomas
Die Filternummer ist nur sehr umständlich herauszufinden. Daher sollte man immer eine sprechende kurze Beschreibung bereithalten. Ansonsten macht Debuggen im LiveLog wenig spaß.
Regeln finden:
* Auf Firewall -> Diagnose -> Statistiken -> Regeln, da siehst du sie alle und kannst aufklappen, aber nicht verändern.
Da man bei der Port Weiterleitung selbst ja auch ein Quelle angeben, also den Zugriff einschränken kann, wenn man das möchte, setze ich die "Filter rule association" grundsätzlich auf "Pass". Dann braucht es keine extra Regel.
Ich habe mir alles Rules angesehen und finde in denen vom System erstellten eine Rule, welche das Problem sein könnte. Dies ist die Zweite, welche abgearbeitet wird:
x -> "grauer Pfeil"
IPv4+6*
Quelle: *
Port: *
Ziel: *
Gateway: *
Zeitplan: *
Netzwerk: *
Bemerkung: Default deny / state violation rule
Die Bemerkung entspricht den Hinweisen im Protokoll. Die 18 vom System automatisch erstellten Regeln kann ich aber nicht löschen oder bearbeiten. Damit vermute ich eine Einstellung in irgendeinem Menü.
Was sagt Ihr dazu?
Vermutlich ein problem deines Switches.
Ein Switch sitzt erst im LAN. Die Pakete werden doch in der FW durch die Rules der Schnittstelle WAN verworfen. Sehe ich da was falsch?
Nein, das siehst du richtig. Es gibt viele hier im Forum, die die default deny Regel gerne löschen würden. Das geht auch, indem man einfach die Firewall abschaltet (Settings unter Firewall irgendwo).
Aber niemand möchte das wirklich. Eher dürfte die Freigabe nicht korrekt sein.
Kannst du eine Freigaberegel im NAT hier bitte posten?
Neben den NAT-Regeln und den assoziierten Firewall-Regeln sollte man noch zwei Punkte wissen, wenn man von einer anderen Firewall kommt:
1. Manche Regeln (wie die Default-Deny-Rule) sind "last match" rules, d.h. sie werden implizit in der Reihenfolge nach unten sortiert. Das ist der Grund, wieso die Default-Deny-Rule oben stehen darf und trotzdem nicht alles blockt. Wenn man (explizite) eigene Regeln schreibt, sortiert man sie in die richtige Reihenfolge und nutzt meist "first match", d.h. die Regel zieht und weitere werden nicht mehr beachtet.
2. Es gibt eine bestimmte Reigenfolge, mit der die Regeln greifen. Man kann sich z.B. über eine "Block"-Regeln in den Floating Rules leicht Kopfzerbrechen bereiten, wenn man gerade Regeln für das Interface schreibt, weil die Floating Rules vor allen Interface Rules greifen. Selbiges gilt für Interface Groups. Die Prioritäten sind hier beschrieben: https://docs.opnsense.org/manual/firewall.html
Soweit ich mich erinnere, werden die assoziierten Regeln für NAT beim jeweiligen Interface angelegt, so dass solche Probleme auftreten könnten, wenn man nicht diszipliniert arbeitet.
Ich schreibe das nur, weil Ihr am Rande das Thema berührt (ohne dass es relevant ist), denn tatsächlich kann es im konkreten Fall nicht die "Default Deny"-Rule sein, die Probleme macht - die ist nur ein Last Resort. Offenbar fehlt eine entsprechende Regel vorher, die den NAT-Traffic durchlässt, z.B. weil in der NAT-Regel irgendeine Einschränkung greift (falsche Quell-Adresse, falsches Interface, was auch immer).
Will sagen: Hier fehlt offenbar die Erlaubnis, es ist kein übergeordnetes Blocking aktiv.
Der Rat, sich die NAT-Regeln mal anzusehen, ist also vollkommen richtig.
Guten Abend,
ich poste morgen mal eine Portweiterleitung und Regel dazu.
Thomas
Hier mal die aktuellen Einträge der Portweiterleitung und automatisch erstellten Regel.
Portweiterleitung HTTPS (Einstellungen, nicht aufgeführte Felder sind nicht aktiviert):
Schnittstelle: WAN
TCP/IP: IPv4 (Hinweis: IPv6 ist deaktiviert)
Protokoll: TCP/UDP
Quelle: jegliche
Quellports: von HTTPS an HTTPS
Ziel: jegliche (Hinweis: Als Test hatte ich schon LAN-Netzwerk, LAN-Adresse und die NAS-IP des Hosts)
Ziel IP umleiten: NAS_IP (ist die IP des NAS als Alias eingetragen)
Zielport weiterleiten: HTTPS
Pooloptionen: Standard
Berschreibung: Webserver NAS
NAT reflection: Aktivieren
Filter Regel Zuordnung: Rule Webserver NAS
Hier nun die angezeigte Regel Webserver NAS:
Erlauben (grünes Dreieck) -> gelber Pfeil (erste Zuordnung)
Protokoll: IP4 TCP/UDP
Quelle: *
Port: 443 (HTTPS)
Ziel: NAS_IP (Alias als IP zum NAS Webserver)
Port: 443 (HTTPS)
Gateway: *
Zeitplan: *
Beschreibung: Webserver NSS
Ich finde hier keinen Ansatz, habe auch andere Einstellungen getestet. Kann es an der Konfiguration der WAN oder LAN Schnittstelle liegen oder habe ich doch ein Denkproblem?
Quellport muss "any" sein, Zielport HTTPS.
Wie beschrieben sind die Quellports a priori nicht bekannt, daher any bei source port. Ports kleiner 1024 erfordern üblicherweise auch Adminrechte auf dem Client, so dass das auch zufällig nicht funktioniert.
Sieht man auch im Livelog, dass die Quellports alle 5-stellig waren.
Quellpost= any (jegliche), ich komme doch auf dem Port 443 an, warum dann any? Am WE bin ich nicht vor Ort und würde erstmal Eure Hinweise sammeln. Montag habe ich dann auch mehr Zeit für die FW.
Quelle - any, Ziel - 443. Dein Browser würfelt sich einen beliebigen freien Port > 1023 und kontaktiert dann den Server auf 443.
Quote from: DTB on March 08, 2024, 09:31:14 AM
Quellpost= any (jegliche), ich komme doch auf dem Port 443 an, warum dann any? Am WE bin ich nicht vor Ort und würde erstmal Eure Hinweise sammeln. Montag habe ich dann auch mehr Zeit für die FW.
Weil eine eingehende TCP-Verbindung technisch ein Quadrupel ist aus (Quell-IP, Quell-Port, Ziel-IP und Ziel-Port). Wenn bei einer HTTPS-Verbindung sowohl Ziel-Port als auch Quell-Port festgeschrieben, könnte zwischen zwei Partnern (= IPs) nur eine einzige HTTPS-Verbindung mit dem Well-Known Zielport 443 aufgebaut werden.
Deswegen erfolgt der Verbindungsaufbau meist über einen "flüchtigen", d.h. zufälligen Quell-Port. Da der vorab nicht bekannt ist, muss dafür "any" erlaubt werden.
Hier geht es nicht um "Port Translation", also dass der Ziel-Port 443 ggf. noch auf einen anderen Port umgeschrieben wird, das wäre bei OpnSense der "Redirect Port". In einer Fritzbox kann man den Quellport in der Regel gar nicht angeben, vielleicht deswegen die Verwirrung?
Hallo meyergru,
die HTTPS Weiterleitung ist nur ein Port/Regel. Ich habe noch 3 Webcams auf den Ports 15010/11/12, wo der gleiche Effekt auftritt. Wie Du schon richtig ahnst, habe ich mehr Erfahrung bei Fritzboxen, wo ich Quellport und Zielport genau mit 443 bzw. zB. 15010 angebe. In der OPNsense muss ich da auch any als Quellport nutzen?
Thomas
Quote from: DTB on March 09, 2024, 08:26:44 AM
wo ich Quellport und Zielport genau mit 443 bzw. zB. 15010 angebe. In der OPNsense muss ich da auch any als Quellport nutzen?
Warum nutzt Du überhaupt eine Sense, wenn Du selbst eine einfache Portweiterleitung nicht hinbekommst? Nicht das richtige Produkt für dich...
Davon ab, bei der Fritzbox setzt Du keinen Source Port, das unterstützt sie gar nicht. Lies Dir noch mal die Antworten hier durch, es wurde schon alles genannt.
Ja, natürlich. Aus Gründen würde ich allerdings keine Port-Translation mehr einrichten:
1. Falls Du jemals zukünftig mit IPv6 zusätzlich arbeiten willst: dort gibt es keine Port-Translation, also wird es schwierig, die Geräte konsistent per Namen anzusprechen.
2. Es gibt eine elegantere Möglichkeit, Geräte, die per HTTP(S) erreichbar sein sollen, verfügbar zu machen, die den ganzen Zauber nicht mehr braucht, nämlich HAproxy (https://forum.opnsense.org/index.php?topic=23339.0). In diesem Fall wird das jeweilige Endgerät mittels des DNS-Namens verfügbar gemacht, ggf. per IPv4 und IPv6 und man muss gar keinen Port mehr angeben.
Für letzteres würde ich eher das Caddy-Plugin empfehlen, das deutlich einfacher zu konfigurieren ist und in einer der nächsten Releases auch im OPNsense-Standard landen wird:
https://github.com/Monviech/os-caddy-plugin
Die Hinweise zum Quellport habe ich heute berücksichtigt, leider ohne Erfolg. Meine Pakete werden immer noch geblockt. Mittlerweile habe ich unterschiedlichste Einstellungen getestet und erhalte im Liveprotokoll immer die gleichen Ergebnisse.
Mein nächster Ansatz wäre, die Werkskonfiguration zu laden und nochmal in Ruhe die Konfiguration anzugehen. Dabei würde ich meine hier gepostete Einstellung incl. Quellport = any verwenden.
Erkennt ihr noch falsche Einstellungen bzw. kann mir jemand ein Beispiel für HTTPS senden?
Ich habe mir eine komplett neue OPNsense bestellt. Bin aber erstmal im Urlaub, melde mich dann wieder.
Thomas