IPv6 only in Unifi UDM Pro oder Cloud Gateway Ultra
Hallo zusammen,
ich suche Hilfe beim Einrichten von IPv6 only in einer Unifi UDM Pro oder in einem Unifi Cloud Gateway Ultra.
Die OS Verisonen sind:
UDM Pro 4.0.21
Network 8.5.6
Cloud Gateway Ultra 4.0.2
Network 8.5.6
Ich habe folgende Daten vom Provider zu IPv6 (die Adressen habe ich verfremdet):
E-Mail vom Provider Zitat:
".... für unsere Kunden XY ist das gesamte IPv6 Präfix 2a02:17a0:3000:a100::/56 vorgesehen.
Aus dem gesamten Präfix ist am Router (Juniper SRX340) ein IPv6-Transfernetz abgespaltet und konfiguriert: 2a02:17a0:3000:a100::/64
In diesem Transfernetz hat unser Router die Gateway-Adresse 2a17a0:3000:a100::1/64
Nun kann der Kunde innerhalb dieses /64-Transfernetz z.B. eine Firewall mit einer innerhalb des /64-Präfix gültigen Adresse einrichten.
Die gesamte Adressen des /56-Präfix müssten dann nutzbar sein......."
Ich kann ein Windows oder Linux Client mit statischer IPv6 unter Angabe des Gateway und DNS Server einrichten, was Problemlos funktioniert.
Ich habe aber keine Ahnung, wie ich einen Router mit WAN und LAN einrichte, so dass die Clienten im LAN, wenn möglich eine IPv6 zugewiesen bekommen.
Ich kenn eben nur IPv4 mit global IP und im LAN mit NAT public IP.
Könnt ihr mir eventuell helfen wie ich WAN und LAN IPv6 only in einem der beiden Unifi Router einrichte?
Danke und Grüße
ich suche Hilfe beim Einrichten von IPv6 only in einer Unifi UDM Pro oder in einem Unifi Cloud Gateway Ultra.
Die OS Verisonen sind:
UDM Pro 4.0.21
Network 8.5.6
Cloud Gateway Ultra 4.0.2
Network 8.5.6
Ich habe folgende Daten vom Provider zu IPv6 (die Adressen habe ich verfremdet):
E-Mail vom Provider Zitat:
".... für unsere Kunden XY ist das gesamte IPv6 Präfix 2a02:17a0:3000:a100::/56 vorgesehen.
Aus dem gesamten Präfix ist am Router (Juniper SRX340) ein IPv6-Transfernetz abgespaltet und konfiguriert: 2a02:17a0:3000:a100::/64
In diesem Transfernetz hat unser Router die Gateway-Adresse 2a17a0:3000:a100::1/64
Nun kann der Kunde innerhalb dieses /64-Transfernetz z.B. eine Firewall mit einer innerhalb des /64-Präfix gültigen Adresse einrichten.
Die gesamte Adressen des /56-Präfix müssten dann nutzbar sein......."
Ich kann ein Windows oder Linux Client mit statischer IPv6 unter Angabe des Gateway und DNS Server einrichten, was Problemlos funktioniert.
Ich habe aber keine Ahnung, wie ich einen Router mit WAN und LAN einrichte, so dass die Clienten im LAN, wenn möglich eine IPv6 zugewiesen bekommen.
Ich kenn eben nur IPv4 mit global IP und im LAN mit NAT public IP.
Könnt ihr mir eventuell helfen wie ich WAN und LAN IPv6 only in einem der beiden Unifi Router einrichte?
Danke und Grüße
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669255
Url: https://administrator.de/contentid/669255
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
46 Kommentare
Neuester Kommentar
Moin.
Eigentlich simples Subnetten wie bei IPv4 auch wenn man ein globales Subnet geroutet bekommt, und das NAT entfällt.
Dein WAN bekommt im o.g. Beispiel die IP 2a02:17a0:3000:a100::2/64, und als DefaultGW auf dem WAN die 2a02:17a0:3000:a100::1
Und der LAN-Port bspw. die 2a02:17a0:3000:a101::1/64 also ein separates 64er Subnetz deines 56er Blocks.
Dann auf dem LAN noch RAs und SLAAC aktivieren und schon generieren sich die Clients selbst eine globale IP aus dem Subnetz des LANs und erhalten den Router als DefaultGW und kommen damit ins globale IPv6 Netz.
Wie immer lesenswert bevor man an die Praxis geht
https://danrl.com/ipv6/
Gruß catrell
Eigentlich simples Subnetten wie bei IPv4 auch wenn man ein globales Subnet geroutet bekommt, und das NAT entfällt.
Dein WAN bekommt im o.g. Beispiel die IP 2a02:17a0:3000:a100::2/64, und als DefaultGW auf dem WAN die 2a02:17a0:3000:a100::1
Und der LAN-Port bspw. die 2a02:17a0:3000:a101::1/64 also ein separates 64er Subnetz deines 56er Blocks.
Dann auf dem LAN noch RAs und SLAAC aktivieren und schon generieren sich die Clients selbst eine globale IP aus dem Subnetz des LANs und erhalten den Router als DefaultGW und kommen damit ins globale IPv6 Netz.
Wie immer lesenswert bevor man an die Praxis geht
https://danrl.com/ipv6/
Gruß catrell
Vielleicht hilft auch ein Beispiel wie das Verteilen des Delegation Netzes als interne /64er Subnetze einfach und schnell auf einer pfSense/OPNsense Firewall oder einem Cisco Router gelöst wird. Dürfte auf den Unify Gurken mehr oder minder identisch sein, da Standard Prozedur die der o.a. Provider ja auch genau so schildert.
https://www.kuerbis.org/2023/03/ipv6-im-heimnetz-mit-pfsense-und-dynamis ...
IPv6 mit PD auf Cisco Router aktivieren
https://www.kuerbis.org/2023/03/ipv6-im-heimnetz-mit-pfsense-und-dynamis ...
IPv6 mit PD auf Cisco Router aktivieren
Jetzt fehlt bei der Konfiguration der IPv6 Gateway auf dem Windows Cleint
Wie oben schon gesagt benötigst du den nicht und nur dann wenn du eine statische Client v6 Adressierung nutzt was aber aus guten Gründen niemand macht. Wäre in deinem Falle bei dynamisch wechselnden PDs vom Provider auch kontraproduktiv.Das v6 Gateway kommt bei den LAN Clients immer automatisch über SLAAC oder auch DHCPv6 je nachdem was sie nutzen. Primär immer SLAAC. Sprich dein Router sendet dynamisch auf dem lokalen LAN Interface RAs (Router Advertisements) die das an die Clients propagieren. (Im IPv6 Workshop Buch Seiten 113, 131 und 139)
Immer das gleiche Spiel, dass nur die "forderste" Schnittstelle prima funktioniert.
Das ist natürlich Unsinn wenn man alles richtig macht. Weisst du ja auch selber! Bei Mikrotik findest du die v6 ToDos u.a. auch hier:
Welche IPv6 Adresse soll ich der LAN Schnittstelle meines Routers geben?
IPv6-Prefix-Delegation auf MikroTik-Router mit FritzBox als Internetrouter
IPv6 mittels Prefix Delegation bei PPPoE (Mikrotik)
Jetzt fehlt bei der Konfiguration der IPv6 Gateway auf dem Windows Cleint (ipconfig /all)
Das brauchst du nicht von Hand setzen. Das kann am Client alles auf automatisch stehen bleiben, außer die IPv6 des DNS Server von Hand wenn dieser nicht distributed wird.Einfach am Router ein static subnet auf dem LAN, SLAAC und Router Advertisements (RAs) aktivieren. Die Clients generieren ihre Adresse automatisch sobald sie passende Advertisements auf ihre Solicitations im LAN bekommen, ebenso wird das DefaultGW dadurch automatisch auf die LinkLocal Adresse (fe80.....) des Routers gesetzt, manuell brauchts da also gar nichts am Client.
Der Router selbst routed Anfragen ans Internet dann seinerseits an sein Default GW zum ISP, simpelste Routing Grundlagen halt🙂
Solltest du noch einen alten Raspberry Pi oder Pi Zero irgendwo in der Bastelschublade haben kannst du das mit einem Lite Image auch schnell selber ausprobieren.
Von der Funktion her ist das immer das Übliche: DHCPv6 Client holt PD (hier eth0, WAN) und weist es als /64er weiteren lokalen Interfaces zu (hier eth1, LAN).
Das o.a. Setup rennt ohne GUI Schnickschnack mit dem aktuellen Bookworm-Lite Image das den NetworkManager als Netzwerk Setup im Default benutzt der kein PD und v6 RAs von sich aus kann. (Bullseye nutzt noch dhcpcd im Default kann aber in der raspi-config auf NetworkManager umgestellt werden)
Dazu benötigst du 2 zusätzliche Komponenten:
Setup DHCPv6 Client:
Wird über die /etc/wide-dhcpv6/dhcp6c.conf Datei gemacht.
👉🏽 Der Router propagiert hier ein /59 Prefix per PD, folglich muss sla-len 5; hier auf 5 stehen. Prefixmaske + sla-len = /64 also 59+5=64 Bit Maske für das eth1. Bei dir und deinen /56 PD dann "8". Interface. ifid 1 bedeutet das der Router die ::1 als Interface IP bekommt.
⚠️ Das DHCPv6 Client Interface eth0 muss im NetworkManager Setup (nmtui) im Modus "Ignore" stehen!
Setup RADVD:
Geht über die /etc/radvd.conf Setup Datei. Hier indem er über die RAs auch Telekom v6 DNS Server IPs an die Clients verteilt.
Zum Schluss noch der übliche Hinweis das IPv6 Forwarding (Routing) aktiviert werden muss wenn Linux (oder auch Winblows) routen soll. Dazu passt man die /etc/sysctl.conf Datei an und rebootet.
Fertisch... 😉
Ein ip -6 a und Routing mit ip -6 r zeigt dann erwartungsgemäß
Mit radvdump kann man sich die RAs auf den beiden Interfaces live ansehen.
Der RasPi werkelt "as designed" so im Handumdrehen als IPv6 Router mit Prefix Delegation! 👍
Was also ein kleiner 10€ RasPi Zero in 10 Minuten mit ein paar Konfig Zeilen kann sollte deine Unify Gurke allemal mit links wuppen können...
Von der Funktion her ist das immer das Übliche: DHCPv6 Client holt PD (hier eth0, WAN) und weist es als /64er weiteren lokalen Interfaces zu (hier eth1, LAN).
Das o.a. Setup rennt ohne GUI Schnickschnack mit dem aktuellen Bookworm-Lite Image das den NetworkManager als Netzwerk Setup im Default benutzt der kein PD und v6 RAs von sich aus kann. (Bullseye nutzt noch dhcpcd im Default kann aber in der raspi-config auf NetworkManager umgestellt werden)
Dazu benötigst du 2 zusätzliche Komponenten:
- apt install wide-dhcpv6-client Der DHCPv6 Client der den delegierten Prefix abholt
- apt install radvd radvdump Der Router Advertising Daemon der am PD Port den Router Status an die Clients propagiert. radvdump ist ein Monitoring Tool was die RAs im Netz anzeigt.
Setup DHCPv6 Client:
Wird über die /etc/wide-dhcpv6/dhcp6c.conf Datei gemacht.
interface eth0 {
send ia-na 0;
send ia-pd 0;
send rapid-commit;
request domain-name-servers;
request domain-name;
script "/etc/wide-dhcpv6/dhcp6c-script";
};
id-assoc na 0 {
};
id-assoc pd 0 {
prefix-interface eth1 {
sla-id 1;
sla-len 5;
ifid 1;
};
};
⚠️ Das DHCPv6 Client Interface eth0 muss im NetworkManager Setup (nmtui) im Modus "Ignore" stehen!
Setup RADVD:
Geht über die /etc/radvd.conf Setup Datei. Hier indem er über die RAs auch Telekom v6 DNS Server IPs an die Clients verteilt.
# aktives Interface mit RAs
interface eth1 {
AdvSendAdvert on;
prefix ::/64 {
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2003:180:2:3000::53 2003:180:2:4000::53 {
};
};
Zum Schluss noch der übliche Hinweis das IPv6 Forwarding (Routing) aktiviert werden muss wenn Linux (oder auch Winblows) routen soll. Dazu passt man die /etc/sysctl.conf Datei an und rebootet.
# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.eth0.accept_ra=2
Fertisch... 😉
Ein ip -6 a und Routing mit ip -6 r zeigt dann erwartungsgemäß
root@raspi:/home/admin# ip -6 a
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 202a:bb:81a:290a:ba27:ebff:fe01:8461/64 scope global dynamic mngtmpaddr
valid_lft 86239sec preferred_lft 86239sec
inet6 fe80::ba27:ebff:fe01:8461/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 202a:bb:81a:2981:2e0:4cff:fe36:4e44/64 scope global dynamic noprefixroute
valid_lft 86144sec preferred_lft 86144sec
inet6 fe80::2e0:4cff:fe36:4e44/64 scope link noprefixroute
valid_lft forever preferred_lft forever
root@raspi:/home/admin# ip -6 r
202a:bb:81a:290a::/64 dev eth0 proto kernel metric 256 expires 86318sec pref medium
202a:bb:81a:2981::/64 dev eth1 proto ra metric 101 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth1 proto kernel metric 1024 pref medium
default via fe80::5e71:bff:fe0c:25f4 dev eth0 proto ra metric 1024 expires 1718sec hoplimit 64 pref medium
Der RasPi werkelt "as designed" so im Handumdrehen als IPv6 Router mit Prefix Delegation! 👍
Was also ein kleiner 10€ RasPi Zero in 10 Minuten mit ein paar Konfig Zeilen kann sollte deine Unify Gurke allemal mit links wuppen können...
Benötige ich eine Route oder ähnliches?
Nein die braucht es nicht, reines IP-Forwarding auf dem Gateway reicht, das kennt ja alle Wege bereits, das ist alles korrekt so. Da grätscht dir vermutlich die Firewall auf dem Gateway rein. Checke was per IPv6 auf deinem Gateway in der Firewall überhaupt für das entsprechende LAN erlaubt ist und schalte das LAN dort frei.Ich habe den WAN Port konfiguriert...
Per Static Konfig?? 🤔Dann verzichtest du im ersten Teststep auf die Prefix Delegation oder?
Die Prefix Delegation an die lokalen LAN Interfaces funktioniert nur mit DHCPv6-PD, folglich muss der WAN Port als DHCPv6 Client laufen sofern du das nutzen willst. Mit Static klappt PD dann erwartungsgemäß nicht. Nur das du das auf dem Radar hast.
Was das Thema Firewall anbetrifft musst du wenn du PD und damit DHCPv6 nutzen willst dann auch sowas wie "PERMIT udp any eq 547 any eq 546" erlauben also alles was UDP mit dem Sourceport 547 und Destination Port 546 ist! Das sind die DHCPv6 Client Ports.
Kann dieser Traffic den WAN Port nicht passieren scheitert auch erwartungsgemäß die DHCPv6 Adressvergabe und damit auch die Prefix Delegation.
Gleicher Fehler beim LAN. Die statische IP Adressvergabe tötet die Adressvergabe dort per PD. Hier müsste also PD aktiviert sein.
Das gilt natürlich nur wenn du eine dynamische v6 Adressvergabe vom Provider bekommst mit sich zyklisch ändernden Prefixes. Sofern du ein festes statisches v6 Netz vom Provider bekommst ist die PD Geschichte natürlich obsolet. Die ISP Zitate oben sprechen aber von einem dynamischen /56er PD.
Meine Vermutung war auch, dass in den Kisten davor was entsprechend konfiguriert ist.
Evt. aber auch auf deiner Kiste, denn vom WAN aus kommst du ja ins Netz, ergo muss es entweder an deiner FW liegen, oder die vorgelagerten Router routen nicht das komplette 56er auf deine WAN-IP. Ein Wireshark Trace am WAN sollte sofort Klarheit schaffen was Sache ist und ob die Pakete deines LANs dort rausgehen. Wenn ja und es kommt nichts an Antwortpaketen zurück liegt es an den vorgelagerten Routern.
Im Packet 99 des gefilterten traces sieht man das der Ping vom Client rausgeht, aber keine Antwort eintrifft, also ist hier deine Firewall schon mal nicht schuld. Ebenso die Pings vom Gateway an Google und Cloudflare kommen nicht durch . Der vorgelagerte Router verbietet wohl die ICMPv6-Kommunikation (echo request) über das Gateway.
Verifizierst du z.B. schnell mittels
Was klar sein sollte ist, das du mit IPv6 only natürlich nur auf per IPv6 erreichbare Gegenstellen zugreifen kannst. Wenn du per IPv6only auch auf IPv4only-Resourcen zugreifen willst benötigst du zusätzlich Techniken wie NAT64/DNS64.
Verifizierst du z.B. schnell mittels
openssl s_client -connect ipv6.google.com:443
. Wenn das erfolgreich durchgeht wird icmp gefiltert.Was klar sein sollte ist, das du mit IPv6 only natürlich nur auf per IPv6 erreichbare Gegenstellen zugreifen kannst. Wenn du per IPv6only auch auf IPv4only-Resourcen zugreifen willst benötigst du zusätzlich Techniken wie NAT64/DNS64.
Glücklicherweise hat dein Fehler keinen Capture Filter auf ICMPv6 zu setzen dazu geführt das man auch anderen Traffic sehen kann insbesondere den DNS Traffic.
Dort sieht man das dein Router mit der 2a02:17b0:4000:a100::2 Absender IP den v6 DNS Server erfolgreich kontaktiert und ihn zu Hostnamen befragt, was zeigt das die v6 Connectivity vom Router im Trace ohne Filter generell gegeben ist.
Kollege @catrell war schneller... Das du die 2a02:17b0:4000:a100::1 nicht pingen kannst kann in der Tat schlicht und einfach daran liegen das der Provider ICMPv6 mit Typ 128 (Echo Requests) in seinem Router per ACL blockt um Ping Attacken usw. zu unterbinden. Das ist generell nicht unüblich bei Providern. Hast du das mit deren Hotline geklärt ob dem so ist ansonsten pingst du dir einen Wolf?! Du solltest deshalb eher www.heise.de oder andere v6 Ziele pingen. Bekommst du da eine v6 Antwort ist die v6 Connectivity ok.
Leider fehlt auch dieser Ping Trace mit und ohne Filter aus dem lokalen ...::a101 LAN.
Nebenbei: Administrator.de scheitert, weil @Frank es traurigerweise immer noch nicht geschafft hat das Forum auch per v6 erreichbar zu machen.
Dort sieht man das dein Router mit der 2a02:17b0:4000:a100::2 Absender IP den v6 DNS Server erfolgreich kontaktiert und ihn zu Hostnamen befragt, was zeigt das die v6 Connectivity vom Router im Trace ohne Filter generell gegeben ist.
Kollege @catrell war schneller... Das du die 2a02:17b0:4000:a100::1 nicht pingen kannst kann in der Tat schlicht und einfach daran liegen das der Provider ICMPv6 mit Typ 128 (Echo Requests) in seinem Router per ACL blockt um Ping Attacken usw. zu unterbinden. Das ist generell nicht unüblich bei Providern. Hast du das mit deren Hotline geklärt ob dem so ist ansonsten pingst du dir einen Wolf?! Du solltest deshalb eher www.heise.de oder andere v6 Ziele pingen. Bekommst du da eine v6 Antwort ist die v6 Connectivity ok.
Router>ping www.heise.de
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2A02:2E0:3FE:1001:7777:772E:2:85, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
Nebenbei: Administrator.de scheitert, weil @Frank es traurigerweise immer noch nicht geschafft hat das Forum auch per v6 erreichbar zu machen.
Aber es funktioniert
Klar da über RAs die Gegenstelle gelernt wird, ist so aber trotzdem Bullshit. Der Nexthop muss immer eine direkt erreichbare Adresse sein.Die gesamte Adressen des /56-Präfix müssten dann nutzbar sein
Das "müsste" bringt mich schon zum schmunzeln. Offensichtlich sind die sich selbst gar nicht sicher was sie da konfiguriert haben .Dort habe ich ein /64er Netz angegeben mit 2a02:17b0:4000:a102:xy
Als Gateway habe ich auch den vom Provider vorgegebenen 2a02:17b0:4000:a100::1 drin.
Das ist aber falsch. Gateway in deinem LAN ist immer der eigene Router. und nur im Router selbst ist das Gateway das vom Provider !! Nexthop Prinzip! Grundlagen => https://www.cisco.com/c/de_de/support/docs/dial-access/floating-static-r ...Als Gateway habe ich auch den vom Provider vorgegebenen 2a02:17b0:4000:a100::1 drin.
Zitat von @FISI-Lehrling:
Dürften die /64 Netz ausserhalb von 2a02:17b0:4000:a100 garnicht mit dem Gateway 2a02:17b0:4000:a100::1 funktionieren?
Nein. Das verbieten die Routing-Tabellen-Grundlagen schon. Einfach mal logisch nachdenken. Wohin sollte ein Device Pakete denn schicken wenn er selbst in seiner Routing-Tabelle keinen Eintrag für ein Subnetz hat aus welchem das Gatway stammt? Ins Nirvana? Die Adresse des Nexthop(GW) muss immer in einem Subnetz liegen das an einem Interface des Devices direkt anliegt.Dürften die /64 Netz ausserhalb von 2a02:17b0:4000:a100 garnicht mit dem Gateway 2a02:17b0:4000:a100::1 funktionieren?
Einfach mal in die Routing-Tabellen schauen, da wird sich das Device schon eine Link-Local als Gateway geschnappt haben und stattdessen die nutzen.
Zitat von @FISI-Lehrling:
catrell noch eine Frage zum Netz.
Ist es stimmig, dass das Transfernetz 2a02:17b0:4000:a100:: mit Gateway 2a02:17b0:4000:a100::1 innerhalb dem /56er "Kundennetz" liegt?
Ja, kein Problem.catrell noch eine Frage zum Netz.
Ist es stimmig, dass das Transfernetz 2a02:17b0:4000:a100:: mit Gateway 2a02:17b0:4000:a100::1 innerhalb dem /56er "Kundennetz" liegt?
Das insgesamt zugewiesene Netz ist ja das 2a02:17b0:4000:a100::/56.
Die schreiben ja:
"....Aus dem gesamten Präfix ist am Router (Juniper SRX340) ein IPv6-Transfernetz abgespaltet und konfiguriert: 2a02:17a0:3000:a100::/64
In diesem Transfernetz hat unser Router die Gateway-Adresse 2a17a0:3000:a100::1/64...."
Ist das ein Problem oder passt das.
Passt. So lange der rest des 56er auf deinen Router mit 2a17a0:3000:a100::2/64 greoutet wird.Die schreiben ja:
"....Aus dem gesamten Präfix ist am Router (Juniper SRX340) ein IPv6-Transfernetz abgespaltet und konfiguriert: 2a02:17a0:3000:a100::/64
In diesem Transfernetz hat unser Router die Gateway-Adresse 2a17a0:3000:a100::1/64...."
Ist das ein Problem oder passt das.
Hier, falls von Interesse, eine einfache Mikrotik Konfig um das umzusetzen. Um jetzt nicht wieder in das Fettnäpfchen Prefix Delegation zu treten ein komplett statisches Setup ohne FW Rules. Dazu musst du beachten:
Mikrotik Setup:
Ping Check:
Sorry für die fehlende "0" der Default Route.
- v6 Default Route statisch setzen
- Provider DNS Server statisch setzen
Mikrotik Setup:
Ping Check:
Sorry für die fehlende "0" der Default Route.
Es ist ja eigentlich genau wie bei IPv4. 2 IP Adressen an den Segmenten konfigurieren, Default Route eintragen, DNS setzen fertisch. Die v4 Grundlagen dazu stehen hier und bei IPv6 ist es ja nicht anders nur das die Adressen ein klein wenig anders aussehen.
Da kein DHCP für IPv6 ins LAN eingestellt ist,
Den braucht es bei IPv6 nicht, wenn "Advertise" für das LAN an ist und das Neighbor discovery für das Interface unter "/ip nd" aktiviert ist, generiert sich die Windows Kiste automatische per SLAAC eine IP aus dem definierten Subnetz, manuelles Konfigurieren deswegen überflüssig, macht aber keinen großen Unterschied wenn du es von Hand machst, außer das als GW dann die LinkLocal (fe80 ...) des Mikrotik herhält.Entweder routet dein ISP nicht das ganze 56er zu dir, oder die machen nur ND am Port für das ganze 56er, die Beschreibung des ISP ist nämlich ziemlich schwammig, denn normalerweise müsste der dir die IP aus dem Transfernetz vorschreiben um die Route hinterlegen zu können, außer es ist ein Mechanismus in Kraft der die erste MAC am Port dafür vorsieht.
Vermutlich Routen die das gar nicht sondern versuchen per Neighbor Discovery die IPv6 deines LANs an deren Port aufzulösen, dann müsstest du am Mikrotik einen ND Proxy am WAN aktivieren damit dieser bei ND Anfragen mit seiner MAC Adresse antwortet. Der Mikrotik hat aber leider keine ND Proxy Funktion nur ARP Proxy für IPv4.
Unter Linux geht ein ND Proxy ganz einfach mit den Standard Tools von iproute2. Hier als bspw. fur einen bestimmten Host.
ip -6 neigh add proxy 2a02:17b0:4000:a101::111 dev eth0
Netcup macht das bspw. auch so bei ihren günstigen vServern.
Auch hier bringt das Mitschneiden des Traffic am WAN Port Klarheit, wenn dort ND Solicitations vom Gateway des ISP auftauchen die nach deiner LAN IPv6 fragen dann ist klar das die nicht regulär routen sondern nur per ND die IPs im Transfernetz auflösen.
Ansonsten bleibt nur abklären mit dem ISP oder mittels ND Proxy arbeiten, oder im schlimmsten Fall den IPv6 Traffic deiner Subnets per NAT auf die WAN IP umschreiben, was aber den Sinn von IPv6 adabsurdum führen würde.
In der Firewall habe ich folgendes eingestellt:
Die Einstellung ist überflüssig. Der Mikrotik bzw. dessen FW arbeitet ohne FW Default Konfig nach einem Router Muster also mit einem Blacklisting und nicht nach einem Firewall Muster (Whitelisting).Sprich ohne Default Konfig und relevante Einträge in der Firewall ist generell alles erlaubt. Deine o.a. Settings sind also ohne Funktion und kannst du damit auch weglassen.
Vermutlich Routen die das gar nicht
Das ist leider zu vermuten... Du kannst das auch recht einfach einmal testen indem du im Ping Tool unter dem "Advanced" Reiter als Absender IP die deines LAN Interfaces 2a02:17b0:4000:a101::1 angibst.
Wenn der Ping dann scheitert ist sehr wahrscheinlich das das Routing deines Präfixes auf Providerseite fehlerhaft ist.
Gleiches sollte dann auch bei einem am MT Lanport angeschlossenen Endgerät passieren bzw. bestägtigt dann auch deinen oben schon gemachten Pingtest.
Im Falle von Winblows hast du mit einem ipconfig -all ja die korrekten v6 Settings überprüft.
Ein Ping auf das Mikrotik LAN und WAN Interface klappt. Ein Ping aufs gegenüberliegende Provider Router Interface und auf andere öffentliche v6 IPs nicht weil die Rückroute fehlt. Das bestätigt dann den Verdacht des fehlerhaften Routings deines Präfixes.
Nebenbei ist das für den Provider bzw. dessen Konfig im Router vor Ort auch nicht einfach. Dieser kennt ja deine möglichen und von dir vergebenen, internen Router v6 Adressen nicht wenn du ihm diese nicht mitteilst. Zusätzlich kennt er damit auch die statischen v6 Netze nicht die ggf. dahinter liegen, kann also keine statischen v6 Routen definieren. Das müsste er aber beides wissen um bei einer reinen statischen IPv6 Konfig die v6 Adressen und statischen Routen dahin zu konfigurieren.
Hier wäre es sinnvoller und für alle Beteiligten einfacher, er würde auf seinem Router DHCPv6 aktivieren und per PD in dein internes LAN entsprechende Subnetz Blöcke an etwaige Router o. Firewalls dort verteilen. Das erzeugt dann nicht nur korrekte v6 Adressen sondern gleichzeitig auch immer einen dynamischen v6 Routing Eintrag auf diesen Block ohne das das manuell passieren muss bzw. immer ein Ticket für Änderungen erforderlich ist.
Falls von Interesse zur Info einmal ein Praxisbeispiel wie dies auf einem Cisco Router konfiguriert ist der hier den Part des Provider Routers übernimmt.
Beispiel Provider Router
Interface:
ipv6 dhcp pool DHCPv6
prefix-delegation pool PREFIX-POOL
import dns-server
domain-name domain.internal
sntp address 2003:2:2:140:194:25:134:196
!
interface Vlan10
description Lokales LAN
ip address 172.16.10.254 255.255.255.0
ipv6 address provider-v6-prefix ::A:0:0:0:1/64
ipv6 enable
ipv6 nd other-config-flag
ipv6 nd router-preference High
ipv6 nd ra dns server 2003:180:2:3000::53
ipv6 nd ra dns server 2003:180:2:4000::53
ipv6 dhcp server DHCPv6 rapid-commit allow-hint <---DHCPv6 aktiv
!
ipv6 local pool PREFIX-POOL 2000:BB:11A:2980::/58 59
DHCPv6:
Der Router reicht wie oben zu sehen aus einem /58 Präfix Block /59er Präfixe dynamisch per DHCPv6 an angeschlossene Router weiter.Sieht man dann in den v6 DHCP Leases:
Client: FE80::4E5E:CFF:FE7F:77E3
Interface : Vlan10
IA PD: IA ID 0x00000002, T1 302400, T2 483840
Prefix: 2000:BB:11A:29A0::/59
preferred lifetime 604800, valid lifetime 2592000
expires at Dec 15 2024 01:17 PM (2591584 seconds)
Routing Tabelle:
Entsprechend dann der dynamische Eintrag in der v6 Routing Tabelle des Routers. Damit entfällt dann eine statische Route denn die per PD vergebenen Netze werden so automatisch geroutet.IPv6 Routing Table - default - 6 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
ND - ND Default
ND ::/0 [2/0]
via FE80::86B5:9CFF:FE65:FA6B, Dialer0
S 2000:BB:11A:2900::/56 [1/0]
via Null0, directly connected
C 2000:BB:11A:290A::/64 [0/0]
via Vlan10, directly connected
L 2000:BB:11A:290A::1/128 [0/0]
via Vlan10, receive
S 2000:BB:11A:29A0::/59 [1/0] <---dynamisch via DHCPv6
via FE80::4E5E:CFF:FE7F:77E3, Vlan10
L FF00::/8 [0/0]
via Null0, receive
Kaskadierter Mikrotik
Der lokale Counterpart ist hier ein Mikrotik Router (RouterOS 7.16.1) der damit dann die komplette v6 Adressierung inkl. Routing dynamisch erhält. RAs auf dem Koppelsegement sind deaktiviert. (NO advertise). Auf den eigenen loaklen Segmenten am MT sind RAs aktiviert damit dort per SLAAC die Adressvergabe und DNS Konfig funktioniert.Der Mikrotik konfiguriert seine Interfaces als DHCPv6 Client dynamisch mit dem ihm vom Cisco zugewiesenen /59er Kontingent als /64er Netze. Natürlch kann man das auch statisch machen.
Ping v6 und DNS Check mit einer lokalen v6 Source IP des MT rennt damit erwartungsgemäß fehlerlos.
Works as designed!! 👍 😉
Setze mal testweise die IPv6 LAN-IP Zusätzlich auf den WAN Port des Mikrotik und entferne diese vom LAN-Port. Pinge dann nochmal mit Absender IP der LAN IP. Wenn dann der Ping vom Mikrotik aus klappt machen die das ganze nur über ND und Routen nicht. Der Neighbor Proxy bringt nur was wenn sich auch mit anderen IPs des 56er vom WAN aus Pingen lässt, dazu muss aber die IP entweder direkt auf den WAN Port gebunden sein oder dieser Neighbor Proxy für diese IP spielen .
Ein Neighbor Proxy bei IPv6 ist nichts anderes als ARP-Proxy bei IPv4. D.h. wenn von Stationen in der Layer 2 Domain des WAN ND Solicitations an das LAN-Subnetz an deinem Router ankommen antwortet dieser mit seiner eigenen MAC-Adresse, so dass der vorgelagerte Router Anfragen von diesen IPs auf dem Rückweg wieder zu deinem Router leitet.
Ein Neighbor Proxy bei IPv6 ist nichts anderes als ARP-Proxy bei IPv4. D.h. wenn von Stationen in der Layer 2 Domain des WAN ND Solicitations an das LAN-Subnetz an deinem Router ankommen antwortet dieser mit seiner eigenen MAC-Adresse, so dass der vorgelagerte Router Anfragen von diesen IPs auf dem Rückweg wieder zu deinem Router leitet.