Messages

Great tips, thanks! Yes, I am hoping to get at least 4 ports, or a mini PC with a full PCIe slot that would let me add a 4+ port Intel NIC. I'm leaning towards the latter currently, as it offers me some ability to update components as time goes on.

I would refrain from a modular PC unless it is really great with power efficiency (most are not). The dedicated firewall boxes have less unneeded components, like audio chips and stuff. Your firewall is a 24/7 device where it makes a difference if it draws 10 Watts more or less. Also, AFAIK, 4-port Intel PCIe cards have 1 Gbps only, whereas most china firewall boxes have 4x I226V with 2.5 Gbps build in.

Ja. Dann brauchst Du aber auch keine ULA - Du würdest ja nur die IPv6 der OpnSense erreichbar machen und den Rest per Reverse-Proxy oder bei sehr speziellen Anwendungen NAT64 in eine DMZ (was sowieso für exponierte Geräte und Services eine gute Übung ist).

Die anderen Geräte können auch intern ruhig GUA benutzen, die Firewall blockt ja den Zugriff von außen (abgesehen davon, dass man die internen GUAs nicht erraten oder scannen kann, selbst, wenn man den Präfix kennt - 2^64 IPs sind ein bisschen zu viel zum Raten).

Für Android-Geräte gibt es m.W. inzwischen auch die Möglichkeit der MAC Randomization und wie gesagt, die IP ist inzwischen nicht mehr das relevante Kriterium zum Erkennen eines spezifischen Geräts.

[Link 2 (eth0)]

Linux (Ubuntu 24.04.3 mit systemd-resolvectl) ja:

#resolvectl status
Global
        Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
Current DNS Server: 192.168.10.2
      DNS Servers: 192.168.10.2
        DNS Domain: xxx yyy zzz

Link 2 (eth0)
    Current Scopes: DNS
        Protocols: +DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.10.2
      DNS Servers: 192.168.10.2 fe80::1
        DNS Domain: xxx yyy zzz


Bei iOS und Android ergibt sich die Frage praktisch nicht - mit wie vielen WLANs will man gleichzeitig verbunden sein? In meinem iPhone habe ich keine Scope-ID gesehen, für das Gateway allerdings auch nicht.

Das stimmt so nicht:

Die Scope ID wird beim Gateway auch nicht mitgegeben - geht ja auch nicht, weil der SLAAC- oder DHCP-Server die Scope ID des Clients ja nicht kennt. Der Client erzeugt sich die selbst anhand des Interfaces, wo er die Angabe herbekommt. Gerade eben probiert mit RADVD und "fe80::1" als DNS-Server. Ergebnis unter Windows:

You cannot view this attachment.

Dafür bräuchte es überhaupt keine ULA, die LL-Adresse würde ja genauso funktionieren, genauso wie für das Gateway. Mal ganz abgesehen davon, dass der DNS-Server genauso gut per IPv4 genutzt / adressiert werden könnte - aber falls sowohl IPv4 als auch IPv6 angegeben werden, ist die Frage, welcher Server dann genutzt wird, undefiniert. All das gilt für Dual-Stack.

ULAs werden normalerweise nicht wegen der Angabe des DNS-Servers, sondern in dem Bestreben genutzt, bei dynamischen IPv6 Präfixen und gewünschtem weitgehenden Verzicht auf (legacy) IPv4 eine DNS-Eintragung vornehmen zu können - weil das mit den (dynamischen) GUAs eben nicht geht. Meine Bemerkung wies lediglich darauf hin, dass genau das bei Dual-Stack trotzdem nicht funktioniert, weil IPv6 ULAs bei gleichzeitiger Verfügbarkeit von IPv4 für DNS-Einträge aufgrund der geringeren Priorisierung gar nicht genutzt werden (viele denken, IPv6 würde "immer" vorgezogen - dem ist nicht so).

Kurz gesagt: Die Verwendung von ULA wird bei dynamischen IPv6-Präfixen immer als "Lösung" angepriesen, funktioniert aber bei Dual-Stack nicht, sondern nur mit IPv6-only.

I would not recommend N1x0 boxes with only two ports:

a. those often tend use Realtek chips, unlike their 4 or more port equivalents, which mostly use Intel I226V. Also, they often are actively cooled.
b. If you want to set up VLANs, you will want to have inter-VLAN traffic at full 2.5 Gbps speed, for which you need multiple physical 2.5 Gbps (V)LAN ports. Thus, two ports will not suffice.

Probably a fake value reported because the smart API wants "something".

...which by default allow any to any for any IP protocols on LAN? ;-)

Can you elaborate? I don't understand what you're referring to, specifically.

In the default configuration, OpnSense comes with a preinstalled "allow any -> any" rule for the first LAN interface. Without it, you initially would not be able to access either the internet or the firewall itself. When people create another VLAN, in 99% of the cases, the first question they come up with is: "Why is it that I cannot access the internet from my second VLAN?" It is because they did not create a similar rule on that new VLAN.

