Messages

Look back to post #37 if you do not want to use the forum search.

You do not tell anything about your IPv6 setup:

DHCPv6 or SLAAC? Which daemon(s) for both? Do your clients still get an IPv6 assigned? What gateway do they get?

Because it is a complex timing issue that manifests itself only under specific circumstances.

Ich glaube nicht, dass das ein Problem wird - laufende TCP-Sessions werden ja nicht unterbrochen. Die temporären Adressen werden stark überlappend eingesetzt - eine neue wird nur für neue Sessions genutzt, während die alten noch zur Verfügung stehen. Würde Deine IP plötzlich wechseln, wäre die Session ja ohnehin kaputt.

Echt? Ich habe keinen Hostwatch laufen. Es reicht doch völlig, wenn ein IPv6-Paket die OpnSense erreicht oder passiert, dann wird der Neighbor Cache doch auch gefüllt? Klar, Hostwatch merkt es schneller, aber der Sinn ist ja die Verwendung in Firewall-Regeln und die können sowieso nur greifen, wenn Unicast-Traffic über die Firewall läuft.

Das schrieb ich doch - Du bringst zwei Themen zusammen, die nichts miteinander zu tun haben:

b. MAC Address - die haben nichts mit einer temporären IPv6-Adresse zu tun. In pf werden sie einfach direkt verwendet und sie sind vollkommen invariant gegen etwaige Präfixwechsel. Du kannst sie in IPv4- und in IPv6-Regeln verwenden und zwar ein- und ausgehend.

Das heißt: Wenn hMx1 ein "MAC Address" Alias ist, dann wirkt er unabhängig davon, mit welcher IPv6 oder IPv4 das Paket daherkommt. Dazu wird nicht direkt die MAC, sondern per ARP oder NDP alle zugehörigen IP-Adressen genutzt. Das klappt natürlich nur bei "lokalen" Paketen, versagt aber bei gerouteten.

Und Du hast Recht: da die NDP-Tabellen im Hintergrund gescannt werden (filterdns), kann es sein, dass sogar MAC-basierte Aliase verzögert greifen. In der Praxis ist das nicht so relevant, weil die Privacy Extensions typischerweise nur alle paar Stunden wechseln.

Und wie gesagt: Inbound ist das ziemlich irrelevant, weil man die Ziel-IP des Clients ja auch erstmal kennen müsste, weshalb man dort ja typischerweise die parallel existierende Management-IP nutzt. Das Problem entsteht also tendenziell bei ausgehenden Verbindungen, bei denen Privacy Extensions genutzt werden.

Es gibt ja zwei Typen von Firewall-Aliasen, die Du einsetzen kannst:

a. Dynamic IPv6 Host - dabei legst Du nicht wirklich die MAC-Adresse zugrunde, sondern die niedrigstwertigen 64 Bits plus den Präfix des gewählten Interfaces. Die 64 Bits können die aus der MAC gebildete EUI-64 sein, wenn SLAAC genutzt wird oder ein fixer Wert bei DHCPv6 oder auch ein zufällig gewählter, persistenter Suffix bei Windows oder auch eine wechselnde temporäre Adresse bei Privacy Extensions. Nur: Bei IPv6 gibt es jeweils beliebig viele Adressen. Normalerweise existiert die "feste" IPv6 (management address) neben den temporären. Für eingehende Regeln müsste man sowieso die "festen" IPs verwenden, weil man die temporären ja überhaupt nicht kennt. Eine Änderung bekommt die OpnSense auch nicht mit und von außen wären solche Addressen ja auch nicht per DNS bekannt. Für Regeln, die den Zugriff nach außen regeln sollen, ginge das auch überhaupt nicht.

b. MAC Address - die haben nichts mit einer temporären IPv6-Adresse zu tun. In pf werden sie einfach direkt verwendet und sie sind vollkommen invariant gegen Präfixwechsel. Du kannst sie in IPv4- und in IPv6-Regeln verwenden und zwar ein- und ausgehend. Ich verwende diese Aliase deshalb sehr gerne, wenn ich konkrete Clients mit Sonderrechten ausstatten will.

