NAT Portweiterleitung funktioniert nicht

[DTB]

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

[Saarbremer]

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.

[DTB]

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

[Saarbremer]

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.

[Patrick M. Hausen]

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.

[DTB]

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?

[Bob.Dig]

Vermutlich ein problem deines Switches.

[DTB]

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?

[Saarbremer]

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?

[meyergru]

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.

[DTB]

Guten Abend,
ich poste morgen mal eine Portweiterleitung und Regel dazu.
Thomas

[DTB]

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?

[Patrick M. Hausen]

Quellport muss "any" sein, Zielport HTTPS.

[Saarbremer]

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.

[DTB]

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.