Richtig.

Beispielsweise kann man mit dynamischen IPv6 nur sehr schwer DNS-Eintragungen machen - dazu braucht es ja bekannte IPs. Meist wird dann empfohlen, für den internen DNS ULAs zu verwenden, was aber wiederum bei Dual Stack nicht funktioniert, weil die IPv4 höher priorisiert werden als ULA IPv6, wie bereits dargestellt.

Die Identifizierbarkeit eines Clients (z.B. in Firewall-Logs) anhand der IPv6 könnte man mittels DHCPv6 auch leicht erreichen. Ist mit dynamischen IPv6 de facto ausgeschlossen, weil die Leases mit DHCPv6 ggf. zu lange gültig wären. Das ist ja der Grund, wieso ich im IPv6 HowTo SLAAC-only vorschlage. Nur geht damit wieder keine DNS-Registrierung und die IPs sind quasi zufällig.

Selbst Firewall-Regeln für IPv6 kann man nur mit zwei Tricks machen: Entweder dynamische IPv6 Aliases, die auf bekannten EUI-64 basieren (was wie bereits diskutiert bei Windows, IOS und Android nur mit speziellen Einstellungen geht, wenn man SLAAC macht) oder, man macht Firewall-Regeln für IPv6 auf Basis der MAC...

Von Docker mit IPv6 und dynamischen Präfixen ganz zu schweigen. Wer mal versucht hat, mit Uptime Kuma eine IPv6 zu überwachen, weiß, was ich meine: geht nur per Proxy.

Alles blöde Ausweichlösungen, um nicht vorhandene statische Präfixe irgendwie zu umschiffen - und funktionieren tut es nur sehr bedingt. Mit statischen IPv6-Präfixen und DHCPv6 wäre das alles kein Problem. Dann rückt - bis auf LAN-Serverdienste (die DS-fähig sein sollten) und eine notwendige Brückenlösung für IPv4 im Internet - sogar IPv6-only im LAN in Reichweite.

Also ich hatte noch kein solches Konstrukt, aber:

Wenn das SIP-WAN auf 172.x.x.x/y liegt, müsstest Du zunächst mal eine Route dorthin haben, was automatisch der Fall sein wird, wenn das SIP-WAN-Interface eine IP in diesem Subnetz zugewiesen bekommt. Ich würde jetzt mal davon ausgehen, dass ngn.enviatel.net auch auf eine IP in diesem Netz aufgelöst wird, so dass Du diesen Namen in Deinem SNOM als SIP-Gateway eintragen kannst, um das SIP-Gateway zu erreichen. Das sollest Du aber checken. Falls das Gateway nämlich nicht im Subnetz liegt, musst Du ohnehin eine zusätzliche Route für das SIP-Netz anlegen, sonst würde ja das Default (WAN) Gateway genutzt, was kaum funktionieren dürfte.

Nur: Die Route zurück vom Gateway in Dein SIP-LAN würde nicht funktionieren, weil Dein ISP ja keine Route zu 192.168.20.0/24 kennt. Deshalb musst Du outbound NAT für das Interface einrichten, so dass sich alle SIP-Geräte hinter der SIP-WAN-Interface-IP der OpnSense "verstecken".

Am Rande bemerkt klingt 172.x.x.x/y verdächtig nach RFC1918, so dass das auf dem betroffenen Interface nicht geblockt werden darf (Checkbox nicht gesetzt).

Depending on your local keyboard layout, you may even see problems with special characters or switched Y and Z when you change between console and web interface.

Das wird bei der Verschleierung der IPv6 kaum helfen, wenn die ersten 64 Bits der nach außen sichtbaren IPv6 immer die selben sind.

Trotzdem kaufe ich das Privacy-Argument nicht wirklich, weil die IP schon länger nicht mehr das entscheidende Kriterium ist, beispielsweise eine spezifische Browser-Instanz zu identifizieren, siehe hier (Mobile Device ID) oder hier (Browser fingerprinting), von Cookies mal ganz zu schweigen. Schließlich ist die IPv4 ja auch meist volatil.

Ich stimme @Maurice zu, ich hätte trotz Privacy-Erwägungen lieber feste IPs - insbesondere bei IPv6.

[Andere]

Andere Lösungen heißt zumindest bei mir: zusätzliche Lösungen. Ich habe kein Problem damit, die Mechanismen von IPv4 auf IPv6 umzustellen, wenn das aber bedeutet, für alle möglichen Features zusätzliche Mechanismen oder spezifische Geräte-Konfigurationen (Umstellung von DHCP-Verhalten am Server, Registry-Edits auf Windows-Clients, Umstellungen an Android und/oder IOS-Geräten, separate IPv4- / IPv6-Netze) einsetzen zu müssen, bin ich aus Aufwandsgründen raus - für mich persönlich besteht der Ansatz dann den Lackmustest nicht. Mal ganz abgesehen davon, dass zumindest Ubuntu 24.04.3 und Windows 11 Professional die DHCP Option 108 einfach ignorieren.

