MAC addresses Alias - wie zuverlässig mit Temporary IPv6 Addresses?

[Bob.Dig]

Hab mir gerade die Doku dazu angeguckt und (aus Gründen) selbst (noch) nicht ausprobiert.
Wie zuverlässig funktioniert das? Wenn z.B. eine temporäre IPv6-Adresse gerade durch einen Windows-Host generiert wurde, klappt dann der Verbindungsaufbau, wenn eine entsprechende Erlauben-Regel mit einem solchen Source-Alias genutzt wird? Oder kann es bis zu 5 Minuten dauern, bis der Alias aktualisiert wird.

[meyergru]

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)?

[Bob.Dig]

Hallo meyergru! Mir geht es nur um den Sachverhalt wie beschrieben. Du bist da irgendwie weit von abgeschweift.
Vielleicht verdeutlicht ein Bild noch, von was für einer Regel ich spreche. ;)
Also die Frage ist, wird der Alias schnell genug aktualisiert, so dass es in der Praxis keine Unterbrechungen durch Blocking gibt.

[meyergru]

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.

[Bob.Dig]

Du bringst zwei Themen zusammen, die nichts miteinander zu tun haben

Nope.

kann es sein, dass sogar MAC-basierte Aliase verzögert greifen.

Nur darum ging es mir, danke trotzdem.

Wer hierzu praktische Erfahrungen hat, gerne hier posten, z.B. ob Webbrowsing manchmal deswegen nicht klappt etc.
Oder wer die genauen Details kennt, wie häufig dieser Alias aktualisiert wird. Vielleicht ist es ja praktisch gar kein Problem. 

[Monviech (Cedrik)]

Der Alias wird einmal pro Minute aktualisiert (es gibt einen Cron job, kannste mit "crontab -e" sehen. filter_update_tables)

Die Quelle des Alias ist Hostwatch. Das bedeuted Hostwatch muss an sein, damit die privacy Extension IPv6 Addressen erkannt werden. (Interfaces -> Neighbors -> Automatic Discovery).

Wenn ein Host eine neue Privacy Addresse generiert, sendet er ein DAD Paket, dieses wird von Hostwatch erkannt und die MAC->IPv6 Addresse wird gemapped (Discovered Hosts). Dieses Paket wird nur einmal gesendet pro neuer Addresse, wenn es irgendwo verloren geht dann wird sie nicht gelernt.

[meyergru]

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.

[Monviech (Cedrik)]

Der Vorteil bei Hostwatch ist dass es in einer persistenten Datenbank gespeichert wird. Selbst nach einem Reboot ist die temporäre IPv6 Adresse noch bekannt. Natürlich muss dann auch der Präfix der selbe bleiben, was aber ein anderes Problem ist.

Ich glaube nicht, dass der MAC alias beim NDP parsen zwischen STALE und REACHABLE unterscheidet. Hier hat NDP nämlich einen 30 Sekunden timeout.

Ich denke es ist also alleine der unterschied zwischen Runtime vs Datenbank.

Noch komplizierter macht es, dass der letzte bekannte Status eines alias in einem cache gespeichert wird auf der Festplatte, das bedeutet theoretisch kennt der MAC Alias nach einem Reboot immer noch den alten Status, auch ohne Datenbank.

Aber wie man sieht gibt es hier viele mechanismen die voneinander Abhängig sind.

Am meisten Sinn ergibt die 1 Minute aktualisierungsrate, die den Alias "langsam" machen kann wenn eine neue Addresse kommt.

[Bob.Dig]

Am meisten Sinn ergibt die 1 Minute aktualisierungsrate, die den Alias "langsam" machen kann wenn eine neue Addresse kommt.

Danke für die Klarstellung, Cedrik. Also ist im Optimalfall eine Spanne von bis zu einer Minute, was hier Probleme machen könnte.

Habe jetzt mal Interfaces: Neighbors: Automatic Discovery aktiviert.

*      *      *      *      *      (/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py --quick) > /dev/null

Hat den wer praktische Erfahrungen mit dem Szenario aus dem Startpost? Was passiert überhaupt bei Dual-Stack, wenn IPv6 (mal kurz) nicht erreichbar ist, wird vom Browser automatisch auf v4 gewechselt, so dass man eher nichts merkt? An sich ist die Lösung ja schon schön, wäre da die Minute nicht.
Wobei bei Online-Games wäre eine Minute downtime eher nicht zu rechtfertigen. ;)

[meyergru]

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.

[Bob.Dig]

laufende TCP-Sessions werden ja nicht unterbrochen.

Sehr guter Punkt!!
Will das irgendwann mal testen. :)