Statische IPv6-Route in FB anlegen

[frank.pcn]

Hallo zusammen,

Ich habe an einem LAN-Port der FB einen zweiten Router (wan) angeschlossen. Eine Statische IPv4-Route ist bereits angelegt. Nun möchte ich auch die Statische IPv6-Route des zweiten Routers in der FB anlegen. Allerdings scheitere ich am IPv6-Netzwerkverständniss. Kann mir bitte jemand anhand meiner Notizen und den Screenshot erklären, welche Angaben aus dem Zweiten Router in der FB als als statische Route hinterlegt werden müssen?

die Link-Local-Adresse des Routers im FRITZ!Box-Heimnetz IPv6-Adresse gateway fe80::XXXX:XXXX:fe09:e237 IPv4=192.168.178.23 Präfixlänge fe80::/64 IPv6 Netzwerk IPv4=192.168.8.0


Mit besten Grüßen

 

[HabNeFritzbox]

Einfachste wäre wenn der andere Router via DHCPv6 eigenes Subnet anfordert. Dann hat es auch Internet über IPv6.

Mit fe80 oder fd00 Adressen kommst da nicht weit.

Gibt es Grund wieso dein Router als Router arbeitet und nicht als Bridge (IP Client)?

More Settings - GL.iNet Router Docs 3

Documentation for GL.iNet Router Productions

docs.gl-inet.com

Würde zumindest Routen ersparen.

 

[sonyKatze]

zweiten Router

Kann mich HabNeFritzbox nur anschließen, siehe auch diesen Fachartikel: heise+ bzw. c’t-Archiv (der dann auf jenen Artikel verweist: heise+ bzw. c’t-Archiv). Die Rück-Fragen sind daher:

1. Warum unbedingt WAN und nicht LAN = IP-Client bzw. Bridge?
2. Welchen zweiten Router genau (Hersteller, Modell, Firmware-Version)?

 

[frank.pcn]

Kann mich HabNeFritzbox nur anschließen, siehe auch diesen Fachartikel: heise+ bzw. c’t-Archiv (der dann auf jenen Artikel verweist: heise+ bzw. c’t-Archiv). Die Rück-Fragen sind daher:

1. Warum unbedingt WAN und nicht LAN = IP-Client bzw. Bridge?
2. Welchen zweiten Router genau (Hersteller, Modell, Firmware-Version)?

1. Der Router (MV-1000) ist als IP-Client (Lan-Brücke) eingerichtet und bezieht via DHCP eine IPv4-Adresse von der FB (192.168.178.23). Verbunden über den WAN-Anschluss welcher als LAN-Anschluss um konfiguriert ist. (Anleitung). Daher bin ich bisher ausgegangen, dass das Interface = WAN wie im PuTTY-Screenshot die passenden IPv6 Informationen für die Statische Route liefern muss.

2. Der Router-Hersteller ist GL.iNet, Das Modell ist GL-VM1000W (Brume). Firmware ist die aktuelle V3.105 - Dec 8, 2020.
2.2 DHCPv6 habe ich nachträglich wie in im Kommentar wieder aktiviert damit zumindest eine lokale IPv6-Adresse dem Brume-Router zugewiesen wird.

Das IU des Brume-Ruters ist normalerweise über 192.168.8.1 erreichbar. Damit ich aus dem FRITZ-DHCP-Heimnetz (192.168.178.XXX) den Brume und die Client, welche an diesem angeschlossen sind, erreichen kann, habe ich dazu eine statische IPv4-Route in der FB eingerichtet und als Exposed-Host konfiguriert. Nur mit der Einrichtung der statischen IPv6-Route scheitert es ...an nicht ausreichenden IPv6 Netzwerk-Kenntnissen.

Gibt es Grund wieso dein Router als Router arbeitet und nicht als Bridge (IP Client)?

More Settings - GL.iNet Router Docs 3

Documentation for GL.iNet Router Productions

docs.gl-inet.com

