Myfritz-Adresse funktioniert nicht korrekt

[n0bbi]

Hallo zusammen,

ich habe anscheinend mit meiner MyFritz-Adresse ein Problem, das ich mir nicht ganz erklären kann. Folgendes ist mir aufgefallen:

- Port-Weiterleitungen in der Fritzbox funktioniert für HTTP, nicht für FTP (Gegenprobe mit IP-Adresse klappt)

- VPN vom Android-Handy aus funktioniert nicht mit Myfritz-Adresse, mit IP und DynDNS hingegen schon.

- VPN vom Android-Handy mittels App "VPNCilla" funktioniert hingegen auch mit der MyFritz-Adresse.


Wirklich greifbar ist es für mich leider nicht, deshalb fehlt mir auch etwas der Ansatz, wie ich hier weitermachen könnte. Hat vielleicht jemand eine Idee?

Vorhandene Hardware:

• Fritzbox 7590 mit FritzOS 7.21
• Pixel 5 mit Android 11

Vielen Dank

 

[n8mahr]

was genau ist denn das Problem? wenn vpncilla funktioniert, aber das "normale" android-vpn nicht, ist es eher eine Frage des verwendeten Protokolls (oder ein Tippfehler beim Passwort), würde ich mal so ins blaue raten. Habe auch beides in Verwendung, bevorzuge aber vpn-zilla wegen der black/whitelisting funktion.

 

[burglar225]

Ich hatte da auch mal einige seltsame Probleme, die sich darauf zurückführen ließen, dass beim Zugriff von außen nicht nur der My-Fritz-Host angegeben werden muss, sondern auch davor der Name des Geräts. Z.B:
<MeinGerätXY>.<MyFritz-Adresse>.myfritz.net

 

[n0bbi]

was genau ist denn das Problem? wenn vpncilla funktioniert, aber das "normale" android-vpn nicht, ist es eher eine Frage des verwendeten Protokolls (oder ein Tippfehler beim Passwort), würde ich mal so ins blaue raten. Habe auch beides in Verwendung, bevorzuge aber vpn-zilla wegen der black/whitelisting funktion.

Hallo,

Tippfehler bei Benutzername & Passwort kann ich ausschließen. Sobald ich die IP eingebe funktioniert es, mit der Myfritz-Adresse hingegen nicht.

Ja, mit VPNCilla funktioniert es. Nichtsdestotrotz möchte ich gerne wissen und verstehen, was das Problem ist.

Ergänzung (20. Oktober 2020)

Ich hatte da auch mal einige seltsame Probleme, die sich darauf zurückführen ließen, dass beim Zugriff von außen nicht nur der My-Fritz-Host angegeben werden muss, sondern auch davor der Name des Geräts. Z.B:
<MeinGerätXY>.<MyFritz-Adresse>.myfritz.net

Danke, das hat leider auch nicht geholfen.

 

[Raijin]

Du verdrehst ein wenig die Begriffe.

myfritz IST ein DDNS/DynDNS.

Wenn eine Verbindung von außen, egal was es nu genau ist, mit der öffentlichen IP funktioniert und auch mit einem externen DDNS-Anbieter, aber mit myfritz nicht, dann ist die Ursache bei der Aktualisierung von der myfritz-Domain zu suchen.

Du kannst das ganz einfach prüfen:

Die öffentliche IP in der Fritzbox nachschauen und sicherheitshalber zB mit https://www.wieistmeineip.de/ abgleichen. Anschließend die beiden DDNS-Domains abfragen:

Start --> cmd
--> nslookup blabla.myfritz.gedöns
--> nslookup der.andere.ddns

Beide nslookups müssen die öffentliche IP aus dem ersten Schritt zurückgeben. Ist das nicht der Fall, dann hat das Update nicht geklappt. Optional kann man hinter die nslookup Kommandos auch noch 8.8.8.8 hinzufügen, um explizit den google-dns zu befragen (nslookup blabla.myfritz.gedöns 8.8.8.8), um auf Nummer sicher zu gehen.

 

