Catch22 mit IPv6-Freigaben für openVPN-Server auf (Qnap)-NAS

[cbeckstein]

Trotz Suche stehe ich hier irgendwie auf dem Schlauch;
vielleicht kann mir da jemand runterhelfen

gegeben: Fritz!Box 7590 mit aktueller Labor-FW, Telekom-Anschluss (VDSL, Dual-Stack), NAS (Qnap) im Heimnetz (alle Geräte IPv6-fähig und -konfiguriert), auf dem ein openVPN-Server läuft

gesucht: ein Weg, um unter Nutzung des openVPN Servers auf dem NAS von aussen via IPv6 (!) eine openVPN-Verbindung ins Heimnetz herzustellen (via IPv4 habe ich da keinerlei Probleme, aber es soll ja über IPv6 passieren)

unter Nutzung der vom myFritz-DynDNS-Dienst gelieferten IPv6-Adresse der Box erfolglos probiert habe ich eine
Port-Weiterleitung von der Box auf das NAS für IPv6, UDP port 1194;
weiter als bis zum "UPD link remote [...]:1194" komme ich da aber nicht, wenn ich das VPN über IPv6 aufbauen will (Abbruch mit TLS timeout error nach 60 sec);

vermutlich müsste ich im openVPN client die IPv6-Adresse des NAS statt die der Box verwenden (unterstellt die Box justiert ihre Firewall entsprechend, wenn eine IPv6 Freigabe gemacht wird, eine eigentliche Weiterleitung braucht es dann ja nicht mehr),
die NAS-IPv6-Adresse liefert mir zwar der myFritz-Dienst, wenn ich eine myFritz-Freigabe statt einer Portfreigabe für das NAS und den Port 1194 mache,
nur kann ich bei einer myFritz-Freigabe nirgends spezifizieren, dass es sich um einen UDP port handelt und bekomme von ihr neben der IPv6 TCP (!)-Freigabe zusätzlich eine ungewünschte IPv4-Freigabe (ebenfalls für den TCP port 1194 statt den UDP port 1194)

was mache ich falsch oder lässt sich mein Wunsch nicht mit Fritzbox-Bordmitteln lösen?

 

[PeterPawn]

Zwei Freigaben verwenden ... irgendeine mit einem "dummy port" für MyFRITZ!, damit dort die IPv6-Adresse ordentlich registriert wird, denn das soll ja tatsächlich die des NAS und nicht die der Box selbst sein, und eine weitere (nicht-MyFRITZ!-)Freigabe dann für den benötigten UDP-Port. Bei einer DNS-Abfrage (auf AAAA) liefert der MyFRITZ!-DNS dann ja auch nur die IPv6-Adresse aus und nicht irgendeinen Port - es spielt also auch keine Rolle, welchen Port man da in der MyFRITZ!-Freigabe verwendet (solange da nicht wirklich irgendein Service auf dem NAS antwortet).

 

[cbeckstein]

OK... also

1) eine myFritz-Freigabe für irgendeinen Port, der mir in der Sicherheitsübersicht der Box nicht als verwendet angezeigt wird (oder gibt es Port-Nummern, die garantiert von niemandem verwendet werden und damit ungefährlich sind?),
wodurch ich dann

a) eine TCP IPv4 und eine TCP IPv6 Freigabe für diesen dummy port erhalte (stört nicht weil dummy port) und
b) eine myFritz-IPv6-DNS-Registrierung für mein NAS (das ist es, was ich für openVPN via IPv6 eigentlich brauche)

2) eine reguläre UDP IPV6-Portweiterleitung für den port 1194 von der Box auf das NAS mit dem openVPN server,
damit die Firewall der Box ncht die IPv6-Verbindung zum NAS blockiert

danke!

aber was denkt sich AVM eigentlich bei der Konzeption seiner beiden "Freigabe"-Mechanismen (Portfreigaben und myFritz-Freigaben),
wenn so ein Hack für so eine elementare Sache notwendig ist?

was AVM da als IPv6-Portfreigaben bezeichnet, sind doch, wenn ich das jetzt richtig verstanden habe, nur Justagen der Box-Firewall, bei denen aber im Gegensatz zu den IPv4-Portfreigaben nix mehr weitergeleitet wird weil das angsichts des Adress-Regimes von IPv6 eh sininlos ist

als ergonomisch oder gar benutzerfreundlich kann man das wohl nicht bezechnen...

oder sehe ich das falsch und tue AVM unrecht?

 

[cbeckstein]

hmm... irgendwas stimmt noch nicht:

habe neben den beiden Freigaben im obigen Sinn im Konfigurationsfile von openVPN

proto udp

ersetzt durch

proto udp6

bekomme aber beim Versuch, über Windows 10 pro die IPv6-VPN-Verbindung herzustellen, die Fehlermeldung

"RESOLVE: Cannot resolve host address YYYYYYYYYYYYYYYYYYYYYYYYYY:1194 (der angeforderte Namen ist gültig, es wurden jedoch keine Daten des angeforderten Typs gefunden)"

 