Ich würde gern den Brume-Router weiterhin als kaskadierten Router arbeiten lassen, mit getrenntem Netzwerk (192.168.8.0). Dieser soll dann mittels eigenem VPN-Client sich mit einem VPN-Dienst (z.B. NordVPN o.ä) verbinden. Die Fritzboxen arbeiten bekanntlich nicht mit aktuellen VPN-Technologien (Wireguard/OpenVPN).

Sollte ich mit meinem Vorhaben mich auf dem Holzweg befinden, bin ich für jede Unterstützung dankbar.

Mit besten Grüßen

 

[HabNeFritzbox]

Als IP Client brauchst keine Routen.

Exposed Host ist auch unnötig, nur wirklich benötigte Ports freigeben wie z.B. für VPN.

 

[sonyKatze]

OpenWRT ist eine kleine bis gigantische Katastrophe, wenn es darum geht als Host-Computer, Bridge, IP-Client (oder wie auch immer man diesen Modus nennen will) über IPv6 zu arbeiten. Normal wäre:

• über DHCPv4 die IP-Adresse und ein DNS-Server abzufragen
• über ICMPv6 Router Advertisements das IPv6-Präfix zu lernen

Das kann OpenWRT von Haus aus nicht einmal über LuCI. Das muss man über die Kommando-Zeile an verschiedenen Stellen richtig biegen. So und jetzt wird es bunt. Du hast mit GL.iNet noch ein zusätzliches Overlay über diesen ganzen gewachsenen OpenWRT-Architektur-Unsinn. Die Frage ist, was GL.iNET beim Modus „Cable: Use as LAN“ macht. In bezweifele sehr, dass Dein verlinkten Ansatz über DHCPv6 richtig ist – aber das müsste man testen. Leider habe ich kein GL.iNET hier.

Brume-Router weiterhin als kaskadierten Router

Das machst Du in IPv6 nur dann, wenn der kaskadierte Router einen anderen (oder weiteren) Administrator hat, der nicht auch Zugang zum Haupt-Router haben darf. Bist Du bei beiden Admin und es gibt nur Dich als Admin, dann ist ein kaskadierter IPv6-Router nicht zielführend, denn es gibt in IPv6 keine „Netz-Segmente“. Jeder IPv6-Client erhält seine globale IPv6, auf die er dann auf alle Anderen zugreifen kann. Brauchst Du eine Separierung, musst Du sowas über Zugangskontrollen lösen (VLAN oder 802.1x oder …). Ich formuliere das so hart, weil das in IPv4 nur „Schwach“-Sinn war. In IPv6 geht es so schlicht nicht.

Egal, nehmen wir an, Du weißt das. Spielen wir es mal durch:

Bei einem kaskadierten IPv6-Router brauchst Du IPv6-Prefix-Delegation (IA_PD). In dem Fall muss der Haupt-Router einen DHCPv6-Server bieten:

fritz.box → Heimnetz → Netz → (Reiter) Netzeinstellungen → (Taste) weitere Einstellungen → (Taste) IPv6-Einstellungen → DHCPv6-Server im Heimnetz: DNS-Server und IPv6-Präfix (IA_PD) zuweisen​

Weil Du den Brume als Router verwenden willst, würde ich „quasi“ Exposed-Host machen, weil dann der Brume-Eigentümer komplett die Firewall so stricken kann, wie er will – die Idee hinter dem Konstrukt „kaskadierter Router“.

fritz.box → Internet → Freigaben → (Reiter) Portfreigaben → … → (IPv6) Firewall für delegierte IPv6-Präfixe dieses Gerätes öffnen​

So müsste alles automatisch klappen. Müsste, wenn, ja wenn, GL.iNet sein OpenWRT im Griff hat. Die Frage ist, ob der Brume ordentlich über DHCPv6 ein Präfix anfragt, das dann auch richtig bei sich einträgt, und dann intern Router-Advertisements verschickt, die nicht nach außen zum Haupt-Router leaken.