Im Grunde sind das also zwei Fragen:

1. Wie benenne ich zuverlässig Clients für Firewall-Regeln (in beiden Richtungen)?
2. Wie mache ich diese Clients "addressierbar" oder für Monitoring-Zwecke "erkennbar" (i.S.v. reverse lookups)?

Yes, it is a strange thing that opening CSV files without the specific CSV dialogue in Excel shows each row as being one text column only. To fix this, you need to import the file properly. In the English version of Excel, use the following menu path: Data > From Text/CSV (located in the Get & Transform Data group)

[running on top of the latest Proxmox version 9.2.4]

Opnsense is running on top of the latest Proxmox version 9.2.4, using SeaBIOS and UFS2 filesystem.

...which in turn prevents a CPU microcode update in a VM for security reasons, so that is useless, if not even harmful. If you want the upgrade, install "intel-microcode" under PVE and uninstall the OpnSense plugin. That is one of the first recommendations here.

@(MARLOO):

So I understand what you are essentially answering to this "call for testing": "No, thank you, I am not going to test the potential fix, but rather wait for other people's confirmation that the fix works and only then apply it with the next hotfix."?

How clever. (Sorry for being a bit harsh)

P.S.: The whole point of this thread is to gain knowledge if the presumed fix works for affected people, so just you know.... the only reason I did not try is that I do not experience the problem myself even with early microcode loading.

https://forum.opnsense.org/index.php?msg=243083

However, the process is different for BIOS and UEFI boot, sometimes it depends on the type of boot disk and / or partitioning.

This is the reason why there is no automatic bootloader update (or upgrade of zpool options, FWIW). And if you want to update like depicted in the link, you need to have booted the NEW system first, which sometimes does not work, so it is a catch-22. That is why Franco wrote:

Doesn't change the fact that everyone including 26.7 would be affected either way by it unless they did a clean reinstall.

Naja, man kann bei Deciso ins Regal greifen, um eine spezialisierte Appliance zu bekommen, die eben 7.9 GBps Threat Protection Durchsatz hat bei gleichzeitig niedrigem Stromverbrauch (DEC3920) oder irgendwas im Server-Bereich als 19"-Rack-Lösung (dann aber Performance) oder selbst bauen auf Basis aktueller High-End-Prozessoren. Die meisten Desktop-Plattformen könnten dann eben kein ECC-RAM, alternativ brauchst Du Server-CPUs und Mainboards, die fast ebenso teuer sind wie fertige 19"-Server von Dell.

Was auch in Frage käme, wäre so etwas: https://minisforumpc.eu/de/products/ms-a2-mini-pc, da reichen eventuell auch die kleineren CPUs, da die Single-Thread-Leistung entscheidend ist.

Ich zweifele aber ohnehin daran, dass das wesentlich günstiger als mit einer DEC3920 geht. Selbst die kann z.B. bei Wireguard nur ca. 4 Gbps. Es gibt noch fettere Lösungen, ich habe aber damit keine Erfahrungen - bei mir reichen 10 Gbps geroutet im Intranet und 2 Gbps im WAN. Außerdem nutze ich keine DPI-Lösungen.

Je nach Größe des Regelsatzes wirst Du da um Enterprise Hardware kaum herumkommen, wenn Du den Speed wirklich ausnutzen willst. Suricata braucht hohe Single-Core Performance, mit Mehrkern-Server-Prozessoren mit niedrigen Frequenzen kommst Du da nicht weit. Das wird laut und energiefressend.

Der N355 bietet keinen sehr hohen Grundtakt, wird das bei größeren Regelsätzen einbrechen.

See: https://forum.opnsense.org/index.php?topic=52441.0

See: https://forum.opnsense.org/index.php?topic=52441.0