veloc1ty · ʎʇƖɔolǝʌ

Links:

Each icon is taken from the providers trademark page.

Content licensed under CC BY-SA 4.0 - Powered by Hugo and a customized Hyde-X template

pfSense/OPNsense: IPv6 Delegation hinter Fritz!Box - 2019 Version

Sunday, May 26 2019 · Lesezeit: 13 Minuten · 2748 Wörter Achtung! Dieser Artikel ist älter als ein Jahr. Der Inhalt ist möglicherweise nicht mehr aktuell!

Dieser Artilel ist ein Update zu meinem Artikel von 2015. Dieser Artikel wird technischer und setzt Kenntnisse im IPv6 Umfeld voraus. Ich habe vor einiger Zeit auf OPNsense umgestellt. Die pfSense konfiguriert sich aber ähnlich. Im Artikel werden aber OPNsense Screenshots gezeigt.

Netzübersicht

Mein Provider und Arbeitgeber stellt mir an meinem VDSL Anschluss eine Fritz!Box 7590 zur Verfügung. Diese ist aktuell noch im Router Modus. Die Fritz!Box macht auf deren WAN Seite DHCPv4 und DHCPv6 mit einer öffentlichen IPV4 Adresse und einem /56 IPv6 Prefix. Auf LAN Seite liegt ein privates /24 IPv4 Netz an.

Auf meinem Homeserver virtualisiere ich mit KVM Gäste und LXC Container. Ein wichtiger KVM Guest ist meine OPNSense.

Eine Separierung der einzelnen Layer 2 Netze habe ich einen Cisco SG-350 Switch. Dieser ist VLAN fähig. Folgende VLANs habe ich definiert:

VLAN Bezeichnung Bridgename am Homeserver Typische Clients
2 WAN brWAN In diesem Netz sind die LAN-Seite der Fritz!Box und die WAN Seite der OPNSense.
3 LAN brLAN In diesem Netz befinden sich meine Endgeräte. Dazu gehört zum Beispiel: Handy, Tables, Fernseher, NAS, etc. Als quasi lauter physische Geräte, denen ich vertraue.
4 DMZ brDMZ In diesem Netz sind Server angesiedelt, die Dienste erbringen oder aus dem Internet angesprochen werden können. Ein Beispiel ist mein eigender DNS-Server und -Resolver. An der Firewall gibt es eine Regel, die zum Beispiel den LAN Clients erlaubt den DMZ DNS abzufragen. Von DMZ in ein anderes Netz gibt es aber keine Regel und eventueller Traffic wird gedroppt.
5 GUEST brGUEST Gastnetzwerk von meinem öffentlichen WLAN. Die Clients in diesem Netz dürfen nur ins Internet. Via DHCPv4 bekommen diese Clients auch nicht meinen eigenen Resolver zugeteilt, sondern benuten den Google DNS Server.

Mein Homeserver ist via einem Trunk Port angebunden und ist erstmal in allen VLANs angesiedelt. Auf dem Archlinux gibt es dann jeweils für jedes VLAN ein Interface. Jedes dieses VLAN Interfaces ist wiederum an einer Bridge angebunden. KVM Gäste und LXC Container binden sich dann an die jeweilige Bridge und sind so zu jedem Zeitpunkt transparent via Layer 2 an ein VLAN gebunden.
Die OPNSense hat für jedes Netzwerk ein dediziertes Interface und mischt an jeder Bridge mit. Die OPNSense ist Router und Firewall. Eine Kommunikation zwischen zwei Layer 2 Netzen wird durch die VLANisierung ausgeschlossen. Traffic zwischen zwei Netzen muss über die Firewall.

Zur visualisierung ein schlechtes Bild:

Wer sich jetzt wundert: Ja, im IPv4 mache ich hier ein Doppel NAT. An der Fritz!Box ist allerdings die WAN Adresse der OPNSense als Exposed Host eingetragen. Deshalb habe ich hier wenig Probleme.

Plan

Mein Provider stellt nun endlich IPv6 an meinem Anschluss zur Verfügung. Dieses soll nun in meinem Netz integriert werden.

Einige Vorteile von IPv4 only waren:

Nachteile von IPv4:

Vorteile von IPv6:

Nachteile von IPv6:

Ein Hauwichtiger Security punkt ist die öffentliche Adresse. Ich möchte nicht, dass mein Android Handy aus dem Internet via IPv6 erreichbar ist. NAT hat in der IPv4 Welt die Clients vor externen Zugriffen quasi “geschützt”. Nun stellt sich die Frage, welches Gerät diesen Traffic filtern soll. Die Fritz!Box oder die OPNsense. Ich plane die Hauptlogik wieder auf die OPNsense zu legen.

Das bedeutet: Die Firewall auf der Fritz!Box soll komplett ausgeschaltet werden. Sozusagen ein Exposed Host, außer dass es nun ein komplettes deligiertes Netz ist.

Adressverteilung

Die Fritz!Box bekommt via DHCPv6 von meinem Provider ein semi-statisches /56 IPv6-Prefix. Das finde ich erstmal cool, denn ich kann quasi unendlich viele Subnetze rauslösen. Die Fritz!Box selbst hat ebenfalls einen DHCPv6 Server, der das zugeteilte Preix weiter aufspalten kann. Dieses Verfahren nennt man “Identity Association for Prefix Delegation” oder kurz “IA_PD” und ist im RFC 3633 spezifiziert. Ein Client kann via DHCPv6 einen gewisse Prefix Länge anfragen.
Wichtig: Wir reden hier nur von Prefixen. Anders als bei DHCPv4 werden keine einzelnen Adressen angefragt.

OPNSense soll auf dem WAN Interface ein /57 Anfragen. Also ein Bit mehr in der Netzmaske.

Die weiteren Interfaces (LAN und DMZ) sollen aus dem deligierten /57 Netz - dass ja nun an der OPNSense anliegt - neue /64 Netze rauslösen aus dem die Clients dann automatisch Adressen ableiten.

Schritte, die an der Fritz!Box durchgeführt werden müssen:

Schritte, die an der OPNSense durchgeführt werden müssen:

Konkrete Implementierung

DHCPv6 mit IA_PD anschalten

Login auf der Fritz!Box. Danach auf Heimnetz -> Netzwerk -> Reiter: Netzwerkeinstellungen. Dort runterscrollen zum Abschnitt “IP-Adressen”. Auf der rechten Seite ist ein Knopf mit dem Namen “IPV6-Adressen”.
In der Maske alles unverändert lassen bis auf den letzen Abschnitt. Dort muss der Radio Button “DNS-Server und IPv6-Präfix (IA_PD) zuweisen” ausgewählt sein. Hier ein Bild:

Danach unten auf “OK” klicken.

Firewall + Exposed Net für deligierte Netze anschalten

Nun muss nur noch die Firewall abgeschaltet werden. Dazu links im Menü auf Internet -> Freigaben klicken. Wenn dort schon ein IPv4 exposed Host ausgewählt ist, dann kann man diese erweitern. Ansonsten muss man diese Regel erst erstellen. Dazu muss man die MAC Adresse von der OPNSense kennen. Normalerweise ist diese schon in der Oberfläche auswählbar. Wichtig ist, dass alle IPv6 Haken an sind. Hier ein Bild:

Unten wieder auf “OK” klicken. Nun ist die Fritz!Box quasi handlungslos. Ohne Firewall würden nun alle unsere Adressen ungeschützt vor der NSA im Internet hängen.

DHCPv6 auf WAN aktivieren

Die OPNSense soll nun ein Prefix von der Fritz!Box angrangen. Spezieller gesagt: Ein /57 Prefix. Dazu öffnet man die Interface Settings für WAN. Dort setzt man IPv6 Configuration Type auf DHCPv6. Weiter unten gehen zusätzliche Optionen auf. Diese setzt man dann wie folgt:

Nach dem klick auf Save wird ein Prefix zugeteilt und das WAN Interface hat eine öffentliche IPv6 Adresse. Diese kann man zum Beispiel unter Interfaces -> Overview -> WAN abrufen:

Soweit so gut.

Interfaces, die IPv6 aktivieren sollten konfigurieren

Nicht jedes Subinterface zieht sich nun selbt ein Prefix oder eine Adresse. Jedes IPv6 fähige Interface muss erst aktiv so konfiguriert werden. Öffne die Config eines Interfaces und wähle bei IPv6 Configuration Type den Wert Track Interface aus. In den erweiterten Optionen weiter unten setzt man als “Parent-Interface” WAN. Wichtig ist, dass der Haken bei Manual configuration gesetzt ist.