Das kannst Du nur selbst (z.B. mittels Wireshark) vor und nach dem Brume testen. Wenn Du Hilfe bei der Interepation des Logs brauchst, helfen wir Dir gerne. Aber wie HabNeFritzbox schon andeutete: Du brauchst keine Routen, nein, Routen sind hier falsch.

mittels eigenem VPN-Client sich mit einem VPN-Dienst (z.B. NordVPN o.ä) verbinden.

Ich würde es anders machen: Reines DSL-Modem holen (= DrayTek Vigor165 oder Digitalisierungsbox Basic oder …), Brume als Haupt-Router ( = WAN) und die FRITZ!Box als IP-Client. Das ist ein Szenario, dass OpenWRT mag und sicher beherrscht. OpenWRT ist aktuell noch eine völlige Schande als IPv6-Client … kann man wirklich nicht lauter saugen. Keine Ahnung was dessen sehr aktive Community in dem Punkt die letzten 15 Jahre verschalfen hat.

Wenn Du das so nicht willst und Dein Brume kaskadieren soll und Du mit Wireshark nicht weiter kommst, einfach melden … ich wollte mir eh mal ein GL.iNet holen und nachschauen wie schlau die sind … die kleineren Modelle kosten ja nicht die Welt. Aber einfach sagen … den ohne Anlass tue ich mir das (noch) nicht an.

 

[frank.pcn]

OpenWRT ist eine kleine bis gigantische Katastrophe, wenn es darum geht als Host-Computer, Bridge, IP-Client (oder wie auch immer man diesen Modus nennen will) über IPv6 zu arbeiten. Normal wäre:

• über DHCPv4 die IP-Adresse und ein DNS-Server abzufragen
• über ICMPv6 Router Advertisements das IPv6-Präfix zu lernen

Das kann OpenWRT von Haus aus nicht einmal über LuCI. Das muss man über die Kommando-Zeile an verschiedenen Stellen richtig biegen. So und jetzt wird es bunt. Du hast mit GL.iNet noch ein zusätzliches Overlay über diesen ganzen gewachsenen OpenWRT-Architektur-Unsinn. Die Frage ist, was GL.iNET beim Modus „Cable: Use as LAN“ macht. In bezweifele sehr, dass Dein verlinkten Ansatz über DHCPv6 richtig ist – aber das müsste man testen. Leider habe ich kein GL.iNET hier.

Das machst Du in IPv6 nur dann, wenn der kaskadierte Router einen anderen (oder weiteren) Administrator hat, der nicht auch Zugang zum Haupt-Router haben darf. Bist Du bei beiden Admin und es gibt nur Dich als Admin, dann ist ein kaskadierter IPv6-Router nicht zielführend, denn es gibt in IPv6 keine „Netz-Segmente“. Jeder IPv6-Client erhält seine globale IPv6, auf die er dann auf alle Anderen zugreifen kann. Brauchst Du eine Separierung, musst Du sowas über Zugangskontrollen lösen (VLAN oder 802.1x oder …). Ich formuliere das so hart, weil das in IPv4 nur „Schwach“-Sinn war. In IPv6 geht es so schlicht nicht.

Leider unterstütz der Brume die VPN-Client/Server-Features nur im Router-Modus. Sobald man ihn in den AP/IP-Client-Modus versetzt, funktionieren die OpenVPN, Wireguard -Module dich mehr.

Bei einem kaskadierten IPv6-Router brauchst Du IPv6-Prefix-Delegation (IA_PD). In dem Fall muss der Haupt-Router einen DHCPv6-Server bieten:

fritz.box → Heimnetz → Netz → (Reiter) Netzeinstellungen → (Taste) weitere Einstellungen → (Taste) IPv6-Einstellungen → DHCPv6-Server im Heimnetz: DNS-Server und IPv6-Präfix (IA_PD) zuweisen OK​

Weil Du den Brume als Router verwenden willst, würde ich „quasi“ Exposed-Host machen, weil dann der Brume-Eigentümer komplett die Firewall so stricken kann, wie er will – die Idee hinter dem Konstrukt „kaskadierter Router“. OK