[PeterPawn]

Bei IPv4-Freigaben macht die Box (bei aktiviertem Packet-Accelerator auch "in Hardware") halt noch das "reverse NAT" und bei IPv6 wird nur noch geprüft, ob die Verbindung "erlaubt" ist, ansonsten wird ggf. noch ein wenig gezählt (für die Statistiken) und das Paket einfach weitergereicht. MyFRITZ!-Freigaben haben nur einen begrenzten "Einsatzzweck" (praktisch nur irgendwelche HTTP(S)-Protokolle, steht dort mehr oder weniger auch in der Beschreibung bei AVM) und da braucht es halt keine UDP-Ports und somit gibt es für den Benutzer (aus MyFRITZ!-Sicht) auch keine Notwendigkeit, da ein Protokoll auszuwählen.

Zitat AVM:
Mit MyFRITZ!-Freigaben können Sie jederzeit mit beliebigen Internetbrowsern über das Internet auf eine browserbasierte Anwendung im FRITZ!Box-Heimnetz zugreifen, z.B. auf einen Web-Server oder die grafische Oberfläche eines NAS-Systems.

Mach' doch einfach erst einmal selbst eine DNS-Abfrage (mit Typ AAAA) für die MyFRITZ!-Adresse (des Gerätes, nicht der Box !!!) ... dabei sollte dann die IPv6-Adresse des Gerätes zurückkommen. Ist das nicht der Fall, stimmt die Abfrage oder die DynDNS-Aktualisierung nicht.

Das oben sieht für mich eher so aus, als würde da der Port noch dem Namen hinzugefügt ... wenn Du das Debug-Level beim OpenVPN hochdrehst, solltest Du da auch genauer sehen können, was nun wirklich beim DNS-Server abgefragt wird.

Vielleicht ist ja auch nur die Fehlernachricht blöd formuliert ... aber beim "resolve" hat ein Port eigentlich nichts zu suchen; der interessiert erst beim Senden von ersten Daten.

Du hast nicht zufällig versehentlich den Port selbst hinter die Adresse gesetzt, anstatt den in einen "(r)port"-Parameter zu verpacken?

Wenn da der Validator für IPv6-Adressen den Namen prüft und nicht (100%) korrekt arbeitet (ich unterstelle mal, daß es dort überhaupt eine Gültigkeitsprüfung von Parametern gibt), dann sieht der vielleicht den Doppelpunkt und die Ziffern noch als gültige Bestandteile einer IPv6-Adresse an und läßt die durch, während der Resolver da gar nichts mehr prüft und einfach eine DNS-Abfrage macht - nur mal so aus dem Bauch heraus, was eine denkbare Erklärung sein könnte.

 

[cbeckstein]

Also die Namensauflösung (CNAME auf den kryptischen, von myFritz generierten Namen für das NAS) funktioniert...
IPv4-Adresse der Box und IPv6-Adresse des NAS wie in der Box nachsehbar
die Freigaben für openVPN (UDP port 1194) von Box auf NAS stehen auch (sowohl für IPv4 als auch IPv6)

aber openVPN will immer noch nicht über IPv6, zumindest nicht mit diesem config file (vom NAS generiert und auf IPv6 angepasst) - Abbruch mit TLS timeout error nach 60 sec:

client
dev tun2001
script-security 3
proto udp6
port 1194
explicit-exit-notify 1
remote CNAME-for-myFritz-generated-symbolic-name-for-NAS
resolv-retry infinite
nobind
ca ca.crt
auth-user-pass
reneg-sec 0
cipher AES-256-CBC
tls-cipher TLS-SRP-SHA-RSA-WITH-3DES-EDE-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA
comp-lzo

selbst dann nicht, wenn ich den CNAME... im remote durch die absolute IPv6-Adresse des NAS ersetze

habe den Verdacht, dass die Fritzbox Firewall mit IPv6 trotz der Portfreigabe für OpenVPN den Zugriff von extern auf das NAS blockiert (weirterleiten muss die bei IPv6 ja nix mehr)

openVPN über IPv4 (obiger config file mit "proto udp" statt "proto udp6") läuft völlig problemlos

strange...

 

[PeterPawn]

In der Support-Datei (bei den PCP-Freigaben) nachsehen, ob die auch tatsächlich freigeschaltet sind oder nicht ... wobei es durchaus denkbar ist, daß die (wieder einmal) einfach nicht richtig funktionieren. Das ist (zumindest bei den anderen Modellen) ja auch noch Baustelle gewesen (auch in der "info.txt" für die 06.90 erwähnt) und da kann man an die Stelle des bloßen Verdachts dann eigentlich nur den eigenen Paketmitschnitt und dessen Analyse setzen und selbst überprüfen, ob die UDP-Pakete des VPN-Clients nun überhaupt bei der FRITZ!Box ankommen und dann ins LAN expediert werden. Raten bringt da auch nur wenig ... es gibt einfach zuviele denkbare Fehlerquellen.