Das mag in Business-Umgebungen anders sein, wo AD, LDAP, Windows-Domänen, 802.1x oder IPAM sowieso schon am Start sind. Bei mir ist das mit "IPv4 im LAN" und "IPv6 outbound only" aber anders: Da brauche ich - und zwar nur auf der OpnSense - eine einfache Zuordnung MAC -> IPv4 -> DNS-Einträg(e) und kann damit alles erschlagen.

Es wäre wahrscheinlich auch anders, wenn sich die ISPs nicht auf diese blöde dynamische IPv6-Zuweisung eingeschossen hätten oder langfristiger, wenn IPv6-only eine echte Option darstellt.

@n3: Im RADVD (falls Du den nutzt) kannst Du die Option "Do not send any DNS configuration to clients" setzen - wie gesagt, ich nehme nur SLAAC, keinen DHCPv6. Damit kommt dann kein DNSv6-Server mehr an. So auch das oben verlinkte HOWTO. Das funktioniert - alles, was wir hier diskutieren, ist offenbar komplexer als man sich das so zuerst vorstellt. Mir fehlt bislang jedenfalls das HOWTO, das das lückenlos beschreibt.

Und: Die ULA wird bei DS-Betrieb nie verwendet, solange der Name auch auf eine IPv4 auflöst... das würde m.E. nur mit IPv6-only funktionieren, nicht mit IPv6 mostly. Solange Du dynamische IPv6-Präfixe und IPv4-only Clients hast, wird das nix.

@Patrick: Ich nutze weder Windows-Domänen noch DHCPv6. M.W. unterstützen Android-Clients (und manche andere) auch nur SLAAC für die IPv6-Zuweisung - ich weiß allerdings nicht, ob das aktuell immer noch so ist. D.h., aktuell arbeite ich mit einer festen Reservierung MAC -> IPv4. IPv6 wird eigentlich nur für Outbound genutzt, inbound nehme ich sowieso meist einen Reverse Proxy, deshalb brauche ich da die IPv6 selten.

Oha. Da kommt aber (theoretisch) viel Arbeit auf einen zu, wenn man dem internen DNS die IPv6 (und zwar aus den genannten pragmatischen Gründen ULAs) hinzufügen will:

a. Wie ich gerade feststelle, wird die IPv6 bei Windows aus einer (zufälligen) DUID abgeleitet. Das bedeutet, ich kann die ULA nicht einmal aus den vorhandenen MAC-Daten für die DHCPv4-Reservierungen ableiten. Es sei denn, ich ändere auf den Windows-Clients per Registry-Setting die Einstellungen so, dass die Ableitung aus der MAC erfolgt, so dass man zumindest die EUI-64 vorab zentral kennt. Das könnte im Extremfall bedeuten, dass ich die DNSv6-Einträge alle nochmal händisch erfassen muss, nachdem ich auf jedem Client die tatsächliche ULA ausgelesen habe. Keine Ahnung, wie Android das macht, aber IOS nimmt m.W. auch eine zufällige EUI-64, wenn man es nicht abschaltet (und das nicht nur für ausgehende Verbindungen mit privacy extensions).

b. Automatisiert kann man die Einträge sowieso nicht so einfach erzeugen, weil man für Nicht-IPv6-fähige Geräte und Services keine DNSv6-Einträge machen will - sonst würden die IPv6-only Clients auf Fehler laufen, weil sie ja dann bevorzugt IPv6 versuchen würden. Wobei: das gälte nur für GUAs, siehe nächster Punkt.

c. Bei ULAs ist es so, dass die ja überraschenderweise niedriger priorisiert werden als IPv4. Wenn also beide Einträge existieren, bringt das rein gar nichts, denn die IPv4 wird der ULA IPv6 immer vorgezogen. IPv4-only Clients nehmen sowieso nur IPv4, und solange diese noch existieren, werden die IPv4-DNS-Einträge auch noch gebraucht - es wäre nicht einmal eine Option, die Einträge exklusiv nur für IPv4 oder IPv6 zu machen.

d. Differenzieren müsste man für echte Services sowieso, denn wenn die per DHCP-Option 108 IPv6-only gesetzt werden, sind sie für IPv4-only Clients nicht mehr erreichbar. M.W. unterstützt Kea DHCP auf OpnSense eine Client-spezifische Steuerung der Option 108 nicht - solche Services müssten also statisch auf Dual-Stack konfiguriert werden.

Ergo: Alle Clients nutzen sowieso nur den IPv4-Teil des DNS-Eintrags. Dann kann ich mir die lokalen IPv6-Einträge im DNS also gleich sparen.

Offenbar wird das also nix bei mir mit "IPv6-mostly" - m.E. klappt das erst gut mit "IPv6 only".

Sorry für Off-Topic, aber wie gesagt, ich versuche nur gerade, das Big Picture zu erfassen (die klassische Version mit internem IPv4 kenne ich).