Routing Deutsche Glasfaser IPv6 (Carrier-grade NAT)
Hallo zusammen,
ich bin (immernoch) dabei einen OpenVPN Server auf IPv6 Basis mit einem Deutsche Glasfaser Anschluss aufzusetzen, leider ohne Erfolg.
Zu meiner Hardware: Ich benutze eine DreamMachine Pro von Ubiquiti und mein ISP hat leider Carrier-grade NAT.
Ich habe einen vServer mit 6tunnel eingerichtet, welchen ich aber vorerst einmal ausblende.
Ich will erstmal versuchen ob das Routing funktioniert. Dazu bin ich an einem anderen DSL Anschluss. Ich bekomme in dem Netzwerk
auch eine IPv6 Adresse. Wenn ich nun tracert auf meine IPv6 Adresse mache erhalte ich folgendes Routing:
Mir wurde in einem anderen Forum das sich speziell auf Ubiquiti beschränkt gesagt, dass das Routing nicht richtig arbeitet.
Da so Zitat:
Ich bin leider absolut kein Fachmann und bin für jeden Denkanstoß dankbar. Ich möchte einfach nur irgendwie wieder per VPN auf mein
Heimnetz zugreifen
Bitte nehmt mich nicht gleich auseinander..
LG
ich bin (immernoch) dabei einen OpenVPN Server auf IPv6 Basis mit einem Deutsche Glasfaser Anschluss aufzusetzen, leider ohne Erfolg.
Zu meiner Hardware: Ich benutze eine DreamMachine Pro von Ubiquiti und mein ISP hat leider Carrier-grade NAT.
Ich habe einen vServer mit 6tunnel eingerichtet, welchen ich aber vorerst einmal ausblende.
Ich will erstmal versuchen ob das Routing funktioniert. Dazu bin ich an einem anderen DSL Anschluss. Ich bekomme in dem Netzwerk
auch eine IPv6 Adresse. Wenn ich nun tracert auf meine IPv6 Adresse mache erhalte ich folgendes Routing:
Mir wurde in einem anderen Forum das sich speziell auf Ubiquiti beschränkt gesagt, dass das Routing nicht richtig arbeitet.
Da so Zitat:
Die Adresse 2a00:6020:ffff:ffff::20 müsste mit der Adresse deiner ETH8 (WAN) Schnittstelle übereinstimmen
-> Das hat nichts mit deinem Prefix zu tun oder der Adresse auf der du den Trace ausgeführt hast, diese muss aber übereinstimmen.
Um es kurz zu machen: Du hast korrekt ein Präfix bekommen von der Deutschen Glasfaser, aber die Deutsche Glasfaser bekommt es nicht gebacken diesen mit ihren eigenen Routern bis zu Dir durchzurouten (so sieht es für mich zumindest aus)
Das Thema hatte ich mit ein paar anderen DG Kunden bereits und leider sind die dort auch nicht sehr kompetent und Einsichtig was eine Problemlösung auf deren Seite entspricht.
Ich bin leider absolut kein Fachmann und bin für jeden Denkanstoß dankbar. Ich möchte einfach nur irgendwie wieder per VPN auf mein
Heimnetz zugreifen
Bitte nehmt mich nicht gleich auseinander..
LG
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1763328209
Url: https://administrator.de/contentid/1763328209
Ausgedruckt am: 16.11.2024 um 03:11 Uhr
22 Kommentare
Neuester Kommentar
Das hier:
https://www.heise.de/select/ct/2018/13/1529374309620058
https://www.heise.de/ratgeber/OpenVPN-Vernetzung-mit-IPv4-und-IPv6-41628 ...
hast du zu dem Thema gelesen ?
Das das Traceroute abbricht sollte dich nicht beunruhigen und muss nicht zwingend ein Zeichen einer ggf. falschen v6 Adressierung sein. Viele Provider blockieren ICMP auf ihren Infrastruktur Routern was dann zu solchen Fehlermeldungen führt wenn ICMP verwendet wird. Ein TCP Traceroute wäre dann zielführender.
Vermutlich blockiert auch deine Firewall eingehende ICMPv6 Echo Requests wie es bei Firewalls ja üblich ist auf extern exponierten Interfaces so das ein v6 Ping oder Traceroute deiner Firewall natürlich scheitert. Leider machst du ja zu deinen v6 Firewall Settings in Bezug auf ICMP keinerlei zielführende oder hilfreiche Aussagen und zwingst uns zur Kristallkugel.
Ein v6 Ping deiner Zieladresse ist ggf. sinnvoller wenn dein Endgerät (Firewall) eingehende ICMPv6 Echo Requests erlaubt.
Was ergibt z.B. ein ping -6 www.heise.de oder ein v6 Traceroute auf diese Adresse ?
https://www.heise.de/select/ct/2018/13/1529374309620058
https://www.heise.de/ratgeber/OpenVPN-Vernetzung-mit-IPv4-und-IPv6-41628 ...
hast du zu dem Thema gelesen ?
Das das Traceroute abbricht sollte dich nicht beunruhigen und muss nicht zwingend ein Zeichen einer ggf. falschen v6 Adressierung sein. Viele Provider blockieren ICMP auf ihren Infrastruktur Routern was dann zu solchen Fehlermeldungen führt wenn ICMP verwendet wird. Ein TCP Traceroute wäre dann zielführender.
Vermutlich blockiert auch deine Firewall eingehende ICMPv6 Echo Requests wie es bei Firewalls ja üblich ist auf extern exponierten Interfaces so das ein v6 Ping oder Traceroute deiner Firewall natürlich scheitert. Leider machst du ja zu deinen v6 Firewall Settings in Bezug auf ICMP keinerlei zielführende oder hilfreiche Aussagen und zwingst uns zur Kristallkugel.
Ein v6 Ping deiner Zieladresse ist ggf. sinnvoller wenn dein Endgerät (Firewall) eingehende ICMPv6 Echo Requests erlaubt.
Was ergibt z.B. ein ping -6 www.heise.de oder ein v6 Traceroute auf diese Adresse ?
bringen dich nicht weiter oder?
Nicht wirklich.... Keiner weiss welches Interface mit dem Screenshot gemeint ist...
- Das WAN Interface der Firewall ?
- Das interne OpenVPN Tunnel Interface
Das du den Heise Server pingen und tracerouten kannst zeigt das dein IPv6 generell sauber funktioniert.
Das du deine eigene Firewall WAN IP nicht pingen kannst kann, wie oben bereits gesagt, mehrere Ursachen haben.
- Firewall Regelwerk blockt ICMPv6
- lokales v6 Routing
So kannst du feststellen ob ein Ping mit deiner WAN IP als Source am Ziel ankommt.
Firewalls haben sowas in ihren Diagnostics Menüs wie hier z.B. eine pfSense/OPNsense Firewall:
Das kann aber natürlich nur dann klappen wenn das Firewall Regelwerk am WAN Port ICMPv6 passieren lässt oder, sollte das nicht der Fall sein, du verwendest alternativ ein TCP Protokoll basiertes Ping Tool.
Wie ist denn die Ubiquiti-Maschine ans Internet angebunden? Direkt am ONT angeschlossen oder ist da noch irgendeine andere Hardware dazwischen?
Und zu der zitierten Diagnose, das Netz wäre nicht korrekt zu dir geroutet:
Das hättest du gemerkt, wenn dem wirklich so wäre. Dann hättest du nämlich quasi keinen Internetzugriff auf irgendwelche Online-Dienste.
Die Diagnose ist also auf den ersten Blick erstmal falsch
Und zu der zitierten Diagnose, das Netz wäre nicht korrekt zu dir geroutet:
Das hättest du gemerkt, wenn dem wirklich so wäre. Dann hättest du nämlich quasi keinen Internetzugriff auf irgendwelche Online-Dienste.
Die Diagnose ist also auf den ersten Blick erstmal falsch
dass ich mich immer noch nicht per OpenVPN verbinden kann.
Alle Schritte des hiesigen OpenVPN Tutorials hast du entsprechend umgesetzt ??WAS sagt das Log des OpenVPN Servers wenn du mit einem Client zugreifst ?
Um die Firewall zu testen, lausche mit tcpdump auf dem Raspberry (als root) und gucke nach, ob eingehende Pakete kommen:
Das "ens3...." musst du durch den Namen des Netzwerk-Interface ersetzen.
Dann versuchst du, den Tunnel aufzubauen und dann siehst du ja, ob eingehende Pakete kommen und ob es Antworten gibt.
tcpdump -i ens3.... -nn "port 1194 || icmp6"
Das "ens3...." musst du durch den Namen des Netzwerk-Interface ersetzen.
Dann versuchst du, den Tunnel aufzubauen und dann siehst du ja, ob eingehende Pakete kommen und ob es Antworten gibt.
Das hilft - das heißt nämlich, dass deine Firewall die Pakete durchlässt (drittes Paket), dein Raspberry aber "unreachable Port" meldet. Das tut er nur, wenn auf dem Port kein Server lauscht.
Hast du in der OpenVPN-Server-Config explizit "proto udp6" angegeben? Sonst lauscht OpenVPN nur auf IPv4.
Kannst du auch nachsehen mit "ss -lnup" - wenn OpenVPN nur an die IP "0.0.0.0" gebunden ist, wird nur auf IPv4 gelauscht.
Hast du in der OpenVPN-Server-Config explizit "proto udp6" angegeben? Sonst lauscht OpenVPN nur auf IPv4.
Kannst du auch nachsehen mit "ss -lnup" - wenn OpenVPN nur an die IP "0.0.0.0" gebunden ist, wird nur auf IPv4 gelauscht.
Liest der OpenVPN-Server denn wirklich diese Config-Datei? Gerade ältere Anleitungen gehen teilweise davon aus, dass das die einzig richtige Config ist - mit Einzug von Systemd stimmt das aber eben nicht mehr zwingend.
Du kannst nachsehen, mit welchen Parametern dein Server gestartet ist - da sollte theoretisch auch der Config-Pfad auftauchen:
Du kannst nachsehen, mit welchen Parametern dein Server gestartet ist - da sollte theoretisch auch der Config-Pfad auftauchen:
ps ax | grep -F "openvpn"
systemctl | grep -F "openvpn"