Die Prefix IP kann man anpassen. Bei mehrere Interfaces muss man dann zum Beispiel aus einer 0 eine 1 machen. Das passiert aber glaube ich automatisch. Ich würde es erstmal unverändert lassen.

SLAAC aktivieren

Mit Stateless Autoconfiguration broadcasted ein Router/Gateway ein Prefix und weitere Infos, wie zum Beispiel DNS Server). Diese nennt mann Router Advertisements (kurz: RA). Die Clients empfangen von einem oder mehrere Router verschiedene Advertisements mit Prefixen und leiten sich zum Beispiel mit Hilfe der eigenen MAC Adresse eine IPv6 Adresse daraus ab. Für SLAAC ist mindestens ein /64er Netz notwendig. Mit einem /65 Netz geht das ganze nicht mehr.

Kurzer Einschub: DHCPv4 vs RA
Beim DHCPv4 frägt jeder Client einen zentralen Dienst, der die Adressen verteilt. Das läuft in der Regel über Broadcast und erzeugt bei einem großen Layer 2 Netz für viel Traffic. Broadcase ist immer Schlecht, da in der Regel die CPU eines teilnehmen Geräts in diesem Netzwerk ein Interrupt von der Netzwerkkarte bekommt. Wenn mein Handy also ein Lease haben will, dann wir die CPU in meinem Tablet, PC, Handy, Kühlschrank, NSA Spionagewanze usw angehalten, obwohl die nichts damit zu tun hat.
Beim Design von IPv6 hat man dieses Problem erkannt und gelöst. Router Advertisements werden hier nicht via Broadcast verteilt, sondern via Multicast. Möchte ein Gerät mit IPv6 kommunizieren teilt es dem nächsten Switch quasi mit, dass es gerene Multicast Traffic für eine spezielle Gruppe/Adresse erhalten möchte. Ich würde das als selektiven Broadcast bezeichnen.

Unter Services -> Router Advertisemetns sollte man nun zum Beispiel LAN finden. Taucht das gewünschte Interface hier nicht auf, dann ist im vorherigen Schritt der Haken bei Manual configuration nicht gesetzt worden.

Nun setzt man einige Einstellungen. Unser RA Daemon soll im Modus Unmanaged Advertisements schicken. Unmanaged bedeutet nicht, dass der Daemon nicht konfiguriert wird, sondern dass die Clients ihre eigene Konfig/Adresse generieren sollen (SLAAC). Wir könnten alternativ auch den Clients mitteilen einen DHCPv6 Server für die Konfig zu fragen.

Ich habe als DNS Server die IPv6 Adresse meines DNS Resolvers eingetragen. Hier können auch die DNS Server von Google oder die vom Provider eingetragen werden.

Das wars auch schon. Wenn nun alles geklappt hat, dann hat der Computer oder das Handy eine oder mehrere IPv6 Adresse generiert.

Firewall Regeln erstellen

Hier kommt es nun speziell auf das Netz an. Ich habe ein paar Basisregeln erstellt:

Das ist erstmal die Grundkonfig. Eine Regel sollte man noch erstellen: ICMPv6 von außern an die Clients im Netz sollten geforwardet werden. ICMPv6 ist im IPv6 Netz sehr wichtig um zum Beispiel Fehler schnell zurückzumelden. Dazu legt man im WAN folgende Regeln(n) an:

Wichtig: Nicht TCP oder UDP freigeben, sondern nur ICMP!

Nun sollte IPv6 erstmal laufen. Testen kann man das zum Beispiel hier: https://ipv6-test.com/. Das Ergebnis sollte so aussehen:

Sollte hier kein IPv6 Support angezegt werden, dann stimmt was nicht. Mögliche Fehler:

Sollte es danach immer noch nicht funktionieren, dann mal mit Wireshark tracen.

Bei ICMP sollte Reachable stehen! Wenn dies fehtl, dann ist die ICMP Regel für das WAN Interface in zum Beispiel das LAN Netz nicht gesetzt. Oder die Fritz!Box Firewall ist noch an.

Damit ist IPv6 erstmal implementiert.