fritz.box → Internet → Freigaben → (Reiter) Portfreigaben → … → (IPv6) Firewall für delegierte IPv6-Präfixe dieses Gerätes öffnen OK​

So müsste alles automatisch klappen. Müsste, wenn, ja wenn, GL.iNet sein OpenWRT im Griff hat. Die Frage ist, ob der Brume ordentlich über DHCPv6 ein Präfix anfragt, das dann auch richtig bei sich einträgt, und dann intern Router-Advertisements verschickt, die nicht nach außen zum Haupt-Router leaken.

Das kannst Du nur selbst (z.B. mittels Wireshark) vor und nach dem Brume testen. Wenn Du Hilfe bei der Interepation des Logs brauchst, helfen wir Dir gerne. Aber wie HabNeFritzbox schon andeutete: Du brauchst keine Routen, nein, Routen sind hier falsch.

FB-seitig gibt es bisher folgende Voraussetzungen:
DNS-Server und IPv6-Präfix (IA_PD) zuweisen OK
Brume als Router verwenden willst, würde ich „quasi“ Exposed-Host OK
Firewall für delegierte IPv6-Präfixe dieses Gerätes öffnen OK
(Weitere Screenshot im Anhang)

Ich würde es anders machen: Reines DSL-Modem holen (= DrayTek Vigor165 oder Digitalisierungsbox Basic oder …), Brume als Haupt-Router ( = WAN) und die FRITZ!Box als IP-Client.

Der Brume ist als Hauptrouter desaströs. Bereits ohne Last/VPN-Trafic erzeugt dieser eine Verlusttemperatur um die 45C' , trotz zusätzlichen angebrachten Wärmeleitpads zwischen Backplate und Platine. Ich bezweifle, dass ein 24/7 Betrieb ohne Zwischenfälle möglich ist. Darüber hinaus brauche ein zuverlässigen Router an der TAL für das Homeoffice. Daher meine "Idee" mit dem kaskadiertem Brume-Router hinter der FB.

Das ist ein Szenario, dass OpenWRT mag und sicher beherrscht. OpenWRT ist aktuell noch eine völlige Schande als IPv6-Client … kann man wirklich nicht lauter saugen. Keine Ahnung was dessen sehr aktive Community in dem Punkt die letzten 15 Jahre verschalfen hat.

Baustellen gibt es einige. Leider kann ich mangelnder IPv6-Netzwerkkenntnisse diese auch nicht näher umschreiben. Nur wie folgt:
Obwohl der Brume via DHCPv6 eine IPv6-Adresse erhält, Trace6 und Ping6 erfolgreich aussehen, können Clients, welche am Brume angemeldet sind nicht auf öffendliche IPv6-Adressen zugreifen. Es ist natürlich nicht ausgeschlossen, dass auf der Layer 8-Ebene noch ein paar Fehler gemacht worden sind.

Wenn Du das so nicht willst und Dein Brume kaskadieren soll und Du mit Wireshark nicht weiter kommst, einfach melden … ich wollte mir eh mal ein GL.iNet holen und nachschauen wie schlau die sind … die kleineren Modelle kosten ja nicht die Welt. Aber einfach sagen … den ohne Anlass tue ich mir das (noch) nicht an.

Auf dein Angebot komme ich gern zurück

 

[sonyKatze]

Obwohl der Brume via DHCPv6 eine IPv6-Adresse erhält, Trace6 und Ping6 erfolgreich aussehen, können Clients, welche am Brume angemeldet sind nicht auf öffendliche IPv6-Adressen zugreifen.

Dann dürfte der Brume (a) kein Präfix über DHCPv6 anfordern, oder (b) das erhaltene Präfix nicht richtig bei sich eintragen, oder (c) keine Router-Advertisements intern anbieten. Puh. Hast Du in Wireshark mal geschaut, ob Dein Brume wenigstens ein Präfix delegiert haben möchte (Filter auf dhcpv6)? Auf jeden Fall solltest Du ab hier in einem OpenWRT zentrierten Forum weitermachen.

 

