Messages

Hallo zusammen,

gibt es hierfür schon einen Fahrplan bzgl. Patch?

https://www.heise.de/news/chwoot-Kritische-Linux-Luecke-macht-Nutzer-auf-den-meisten-Systemen-zu-Root-10466885.html

Mein checkMK meckert auch schon:
Pkg: sudo vulnerable

Danke!

Gruß

Even if suricata is not enabled on my firewall, I had to change the interface from WAN to something different and after a reboot the problem went away and IPv6 is working. This is strage behaviour, because when a plugin is not activated it should not pay attention to its settings.

Hey,

I only use one ISP and have the issue, even if suricata is not enabled:

I´m facing the same problem. I was running IPv6 for over one year with any problem. Yesterday, after a reboot (without any config change, last update was a week ago without any reboot), IPv6 is not working anymore. My CheckMK is read on IPv6-Checks. After reboot IPv6 is working for some minutes and then it´s not working anymore.

Fun fact: I don´t have suricata activated. In which log did you find the problem?

I see IPv6 is assigned on the interfaces correctly. Even on my clients, I see the correct IPv6, but it doesn´t get through. Browsing wieistmeineip.de only gives me back my IPv4.

Any idea what it could be?

Hallo zusammen,

bei mir wurde vor kurzem der HÜP inkl. ONT gesetzt. Da ich aber den ONT nicht nutzen will, sondern die Glasfaser direkt in die Firewall stecken möchte, brauche ich ein SFP+ Modul.
Mein Anbieter wird o2 in Verbindung mit UGG sein. Durch Recherche habe ich herausgefunden, dass es mit diesem Modul gehen soll: https://www.luleey.com/product/2-5g-xpon-stick-sfp-onu/

Hier habe ich auch eine Konfigurationsanleitung gefunden: https://ubiquiti-networks-forum.de/wiki/entry-pdf-export/124-warum-ben%C3%B6tigt-man-zugriff-auf-das-sfp-gpon-modul/

Das Ganze wurde immer mit einer Dream-Machine getestet. Hat einer Erfahrungen ob es auch mit einer Deciso 3860 so funktionieren sollte?

Gruß

Hello

I waited until today for the update to 24.1.9, including the hotfix (_1), and I confirm that it has rewritten my one-to-one entries by changing my 'destination' addresses.
Basically, 'Internal' and 'Destination' were bearing the same thing.

I did the update from 24.1.8

I manually edited the entries with the correct destinations.
Regards

I did the same this morning and cannot confirm this behaviour with 24.1.9_3

Nach intensiven Tests mit Franco kann ich bestätigen, dass mit dem Hotfix 24.1.9_3 nun alles funktioniert wie es soll.

After intense testing with Franco I can confirm, that everything works with the hotfix 24.1.9_3

Hey Franco,

just sent you two diffs to your provided mail address.
Sorry I was working during the day and I thought you already found the issue because you provided the hotfix. This was the reason why I didn´t send to you anymore.

I hope you find the reason.

I think it is this:

New:
<destination_net>any</destination_net>
Old:
-      <destination>
-        <any>1</any>

The syntax changed.

Hallo wirehire,

ist bei mir das gleiche. Die externe IP wird in der Übersicht nicht mehr angezeigt, sondern nur in der Bearbeitungsübersicht, ist wohl ein Anzeige-Bug.
Des Weiteren wird die Destination (in meine Fall war es "any") gleichgesetzt mit der IP aus Source (dort hatte ich zuvor auch eine 10er-IP mit /32). Somit wird während des Updates Daten geändert, was man erst mal finden muss.
Ich habe die Erkenntnis nun auch im englischen Thread gepostet.

Lange Rede, kurzer Sinn: Ich weiß nicht ob hier wirklich eine Rule das Problem war oder die falsch überschriebenen Einstellungen während des Updates (bekomme ich jetzt aber auch nicht mehr nachgestellt).
Fakt ist: Das Hotfix auf 24.1.9_1 funktioniert selbst dann nicht ohne manuellen Eingriff, wenn man von 24.1.8 kommt (hatte ja den Snap zurückgespielt).

Gruß

Quick feedback, because I tried the hotfix:

After applying the update I had again the problem, that IPv4 was not reachable.
I saw, that under 1:1 NAT the destination of my entry was not "any" anymore and was filled with the same IP like in source (which was also set before and is correct). This is not correct and the update set the wrong value for destination which wasn´t present before.
Additionally there is also a display error.
The external IP address is not shown in the overview of the 1:1 NAT-rules. You just see it, when you click the edit button of the corresponding 1:1 NAT-rule

In my opinion, the update should not change the destination value from "any" to the same IP-address like in source. And the external IP address should also be shown in the 1:1 NAT overview.

At the moment I don´t know if the hotfix really helped in my case. Maybe I could have reached the same result without the hotfix if I changed the settings before to the correct values. But this is speculation.

I just wanted you to give the feedback that the hotfix didn´t solve anything without touching.

Hier gehts im englischen Thread weiter, Franco ist schon dran: https://forum.opnsense.org/index.php?topic=41122.0

Thanks for investigating Franco. I will wait with any further update :)

Yes I exactly also think, that this is the cause.
I also started a topic in the German forum. I restored a snapshot of my OPNsense (it runs within Proxmox).
I´m just curious what new rule is needed to get it working again with the new version.

see: https://forum.opnsense.org/index.php?topic=41119.0

P.S.: Nach dem Update sehen die automatic Rules im Outbound-NAT genauso aus wie vorher. Ich verstehe gerade nicht, was da weggeflogen ist. Ich habe das gleiche Verhalten wie im Englischen Thread, dass es auf der Firewall an kommt, anstatt auf der Ziel-VM.

Folgende Einstellungen habe ich entdeckt, aber die waren auch schon immer so (siehe Screen).

Auch finde ich es komisch, das wohl nur TCP betroffen ist, UDP aber in Ordnung zu sein scheint. Zumal ich Port 54 TCP/UDP in einer Regel auf WAN habe (natürlich von der Source-IP eingeschränkt).