Abschliesende Gedanken

Statische Konfiguration vs. SLAAC

Ein Netzwerkadmin will sein Netzwerk immer in einem klar definierten Zustand wissen. Geräte, die sich selber Adressen bilden fühlt sich erstmal ungewohnt und unsauber an. Ich würde es mal wie folgt umschreiben:
Bei IPv4 und DHCP bildeten die Leute eine Schlange vor einem Ticketspender, der nach und nach jedem eine Wartenummer zuteilt. Bei IPv6 und SLAAC schreit der Ticketspender regelmäßig einen Nummernblock und die Leute machen dann untereinander die Reihenfolge aus.

Ein gewaltiger Vorteil bei IPv6 und SLAAC ist, dass das Administrationsaufwand gegen Null geht. Ich definiere ein mal ein Prefix und die Advetisements und muss mich danach um nichts mehr kümmern. Gerade in den kommenden großen Netzen (Internet of Toilets) wird der lähmende Broadcast Traffic nur noch einen Bruchteil betragen.

Statisches Prefix vs. dynamisches Prefix

Als ich noch IPv6 via meinem Telekom Anschluss bekommen habe wurde beim Erneuern des DHCPv6 leases zwingend ein neues Prefix zugeteilt. Die Telekom hat damals mit Privatsphäre argumentiert. Zugegeben: 98% der Privatanwender der Telekom ist das IPv6 Prefix völlig egal. Diese Kunden haben keine Services im Heimnetz, die auf ein statisches Prefix angewiesen wären. Nur die Nerds brauchen das.

Mein Arbeitgeber und jetziger Provider verzichtet bei der Auffrischung des Leases auf einen zwingenden Wechsel. Lease Time ist aktuell bei 20 Minuten.

Security

Ich habe es oben schon mal angesprochen und ich widerhole es noch mal: Jedes Gerät bekommt eine öffentlich geroutete Adresse und ist - wenn man keine Firwall hätte - nackt im Internet. Ein Android Handy oder die chinesische IOT Scheiße wäre ungefiltert im Netz. Das kann Fluch und Segen sein. Einfach mal IPv6 zu aktivieren ist also nicht so trivial.

Die Fritz!Box (und ich denke auch alle anderen Hersteller) hat das schön gelöst. Die Fritz!Box hat intern eine Statefull Firewall. Baut ein Client eine Verbindung nach außen auf, dann wird der Rücktraffic an der Firewall geforwardet. Das muss man nicht extra konfigurieren und ist standardmäßig an. Für den 0815 Anwender ist das also schon perfekt gelöst.

In meinem oben beschriebenen Setup schalte ich die Firewall explizit aus. Ich traue mir zu mein Netz mit Hilfe von OPNSense selbst abzusichern. Vor allem weil die default Policy “Drop” ist.
Ich habe von WAN zu LAN nur ICMPv6 freigegeben und das ist auch wichtig. Mit ICMPv6 werden vor allem im Fehlerfall wichtige Kontrollnachrichten dem Client zugestellt. Da das nicht im normalen Dialog passier hätte die Firewall keinen State dafür und würde das Paket nicht forwarden. Unter Umständen führt das zu einer erheblichen Verzögerung beim Verbindungsaufbau oder einen IPv4 Fallback.
Beispiel: Ich baue eine ausgehende IPv6 Verbindung zu einem Webserver auf. Da dieser aber falsch konfiguriert ist sendet ein System ein ICMPv6 Paket über mit dem Code Destination Unreachable zurück. Fehlt die Firewall Regel wird das Paket gedroppt (kein State vorhanden) und der Client versucht mit Retransmits noch einige Sekunden die Verbindung aufzubauen. Erst nach dem Timeout eines Protokolls einer höheren Schicht wird ein Fallback auf IPv4 ausgelöst. Das kann schon mal ein paar Sekunden sein. Mit der Regel werden diese ICMPv6 Nachrichten auch ohne State in der Firewall an den Client geforwarded und der Fallback kann sofort erfolgen.

