IPv6 Funktionalität - Was gibt es und was kommt noch?

[Markus Hillebrand]

Hallo,

ich habe mich sehr intensiv in die Arbeit mit IPv6 sowohl im Allgemeinen als auch mit Securepoint UTMs eingearbeitet. Leider ist hierbei aufgefallen und auch bereits mit dem Support besprochen, dass Interfaces (z.B. eth1, wan0) nicht für die Arbeit mit IPv6 geeignet sind - hier müssen aktuell noch die Adressblöcke oder Interfaceadressen eingegeben werden. Dies ist natürlich für dynamische Anschlüsse (die viele unserer Kunden haben) nicht wirklich nutzbar.

Gibt es hier bereits einen Zeitrahmen wann eine UTM Version (das Forum sprach von Version 12) herauskommt, die auch dynamische Adressvergabe unterstützt?

Weiterhin ist die Frage nach Multihoming (Nutzung mehrerer IPv6 Adressblöcke und somit mehrerer IPv6 Adressen pro Client) für die Arbeit mit mehreren Providern. Für DNS gibt es ja die Möglichkeit mit einem Round Robin DNS die Erreichbarkeit über mehrere IP Adressen zu realisieren - die Frage ist nun, ob die UTM Multihoming bei IPv6 bereits unterstützt (ohne Krücken wie DestNAT oder ähnlichem).

Ansonsten kann ich bisher positives Fazit ziehen bei Anschlüssen mit festem IPv6 Netz: Die Performance über IPv6 was Latenz und teilweise auch Übertragungsraten angeht ist sehr gut und bei den meisten Tests besser als über IPv4. Ausserdem gefällt mir die Arbeit mit Portfreigaben ohne NAT und Reverseproxy. Ich freue mich auf den Zeitpunkt, wenn einmal alle Provider in Deutschland damit loslegen - vielleicht sogar mit festem IPv6 Netz für alle Kunden (auf Antrag).

Vielen Dank bereits im Voraus

[Mario]

Moin!

Es werden noch ein paar Anpassungen bei IPv6 kommen.

Zum Einen zieht sich die Firewall entsprechend bei Aktivieren des DHCPv6-Client fuer die entsprechende Schnittstelle ein IPv6 Lease. Das Aktivieren des Router Advertisement ist ebenfalls notwendig, sodass die Firewall den Nexthop ermitteln kann. Dies ist aktuell fuer die normalen Schnittstellen der Firewall implementiert. (Wie Sie beschrieben haben)

Bei WAN-Anschluessen muss nur die IPv6-Unterstuetzung und die Prefix Delegation aktiviert werden. Auf dem WAN-Interface hat man dann zwar keine IPv6-Adresse, dies ist aber unerheblich. Das Router Advertisement z.B. auf eth0.7 des VLAN fuer das WAN-Interface zu aktivieren, loest das Problem. Natuerlich kann das Router Advertisement entsprechend auch auf anderen Schnittstellen eingeschalten werden, die Firewall wird dann entsprechend eine weitere oeffentliche IPv6-Adresse auf das Interface legen und in die dahinter liegenden Netze oeffentliche IPv6-Adressen verteilen.

Hier wird zukuenftig wohl noch eine Aenderung kommen:

Wenn Sie ein ULA erstellen, wird es wahrscheinlich so kommen, das dann nur Adressen fuer dieses ULA in dieses Netz verteilt werden. Es wird dann, wenn ein internen IPv6-Netz aufgespannt wird, keine oeffentliche IPv6-Adresse mehr auf dieses Interface gelegt werden. (Prefix Delegation und Router Advertisement fuer die Schnittstelle einschalten/ per DHCPv6 Adressen verteilen > Fertig)

Das wuerde dann auch mehrere verschiedenen Internetanschluesse mit IPv6 und Multipath-Routing ermoeglichen. In dem Fall erstellen Sie dann Regeln wie mit IPv4-Netzen auch > Mit HIDENAT. Da die ULA-Adresse dann mit der oeffentlichen IPv6-Adresse der FW ersetzt werden muss. Dies hat den Vorteil, das Sie sauber Netzwerkobjekte anlegen koennen, da das Netz ja fest steht.

Auf Interfaces, wo kein IPv6 Netz angelegt wurde, laeuft es dann wie bisher: Das Interface und die Clients hinter dem Interface bekommen eine oeffentliche IPv6-Adresse zugewiesen. Die Netzwerkobjekte muesssen dann bei unbekannten Prefix als "::/0" angelegt werden, mit der korrekten Zone.

Was die Netzwerkobjekte selbst angeht: Dafuer existiert bereits ein Ticket in der Entwicklung. Ein Problem bei der Verwendung von oeffentlichen IPv6-Adressen fuer interne Clients besteht aber eben auch beim Zonenkonzept der Firewall. Da bei den oeffentlichen IPv6-Adressen das gleiche Netz an mehreren Interfaces existieren kann und es auch Dienste gibt, die das Zonenkonzept nicht nutzen (Webfilter), kann ich nur empfehlen, im Normalfall die Loesung mit den "ULA" zu nutzen, die zukuenftig moeglich sein wird. Falls man dann noch Clients mit oeffentlichen IPv6-Adressen braucht, wuerde ich diese dann in ein eigenes Netz an einem eigenen Interface hinter die Firewall legen. (VLAN ist da auch eine Option)

Dann hat man das Optimum aus beiden Welten: Fuer interne Netze/ Workstations/ Clients > Keine oeffentlichen Adressen/ keine Probleme mit Webfilter & Co wegen Ueberschneidungen.
Fuer Webserver & Co > Getrennte Netze mit oeffentlichen IPv6-Adressen, direkt ohne DESTNAT erreichbar. (Eine Regel muss natuerlich trotzdem sein)

Und bitte beachten: Das Anpingen der oeffentlichen IPv6-Adressen der Firewall und der Clients ist ohne Portfilterregel moeglich. (Dies ist so im Standard festgelegt) Der Zugriff auf andere Dienste natuerlich nicht, dies bedarf einer Portfilterregel.

[Markus Hillebrand]

Mmh, das Arbeiten mit den ULAs finde ich ... naja (es entspricht ja nicht dem Konzept hinter IPv6 alles wieder zu NATen). Die Netztrennung der Zonen habe ich ja durch die Interfaces bzw. durch die Subnetze (hierfür stellen die ISPs ja jedem Kunden extra ein /56 zur Verfügung, damit wir hieraus mehrere /64er Netze bauen können) - hier wäre es schön, wenn die UTM auch dynamische Präfixe unterstützen würde (z.B. durch automatisches Regelupdate der Interfaces bei Update des Präfix auf der WAN Schnittstelle). Aber schauen wir mal was die Zukunft bringt.

[Mario]

Gerne auch in der Wunschbox bei uns vorbei schauen.