[n8mahr]

was raijin sagt. eventuell hilft es auch, die myfritz adresse auf der fritze zu löschen und neu anzulegen; hatte da vor einer weile auch mal nen bug, dass die nach nem firmwareupdate der box einfach nicht mehr sauber funktionierte.

 

[n0bbi]

Du verdrehst ein wenig die Begriffe.

myfritz IST ein DDNS/DynDNS.

Wenn eine Verbindung von außen, egal was es nu genau ist, mit der öffentlichen IP funktioniert und auch mit einem externen DDNS-Anbieter, aber mit myfritz nicht, dann ist die Ursache bei der Aktualisierung von der myfritz-Domain zu suchen.

Du kannst das ganz einfach prüfen:

Die öffentliche IP in der Fritzbox nachschauen und sicherheitshalber zB mit https://www.wieistmeineip.de/ abgleichen. Anschließend die beiden DDNS-Domains abfragen:

Start --> cmd
--> nslookup blabla.myfritz.gedöns
--> nslookup der.andere.ddns

Beide nslookups müssen die öffentliche IP aus dem ersten Schritt zurückgeben. Ist das nicht der Fall, dann hat das Update nicht geklappt. Optional kann man hinter die nslookup Kommandos auch noch 8.8.8.8 hinzufügen, um explizit den google-dns zu befragen (nslookup blabla.myfritz.gedöns 8.8.8.8), um auf Nummer sicher zu gehen.

Sorry, falls ich mich etwas ungenau ausgedrückt habe.

Nachdem die Myfritz-Adresse in einigen Fällen eben funktioniert hätte ich nicht gedacht, dass es an der Namensauflösung scheitern könnte. Nichtsdestotrotz habe ich einen nslookup und ping durchgeführt:

C:\Users\marco>nslookup xxx.myfritz.net
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  fd00::f64d:30ff:fe6a:afff

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.

C:\Users\marco>ping xxx.myfritz.net

Ping wird ausgeführt für xxx.myfritz.net [xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx] mit 32 Bytes Daten:
Antwort von xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: Zeit=1ms
Antwort von xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: Zeit=1ms
Antwort von xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: Zeit<1ms
Antwort von xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx: Zeit<1ms

Ping-Statistik für xxxx:yy:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

C:\Users\marco>ping -4 xxx.myfritz.net

Ping wird ausgeführt für j3yuk8mnsulzfgxc.myfritz.net [12.34.56.78] mit 32 Bytes Daten:
Antwort von 12.34.56.78: Bytes=32 Zeit<1ms TTL=63
Antwort von 12.34.56.78: Bytes=32 Zeit=1ms TTL=63
Antwort von 12.34.56.78: Bytes=32 Zeit=1ms TTL=63
Antwort von 12.34.56.78: Bytes=32 Zeit<1ms TTL=63

Ping-Statistik für 91.17.30.29:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 0ms, Maximum = 1ms, Mittelwert = 0ms

C:\Users\marco>

Das kann ich mir nun gar nicht mehr erklären. Warum funktioniert die Namensauflösung beim Ping, aber nicht beim nslookup?

Ergänzung (20. Oktober 2020)

was raijin sagt. eventuell hilft es auch, die myfritz adresse auf der fritze zu löschen und neu anzulegen; hatte da vor einer weile auch mal nen bug, dass die nach nem firmwareupdate der box einfach nicht mehr sauber funktionierte.

Das habe ich bereits versucht, ohne Erfolg.

 

[Raijin]

Das kann ich mir nun gar nicht mehr erklären. Warum funktioniert die Namensauflösung beim Ping, aber nicht beim nslookup?

Dafür hast du doch selbst gesorgt

