Hi
Versuche ein mühsames Subnet aus UA zu blocken. Habe Gemini dazu befragt. Habe ein Alias mit dem betreffenden Subnet gemacht. Gemini meinte erst, ich müsse eine FW Regel bei der WAN Schnittstelle machen. Das hat aber nichts gebracht. Gemini meinte darauf, ich müsse die Regel vor die automatisch generierten Regeln setzen. Ist dem so? Nach mir ist das gar nicht möglich. Bzw. wüsste nicht wie.
Nun gut, meinte Gemini, ich solle das doch im DMZ VLAN blocken. Auch hier selbes Problem. Die Hosts kommen immer noch durch. Auch hier kann ich nichts vor die automatisch generierten Regeln setzen.
Nun meinte Gemini, ich soll das bei den NAT Regeln machen. Aber auch da bin ich nicht wirklich weiter gekommen.
Beim Ziel handelt es sich um einen Plesk Server. Da sind auch schon diverse Adressen aus dem betreffenden Netz im Jail. Dachte erst, die versuchen es sicher auf 8443 TCP (Mutmassung), aber den habe ich schon vor einiger Zeit zu gemacht.
Wo mache ich denn jetzt die Regel, damit das Netzwerk draussen bleibt? Würde es auch gerne loggen, um zu sehen, auf welchem Port/Dienst die da dauernd rein brezeln. Ich vermute, das wäre schon unter WAN Rules korrekt gewesen? Hatte die Regel ganz oben, aber leider kamen die netten Ukrainer immer noch durch.
Alias ist 81.30.107.0/24
Gruss und danke
NAT-Regeln haben Vorrang vor Filter-Regeln (die ggf. auch nur ein Interface betreffen), siehe: https://docs.opnsense.org/manual/firewall.html#processing-order
Also musst Du als Quelle der Port-Forward-Regel das Subnetz oder den Alias mit gesetzter "Source / Invert" Checkbox verwenden.
Die Alternative sind NAT-Regeln, die eine explizite, assoziierte Firewall-Regel anstelle von "Pass" haben. Diese kann man dann, genau wie andere Filter-Regeln, verschieben und damit die Priorität ändern (oder die Block-Regeln mit höherer Priorität in den Floating Rules anstelle der Interface Rules für das WAN unterbringen).
Danke. Leider nur die Hälfte verstanden.
Was meinst Du denn mit "Floating Rules"? Sind das die automatisch generierten Regeln? Oder in den globalen Regeln?
Würde das gerne bei den WAN Regeln machen, ja. So zumindest der Plan. Hatte es ja bereits versucht, siehe Screenshot oben.
Firewall > Rules > Floating ...
Okay, danke. Versuche es nun über spezielle Port Forwarding Rules. Wäre das so richtig? Und muss ich da die beiden unteren Plesk Regeln mit * als Source noch raus löschen, nehme ich an? Oder wäre das in den Floating Rules besser aufgehoben? Da kann es durchaus sein, dass ich da noch mehr blocke dann, auch auf andere Ziel Adressen. Aber blicke da nicht ganz dahinter, wie das gehen soll, ehrlich gesagt.
Musste die Sense erst mal auf Englisch umstellen. Die Floating Rules heissen auf Deutsch tatsächlich "globale Regeln".
hmm, hat glaube ich nichts gebracht die Aktion. Die kommen immer noch durch.
Ja, natürlich musst Du die beiden unteren Regeln rausnehmen. Und Apply drücken.
Bedenke, dass eine neue Blockregel bereits existierende Verbindungen nicht beeinträchtigt. Wofür OPNsense bereits einen State in der Tabelle hat, funktioniert solange dieser existiert.
Die entsprechenden States müsstest du manuell löschen.
Quote from: MarroniJohny on September 22, 2025, 01:40:45 PMOkay, danke. Versuche es nun über spezielle Port Forwarding Rules. Wäre das so richtig? Und muss ich da die beiden unteren Plesk Regeln mit * als Source noch raus löschen, nehme ich an? Oder wäre das in den Floating Rules besser aufgehoben?
Floating Regeln und Interface Gruppen Regeln haben Vorrang gegenüber Interface Regeln. D.h. wenn du das mit eine Floating Quick Regel blockst, sollte die in jedem Fall zum Tragen kommen.
Hast du dir auch überlegt, ob es nicht sinnvoller wäre, eine Whitelist für den Zugriff zu erstellen, um nur gewünschten Quellen den Zugriff zu erlauben anstatt andere zu blocken?
Ja, hatte auch vermutet, dass die Regeln noch nicht greifen, weil die Verbindungen noch stehen. Hatte aus dem Grund den Plesk Server neu gestartet, dachte damit werden die Verbindungen gekappt. Reicht das nicht? Oder soll ich die Sense mal neu starten, greift die Regel dann?
Die beiden NAT Regeln mit den * Source Adresses habe ich jetzt einfach mal deaktiviert.
Whitelist kommt leider nicht in Frage. Ist ein Plesk, das zu einer Flugsimulator Community gehört. Da fliegen Piloten aus aller Welt mit. Hat z.B. auch ganz viele Verbindungen aus China. Die nerven z.T. auch hart rum im Sim, aber ich möchte da trotzdem niemanden bannen, der nicht wirklich was böses im Schilde führt. Sind wohl viele Kiddys dabei bei den Chinesen.
Vielen Piloten aus dem "Westen" wär das recht, wenn ich per GeoIP Keule mal gewisse Nationen ausschliessen würde. Aber sind wir ehrlich, irgendwann fliegt gar keiner mehr mit. Darauf würde ich gerne verzichten.
Die Website läuft zum grossen Teil extern, ist auch ein Plesk. Aber da habe ich gar keinen Zugriff auf Funktionen wie Jail oder gar einer vorgeschalteten Firewall. Aber Teile von der Website laufen auf meinem Homeserver, auf einem eigenen Plesk. Das spielt auch Reverse Proxy für weitere Anwendungen.
Um das Projekt geht es vor allem:
https://www.flugsimulatoren.ch/
Werde das aber schon noch per Floating Regeln lösen. Dünkt mich eleganter als die Lösung im NAT Bereich.
Quote from: MarroniJohny on September 22, 2025, 04:34:51 PMJa, hatte auch vermutet, dass die Regeln noch nicht greifen, weil die Verbindungen noch stehen. Hatte aus dem Grund den Plesk Server neu gestartet, dachte damit werden die Verbindungen gekappt. Reicht das nicht?
Nein, es geht um die Verbindungen, die OPNsense als Router hält.
Die können entweder aktiv durch den Client beendert werden oder sie laufen in den Timeout. Letzteres passiert aber nicht, wenn der Client immer wieder neue Pakete drüber schickt.
Also entweder die State Table in der OPNsense GUI löschen (Firewall: Diagnostics: States: Actions: Reset state table) oder neu starten.
Das im angehängten Screenshot funktioniert btw. nicht, zumindest bei meinem schweizer Käse. Habe erst die State Table gelöscht und den Plesk Server neu gestartet, dann die Sense komplett neu gestartet und den Plesk Server auch noch mal neu gestartet. Die betreffenden Clients sind immer noch online.
Kann es sein, dass es an meinem Router vor der Sense liegt? Fahre mit doppelt NAT, geht leider nicht anders. Bridged Mode kann der nicht, und von freier Routerwahl träumen wir hier nur ausserhalb der EU...
Quote from: MarroniJohny on September 22, 2025, 07:40:49 PMKann es sein, dass es an meinem Router vor der Sense liegt?
Solange der Router kein Masquerading (die Quell-IP auf die LAN-IP umsetzt, S-NAT) auf eingehendem Traffic macht, kann das nicht die Ursache sein.
Aber du kennst doch die Clients, also kennst du vermutlich auch deren Quell-IP. Ist diese Teil des Block-Alias?
Wenn ja, sollte die Block-Regel auch greifen. Die gibt es ja noch?
Nein, glaube habe kein SNAT eingerichtet. Das hatte ich mal auf der Zywall am laufen, um auf zwei verschiedene IPs raus gehen zu können. Aber bei der Sense hab ich das glaube ich noch nicht verbrochen, so weit ich weiss. Und beim Router habe ich einfach die Sense als Exposed Host eingetragen. Und Port 25 freigegeben.
Ja, die Clients die ich blocken möchte sind eben aus dem Subnet 81.30.107.0/24. Wobei müsste das korrekt nicht 81.30.107.1/24 heissen? Sry, bin echt nicht so der Netzwerkspezialist. Ist eh mehr Bastelbude hier, da ist die Firewall nur ein kleiner Teil von. Ja, im Moment ist der Alias auf URL/IP 81.30.107.0/24.
Block Regeln habe ich bislang noch nicht. Im Moment nur das NAT Ding, wo das Subnet davon ausgeschlossen sein sollte. Aber die sind weiter online.
Und kannst Du vielleicht zur obersten NAT Regel noch was sagen? Also Pilot Adress (mein LAN), wo da TCP 20,53 und 443 drin sind? Bin mir da auch nicht mehr sicher, was ich da damals gemacht hatte. Das hat mir wohl auch mal die KI empfohlen, aber weiss echt nicht mehr, aus welchem Grund. Die Anti_Lockout_Rule da. Keine Ahnung, wozu die gut sein soll.
Ah doch, bei outbond NAT hatte ich tatsächlich mal rum gewerkelt:
Mal eine dumme Frage: Was sind eigentlich die Plesk_TCP_Ports? Doch nicht etwa 80 und 443?
Quote from: meyergru on September 22, 2025, 09:15:47 PMMal eine dumme Frage: Was sind eigentlich die Plesk_TCP_Ports? Doch nicht etwa 80 und 443?
Doch schon, ja. Wieso?
Naja. Dann ist es ziemlich klar. Die Anti-Lockout-Regel, die eigentlich für die UI der OpnSense gedacht ist, erlaubt den Zugriff für jedermann. Die der NAT-Regel zugeordnete Firewall-Regel greift dann nicht mehr, es sind ja die selben Ports.
Also solltest Du vorzugsweise den Port für die OpnSense von 443 auf einen alternativen Port verlegen und die Weiterleitung von Port 80 auf 443 für das UI abschalten oder unter Firewall: Settings: Advanced -> Disable anti-lockout einschalten (aber dann musst Du natürlich vorher selbst für den möglichen UI-Zugriff aus dem LAN sorgen).
hmm, okay. Kann ich die Regel nicht einfach dahingehend umgestalten, dass ich da nur vom LAN (Pilot Network) aus zugreifen kann? Das würde mir eigentlich reichen. Vom WAN aus will ich gar nicht, dass die Sense erreichbar ist.
Genau das habe ich doch gesagt:
Quote from: meyergru on September 22, 2025, 10:19:47 PMAlso solltest Du vorzugsweise den Port für die OpnSense von 443 auf einen alternativen Port verlegen und die Weiterleitung von Port 80 auf 443 für das UI abschalten oder unter Firewall: Settings: Advanced -> Disable anti-lockout einschalten (aber dann musst Du natürlich vorher selbst für den möglichen UI-Zugriff aus dem LAN sorgen).
P.S.: Die Regel selbst kannst Du nicht "umgestalten", drück mal auf den Edit-Button und schau selbst, wohin Dich das führt...
Okay, musste da ellenlang mit der KI hin und her diskutieren, wieso da meine NAT Regel nicht zieht, und was das mit meiner Anti_Lockout_Rule zu tun hat. Habe das aber mittlerweile verstanden denk ich.
Aber kann ich jetzt mal bevor ich den Port zur Sense ändern muss (wtf?) wenigstens mal monitoren, auf welchen Dienst es die netten Ukrainer abgesehen haben? Die sind da weiterhin fleissig am Werk...
Den Web GUI Port auf einen zu ändern, der nicht anderweitig genutzt wird, ist grundsätzlich zu empfehlen.
Warum die Anti-Lockout Regel am LAN irgendetwas vom WAN öffnet, ist mir aber nicht klar. Eine solche Erfahrung hatte ich auch noch nicht gemacht. Ich hätte angenommen, dass sich diese ausschließlich auf eingehende Verbindungen am LAN Interface auswirkt.
Für die Problemanalyse mit Verbindungen und Datenverkehr ist Firewall > Diagnostic > Packet Capture geeignet.