[frank.pcn]

Auf jeden Fall solltest Du ab hier in einem OpenWRT zentrierten Forum weitermachen.

Gesagt, getan. Anscheinend hat gl-inet im August 2020 mit dem FW-Release 3.104 IPv6 bei all seinen Produkten deaktiviert (Quelle). Anscheinend gab es IPv6-DNS-Lecks bei der Verwendung von VPN. Über das Forum bin ich auf die aktuelle 3.201 Beta6 gestoßen. Zumindest klappt es jetzt mit Anfragen über IPv6. Mit dem Gebrauch von Wireshark muß ich mich noch einlesen und werde die Ausgabe dann in dieser stelle posten.

 

[sonyKatze]

Mit dem Gebrauch von Wireshark muß ich mich noch einlesen

Anders machen: Installieren, mitschneiden und fragen. Wir helfen gerne. Das größte Problem dürfte erstmal das Mitschneiden sein. Klappt das? Das machst Du entweder auf der Schnittstelle LAN in der FRITZ!Box (Anleitung) oder Du holst Dir einen Switch mit Port-Morring (Liste). Letzteres kostet unnötig Geld, aber so kannst Du direkt live mitverfolgen und Du kannst den Switch jederzeit auch bei anderen Projekten einsetzen; Plug-and-Play.

 

[frank.pcn]

....oder Du holst Dir einen Switch mit Port-Morring (Liste).

Eventuell besitze ich bereits ein Switch welcher Port-Mirroring (Spiegelung) unterstützt. Es ist ein Netgear GS305E. Konfiguration und Klemmbrett als Screenshot. Ich würde gern mit dem am Switch angeschlossenen PC mitschneiden wollen. Welche der 3 Ports müsste ich zur Spiegelung freigeben? Die Doku und das Benutzerhandbuch lassen diese diese Frage offen. ...oder der vor dem Monitor stellt sich zu glatt an .

 

[Joe_57]

[OFF TOPIC]
Dein Bild FB-Klemmbrett hat den Namen "Netzwerkknoten" zu 100% verdient!
[/OFF TOPIC]

 

[sonyKatze]

der vor dem Monitor stellt sich zu glatt an

Das auf jeden Fall. Aber nicht Du, sondern derjenige, der das programmiert (und auch derjenige, der das übersetzt) hat. Vermutlich wüsste nach der Übersetzung selbst von den beiden keiner, wie es geht. Daher mein Tipp: Erstmal den Netgear auf Englisch umstellen. Ich vermute, Du wählst bei Port-Spiegelung oben rechts das „Deaktiviert“ auf etwas anderes. Und dann als Ziel-Port den Wireshark, also bei Dir Port 3. VLANs … brauchst Du das? Aber, aber …

… ich wollte mir eh mal ein GL.iNet holen und nachschauen wie schlau die sind … die kleineren Modelle kosten ja nicht die Welt.

Am Donnerstag kam endlich mein GL.iNet White und danach mussten die mich erstmal in die Klink einweisen … eigentlich ist das schön, was für Größenwahnsinnige dort in ihren (kantonesischen) Hinterhof-Buden alles im Direkt-Vertrieb mittels AliExpress, Amazon und eBay zu uns per Luftfracht verfrachten … vielleicht wacht so die Politik irgendwann auf, und zieht mal eine Linie. Was für ein Murks! Dass solche Buden (aber auch deutsche) nicht einmal Anwenderwissen in WLAN haben, daran gewöhne ich mich wirklich nur langsam. Also den WLAN-Teil vergessen wir ganz schnell:

• ab Werk kein zufälliger WPA-Schlüssel sondern immer „goodlife“
  änderbar über das GL.iNet eigene Web-Interface → Wireless
  uci set wireless.default_radio0.key='goodlife'
• Deutschland als Land nicht setzbar
  änderbar über More → Advanced (LuCI) → (Menüleiste) Network → Wireless → (Taste) Edit → (Device) Advanced → Country Code: DE
  uci set wireless.radio0.country='DE'