Klare Empfehlung: Mit der aktivierung von eingehenden ICMPv6 Nachrichten geht man kein Sicherheitsrisiko ein. Das führt dazu, dass Clients ICMPv6 Echo Requests (aka Pings) beantworten. Das alleine ist aber meiner Meinung nach kein Angriffsvektor.
Es besteht natürlich die Möglichkeit alle ICMPv6 Pakete zu forwarden bis auf Echo Request. Die Komplexität steigt und man gewinnt meiner Meinung nach nichts wirkliches. Erst wenn es einen Angriff wie “Remote Code Execution over ICMPv6” in der freien Wildbahn gesichtet wird sollte man das abdrehen.

Prüft eure Firewall Einträge auf der WAN Seite! Ein mal als Protokoll TCP anstelle von ICMP ausgewählt und alle eure LAN Clients hängen mit nacktem Arsch im Internet. Das möchte man wirklich nicht haben.

Privacy

Mit SLAAC bildet sich ein Gerät in der Regel eine Adresse aus der EUI-64/MAC-Adresse. Deswegen kann ein SLAAC Netz auch nicht kleiner als /64 sein, da die letzten 64 bit der sogenannte Interface Identifier ist. IPv6 Adressen sind also quasi vorhersehbar.

Einige argumentieren: Wenn die letzten 64 bit immer die selben sind, dann ist ein Gerät durch das gesamte Internet trackbar. Bei IPv4 wurde durch die Verwendung von NAT viel verschleiert. Abhilfe schafft die sogenannte Privacy Extension (RFC 4941). Bei diesem Verfahren wird eine Adresse mit Hilfe vom Zeitstempel + MAC Adresse + SHA1 und weitere Magie eine oder sogar zwei zufällige Adresse generiert. Diese Wechselt dann von Zeit zu Zeit auch noch. Somit ist ein Tracking nur anhand der IPv6 Adresse fast unmöglich.
Man sollte sich aber im klaren sein, dass das Tracking über eine IP-Adresse in Zeiten von Cookies, Tracking Pixel, Browser Fingerprinting usw. völlig vernachlässigbar ist

Consumer Geräte wie Handies, Tablets und Laptops haben die IPv6 Privacy Extension standardmäßig aktiviert. Mein Macbook Pro zum Beispiel hat gar keine IPv6 Adresse mit Hilfe der EUI-64 gebildet. Diese erkennt man in der Regel daran, dass ziemlich Mittig ff:fe auftaucht. Stattdessen hat er eine IPv6 mit der Eigenschaft secured und temporary generiert:

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether 98:01:a7:XX:XX:XX
	inet 10.20.10.21/24 brd 10.20.10.255 en0
	inet6 fe80::1859:ddf:67e6:78eb/64 secured scopeid 0x5
	inet6 2001:XXXX:XXXX:5180:10b1:3ea1:afea:4554/64 autoconf secured
	inet6 2001:XXXX:XXXX:5180:917f:9796:894b:1991/64 autoconf temporary

Die Adresse mit der Eigenschaft secured ist mit Apple Magie generiert worden und der Host-Teil ist statisch. Ändert sich das Prefix, dann ändert sich nur der Prefix-Teil der Adresse. Der Host-Teil bleibt gleich. Erst nach einer Neuinstallation soll sich laut Internet der Identifier ändern.

Die Adresse mit der Eigenschaft temporary ist mit Hilfe der IPv6 Privacy Extension generierten Adresse. Diese Adresse hat sich auch tatsächlich nach ein paar Stunden geändert.

Auf meinem Android Handy ist es etwas anders. Dort ist eine Adresse aus der MAC generiert worden:

Zusätzlich wurde auch eine IPv6 nach der Privacy Extension generiert. Diese wird auch für ausgehende Anfragen benutzt. Die DNS IP Adresse ist auch eine SLAAC Adresse, allerdings ohne Privacy Extension.

Zusammengefasst: In Zeiten von globaler NSA Überwachung, Facebook, Tracking Pixel und Browser Fingerprinting ist die IPv6 Adresse sogar ohne Priacy Extension vernachlässigbar. Ich würde aber immer prüfen, ob die Privacy Extensions eingechaltet sind.


Du hast einen Kommentar, einen Wunsch oder eine Verbesserung? Schreib mir doch eine E-Mail! Die Infos dazu stehen hier.

🖇️ = Link zu anderer Webseite
🔐 = Webseite nutzt HTTPS (verschlüsselter Transportweg) Zurück