Windows nutzt bevorzugt IPv6, wenn verfügbar. Beim nslookup sieht man das deutlich, weil ein IPv6-DNS befragt wird, der dann aber nicht antwortet - DNS timeout. Beim Ping schreibst du explizit -4 und dann wird Windows zwingend IPv4 nehmen und eben auch einen IPv4-DNS befragen.

Wenn du nslookup zu IPv4 zwingen willst, dann gib die IP des DNS als letzten Parameter an, zB nslookup computerbase.de 192.168.178.1


Grundsätzlich kann das aber durchaus die Ursache für dein Problem sein, IPv4 vs IPv6.

 

[Mickey Mouse]

nslookup fragt den konfigurierten Nameserver, ping fragt "das System", geht also z.B. auch über die "/etc/hosts" (oder wie immer das wieder bei DOS/Windows läuft).

 

[Myron]

@n0bbi Was für einen Provider hast du denn? Ist überhaupt eine öffentlich erreichbare IPv4 vorhanden?

 

[razzy]

Check mal bitte, ob du eine IPv6 Adresse an deinem Netzwerkanschluss besitzt (Client Port).
Wenn du IPv4 erreichen kannst aber IPv6 nicht, würde ich hier mal anfangen

 

[n0bbi]

Danke für die Antworten! Ich besitze einen normalen Telekom-Anschluss.

Hier von myfritz.net

Die externe IPv4 passt, bei IPv6 bin ich fachlich leider raus. Das gab es zu meinen Lehr- und Studienzeiten noch nicht

Ergänzung (20. Oktober 2020)

Tatsächlich weiß ich jetzt wirklich nicht mehr weiter. Ich habe zu Testzwecken IPv6 auf meinem Handy deaktiviert (APN-Protokoll auf IPv4 only gestellt). Nun behauptet er, dass er den Namen xxxyyyzzz.myfritz.net nicht auflösen kann.

Es scheint also schon irgendwie daran zu liegen. Hat jemand eine Idee wie ich jetzt weitermachen könnte?

Danke!

Ergänzung (20. Oktober 2020)

Das wird für mich immer undurchsichtiger...

vom Windows-Rechner aus bekommt nslookup den Timeout wie oben beschrieben. Von meinem Ubuntu-Server bekomme ich IPv4 und IPv6 zurück:

marco@nuc:~$ nslookup xxxyyyzzz.myfritz.net
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   xxxyyyzzz.myfritz.net
Address: 12.34.56.78
Name:   xxxyyyzzz.myfritz.net
Address: 2003:xx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx

marco@nuc:~$

 

[Mickey Mouse]

also was offensichtlich ist: der Ubuntu Rechner fragt den Google NS ab, der ist also nicht "normal" als DHCP client an der Fritzbox konfiguriert, dann wäre sie nämlich der DNS. Selbst wenn man in der FB die DNS Anfragen auf etwas anderes als den vom Provider gestellten DNS umleitet, arbeitet sie für "ihre DHCP clients" als Proxy.
ich vermute mal, dass der Windows Rechner "anders verkonfiguriert" ist...

 

[n0bbi]

also was offensichtlich ist: der Ubuntu Rechner fragt den Google NS ab, der ist also nicht "normal" als DHCP client an der Fritzbox konfiguriert, dann wäre sie nämlich der DNS. Selbst wenn man in der FB die DNS Anfragen auf etwas anderes als den vom Provider gestellten DNS umleitet, arbeitet sie für "ihre DHCP clients" als Proxy.
ich vermute mal, dass der Windows Rechner "anders verkonfiguriert" ist...

Da gebe ich dir Recht. Irgendwas passt da nicht. Allerdings erklärt das nicht, warum der Zugriff auf myfritz aus dem Mobilfunk nicht klappt. Mittlerweile bin ich auch der Überzeugung, dass es an IPv6 liegt. In VONCilla sehe ich zumindest, dass er per IPv6 nicht Connecten kann, sondern auf IPv4 ausweicht. Vielleicht macht das der Android eigenen VPN Client nicht?