• DSSS nicht abschaltbar
  änderbar in LuCI an selber Stelle wie der Country-Code
  uci set wireless.radio0.legacy_rates='0'
• (folgerichtig) kein WLAN-Kanal 12 bzw. 13
  nachdem der Country-Code richtig sitzt, ist auch das in LuCI änderbar (aber immer noch nicht im GL.iNet eigenen Web-Interface)
  uci set wireless.radio0.channel='13'

Bereits ohne Last/VPN-Traffic erzeugt [mein GL.iNet Brume] eine Verlusttemperatur um die 45C' , trotz zusätzlichen angebrachten Wärmeleitpads zwischen Backplate und Platine. Ich bezweifle, dass ein 24/7 Betrieb ohne Zwischenfälle möglich ist.

Klingt ja gar nicht gut. Der GL.iNet Brume ist ja eigentlich als „Edge Computing Gateway“ ausgelegt bzw. wird so beworben. Oh je.

aktuelle 3.201 Beta6

Ist das eine Beta? Bei mir wird die als Release angezeigt …

Egal. IPv6 sieht nicht besser aus. Mein GL.iNet White fragt im WAN über DHCP-PD alles richtig an. Folglich musst Du das WAN nicht mehr mitschneiden. Das Problem ist das LAN: Wähle ich in der GL.iNet Web-Oberfläche → More → IPv6 unter LAN-Mode …

• … native, dann reicht GL.iNet die Router-Advertisements (RA) der FRITZ!Box einfach durch. Somit landet ein LAN-Client hinter dem GL.iNet im falschen IPv6-Subnetz (bei mir anstatt in 00fc in 0001). Auch werden RA-Flags wie das O(ther)-Bit nicht gelöscht. Folglich fragt ein LAN-Client über DHCPv6 über mehr Infos – bekommt aber keine Antwort von GL.iNet.
• … NAT6, dann macht GL.iNet dies … (mehr dazu im OpenWrt eigenen Wiki: NAT66).

Beides ist der falsche Weg und deren Web-Interface für Dein Vorhaben somit gestorben. Die Tage werde ich mir mittels SSH und uci anschauen, was genau gesetzt ist. Einen Weg gibt es. Keine Frage. Die Frage, ist wie lange es dauert, den zu finden. Hast Du mal statt OpenWrt schon das Image für Ubuntu probiert?

Auf jeden Fall ist WLAN aber auch IPv6 nicht die Stärke im Hause GL.iNet. Und ich habe mir bisher nur das angeschaut. WLAN-Router sind heutzutage echt nicht einfach und für eine einzelne Person ohne ordentliche Ausbildung nicht mehr überschaubar … ich habe auch nichts gegen Fehler … ich habe auch nichts gegen ein wenig Größenwahn … aber muss man wirklich solche Böcke schießen … Dass die bereits seit dem Jahr 2013 mit dem GL.iNet 6416A als Kopie des TP-Link TL-WR703N mitmischen, macht es nicht besser. Bist Du schon weiter?

 

[sonyKatze]

Bist Du noch da?

Das Problem ist das LAN: Wähle ich in der GL.iNet Web-Oberfläche → More → IPv6 unter LAN-Mode: native, dann […]

GL.iNet schaltet im IPv6-LAN-Modus „Native“ den Daemon odhcpd auf relay. Warum, verstehe ich noch nicht …

uci set dhcp.lan.ra_management=0
uci set dhcp.lan.ndp=server
uci set dhcp.lan.ra=server
uci set dhcp.lan.dhcpv6=server
uci commit dhcp
service odhcpd restart

So geht es nun bei mir, wie erwartet. Wireshark zeigt auf den ersten Blick auch keine Auffälligkeiten. Der erste Befehl schaltet zusätzlich in den Router-Advertisements das M(anaged)-Flag aus. So bekommt jetzt ein LAN-Client hinter meiner FRITZ!Box, hinter meinem GL.iNet die richtigen IPv6-Adressen.

Außerdem setzt GL.iNet noch ein ULA-Prefix aber mit einer globalen IPv6 im Adressbereich dd00::/8. Das über

uci delete network.globals.ula_prefix

löschen oder direkt das Skript /etc/init.d/gl_ipv6 im Abschnitt set_lan_relay bearbeiten.

Dein nächster Schritt wäre, zu testen, ob nun das (gewünschte) VPN klappt. Soweit ich Dich verstand, willst Du nicht zwei GL.iNet untereinander koppeln, sondern Dich unterwegs mit diesem GL.iNet in ein Cloud-VPN einbuchen. Richtig? Das wird dann super bunt, weil Du ja dann auch noch eine globale IPv6 von dem VPN-Dienst bekommst. Egal. Berichte mal oder sag uns welchen VPN-Dienst Du genau nutzen willst. Dann baue ich auch das hier mal nach.

 

[frank.pcn]

Ist das eine Beta? Bei mir wird die als Release angezeigt …

Für den Brume hangle ich mich von einer Nightly Build zur nächsten aus diesen Quellen bis zum offiziellen Release 3.201 für die Büchse. Bin gerade am Testen der snapshot20210424. Einmal via OpenVPN-Client bei CyperChost und via Wiregard-Client bei Mullvad. Am Servertunnel-Ende kann ich hier auch nicht auf IP-v6-Adresssen zugreifen, nur IPv4. Um die Serverseite zu testen, habe ich mir einmal ne t-mobile-SIM und D2-Vodafone schon zurecht gelegt.

Dein nächster Schritt wäre, zu testen, ob nun das (gewünschte) VPN klappt. Soweit ich Dich verstand, willst Du nicht zwei GL.iNet untereinander koppeln, sondern Dich unterwegs mit diesem GL.iNet in ein Cloud-VPN einbuchen. Richtig?

Richtig.
Letzt endlich möchte ich beide Richtungen Tunneln. Bin aber noch am testen. Dies ist nur Nachts möglich, sonst steigen mir die Frauen auf dem Kopf.
Ich bin noch so tief ins Backend abgestiegen. Nach der Arbeit ist bei mir meist nicht gleich Feierabend.

Hast Du mal statt OpenWrt schon das Image für Ubuntu probiert?

Noch nicht. Wenn das nächste offizielle Release genauso grausam gebacken ist, ist das Ubuntu-Image ein Versuch wert. Auf meinem Raspberry 4b (Debian) habe ich nur die OpenVPN-Client-Seite am laufen gebracht.

 

[sonyKatze]

Du solltest ab hier in einem OpenWRT zentrierten Forum weitermachen.

Noch der Link zum Cross-Post …

Für den Brume hangle ich mich von einer Nightly Build zur nächsten

Ja, habe gerade gesehen, dass Dein Modell sein eigenes Image bekommt …

Letzt endlich möchte ich beide Richtungen Tunneln.

Wenn Du Dein Ziel-Setup nachvollziehbar beschreiben könntest, dann versuche ich das irgendwann einmal nachzubauen. Dann kann ich direkt sehen, was los bzw. schief geht.

 

[frank.pcn]

Wenn Du Dein Ziel-Setup nachvollziehbar beschreiben könntest, dann versuche ich das irgendwann einmal nachzubauen. Dann kann ich direkt sehen, was los bzw. schief geht.

Sobald ich ein "Meilenstein" erreicht habe, lasse ich es dir wissen. Bisher funktioniert nur der VPN-Client (Zum VPN-Dienstanbier) des Brume. Über das Wireguard-Protokoll mit IPV4 & V6, OpenVPN nur IPv4. Hierzu habe ich in der FB die Einstellungen aus dem POST #6 vorgenommen um den Brume als kaskadierten Router laufen zu lassen.
Der WAN-Port des Brume bleibt als WAN. Da anscheinend der Brume in der letzten Nightly Build nicht in der Lage ist, den IPv6-Gateway der FB zu ermitteln, habe ich die "WAN-Einstellungen" des Brume manuell eingetragen.
Als IPv6-Gateway die lokale IPv6-DNS-Server-Adresse der FB , welche in der Rubrik "DNSv6-Server im Heimnetz" unter "Heimnetz"->"Netzwerk"->Registerkarte "Netzwerkeinstellungen"->Button "IPv6-Einstellungen" zu finden ist.
Die Brume eigene lokale IPv6 Adresse habe ich ebenfalls von der FB übernommen statt fe80= fd00::9683:c4ff:fe09:e237. Zu finden unter "Details für GL-MV1000" unter "Heimnetz"->"Netzwerk"->Registerkarte "Netzwerkverbindungen". So sieht es bisher aus.

Ich hoffe, unsere Netzwerkspezis lünchen mich nicht.

 

[sonyKatze]

nicht in der Lage […] den IPv6-Gateway der FB zu ermitteln, habe ich die "WAN-Einstellungen" des Brume manuell eingetragen.

Verstehe ich leider gar nicht. Du musst schon das machen, was ich in #14 schrieb, denn GL.iNet unterstützt IPv6 noch immer nicht richtig. Umso spannender, dass Du laut den Test-Seiten soviel „grün“ bekommst.

Als IPv6-Gateway die lokale IPv6-DNS-Server-Adresse der FB , welche in der Rubrik "DNSv6-Server im Heimnetz" unter "Heimnetz"->"Netzwerk"->Registerkarte "Netzwerkeinstellungen"->Button "IPv6-Einstellungen" zu finden ist.

Das ist nicht Dein Gateway (fe80…) sondern die ULA (fd00…) der FRITZ!Box. Allerdings sah ich hier beim Testen, dass OpenWrt irgendein Software-Fehler mit ULAs als DNS-Server hat. Bin ich gerade am debuggen! Daher mein Tipp: An jener Stelle in der Web-Oberfläche der FRITZ!Box keine ULA sondern erstmal eine globale IPv6 einzutragen, entweder jene die Du im FRITZ!Box Online-Monitor siehst (also jenen DNS-Server Deines Internat-Anbieters) oder einen öffentlichen DNS-Server …

Bisher funktioniert nur der VPN-Client (Zum VPN-Dienstanbier) des Brume.

Wenn Du das ein wenig mehr erklärst … dann könnte ich hier mitbasteln. Welchen VPN-Diensteanbieter nutzt Du genau? Stehe gerade auf dem Schlauch, wen Du meinst. Die Frage ist nämlich, ob der DNS-Verkehr richtig über das VPN geleitet wird, also ob die ganzen Server bei Deinem LAN-Client richtig eingetragen werden.

 

[frank.pcn]

Wenn Du das ein wenig mehr erklärst … dann könnte ich hier mitbasteln. Welchen VPN-Diensteanbieter nutzt Du genau? Stehe gerade auf dem Schlauch, wen Du meinst. Die Frage ist nämlich, ob der DNS-Verkehr richtig über das VPN geleitet wird, also ob die ganzen Server bei Deinem LAN-Client richtig eingetragen werden.

Ich hänge hier mal eine "Tapete" mit Kritzeleien ran und ein Teil der gesicherten Konfigurationsdateien, welche ich mit LuCI exportiert habe.
Als VPN-Anbieter habe ich zwei zur Auswahl. Einmal CyberGhost, leider ohne IPv6 Unterstützung, ....und Mullvad.

 

[sonyKatze]

Wenn Dein VPN-Anbieter kein IPv6 bietet, warum machst Du Dir darum einen Hals? Also, was ich gebraucht hätte, war: „Ich möchte mit meinem GL.iNet Brume den VPN-Anbieter Mullvad über WireGuard nutzen.“ Fertig. Was ich dann noch bräuchte wäre:

• Warum willst Du IPv6 haben?
• Willst Du das nur von daheim (Telekom Deutschland mit Dual-Stack und FRITZ!Box) oder vielleicht in Zukunft auch unterwegs (von einem beliebigen Internet-Anschluss)?