AW: VPN an Fritz!Box Fw 7.27 funktioniert nur bedingt

[#1]

Hallo Community,

Nach dem Update der FB 7590 auf Firmware 7.27 habe ich - da ich in den Release-Infos von Verbesserungen las - mal wieder die VPN-Anbindung von Android über MyFritz getestet.
Nichts (was vorher funktionierte) ging mehr. Weder das FB-eigene VPN, noch OpenVPN auf einen zweiten Server (durch den FB-Router).
Deshalb habe ich zunächst die MyFritz-Konto-Funktionalität und die Berechtigungen der verwendeten Nutzer geprüft. Alles OK. Der verwendete Nutzer, der Zugriffsrecht aus dem Internet hat, ist auch VPN-berechtigt.

Verlauf MyFritz-VPN: Die Einstellungen habe ich aus der FB-Anleitung in die Einstellungen meines Android-11-Pixel5 kopiert und exakt abgeglichen (Server ist die MyFritz-Adresse). Die Verbindung konnte nicht aufgebaut werden. ABER: Wenn ich WLAN am Smartphone aus und einschaltete, wurde in einem 3-Sekunden-Zeitfenster nach Umschaltung unter WLAN die Verbindung etabliert. Dann habe ich statt der MyFritz-Adresse (die ja ansonsten für in- und externen Zugriff einwandfrei funktioniert) die aktuelle IPv4 eingetragen. Danach war VPN per WLAN und LTE möglich. Allerdings funktionierte der Zugriff aufs LAN nicht vollständig wunschgemäß.

Verlauf bei OpenVPN: Der Zugriff funktioniert über ein DynDNS-Adressbereitstellung. Die Freigaben in der FB für die Portweiterleitung sind gesetzt und haben auch immer funktioniert. Nun nicht mehr. Nachdem ich einen externen Nicht-Standardport (x statt 1194) und TCP statt UDP verwendet habe, konnte die Freigabe wieder verwendet werden und OpenVPN baut wieder einen Tunnel auf. FB verweigert ja die Mehrfachverwendung von internen Ports (was ich nur bei externen verstehen kann) in den Portweiterleitungen.

Hat jemand ähnliche Probleme? Wie habt ihr sie womöglich gelöst?

Meine Ziele:
- UDP und TCP sollten funktionieren.
- Auch der Zugriff über den externen VPN-Standardport (1194 UDP) sollte gleichzeitig für MyFritz-VPN und OpenVPN möglich sein.
- Der Zugriff über dynamische IPs (speziell MyFritz) MUSS wie spezifiziert funktionieren.
- Bei etabliertem MyFritz-VPN-Tunnel soll der Zugriff auf alle LAN-Adressen ungehindert funktionieren.

Für Lösungen und Anregungen jeder konstruktiven Art bin ich dankbar.

Jochen Kuhla

[#2 · Accepted solution]

@alle

So, nach umfangreichen Recherchen, Anfragen und Tests ist es jetzt klar (...). Unter Android 11 gibt es bekannte Probleme mit dem VPN-Tunneling von Pixel zu Fritzbox. Wenn das Android 11-Gerät einen APN (Access Point Name) verwendet, der auch IPv6 unterstützt, kann die MyFritz-Adresse nicht so aufgelöst werden, dass die FB eine VPN-Anfrage verarbeiten kann. AVM sieht die Ursache in Android 11, wahrscheinlich zeigen alle Beteiligten da mit allen Fingern einer Hand auf die jeweils Anderen.

Zwei Lösungen:

1) Anlage eines zusätzlichen APN-Eintrags im Smartphone, in dem nur folgende Einträge gegenüber dem v6 geändert werden:

APN: internet.telekom

Benutzername: t-mobile
Passwort: tm
Authentifizierungstyp: PAP
APN-Typ: default,supl 

APN-Protokoll IPv4

Diese Definition kann dann bei Bedarf aktiviert werden. Ist sie aktiv, ist der IPv6-Verkehr ins Internet abgeschaltet!

2) Verwendung der MyFritz-App für den Tunnelaufbau. Das funktioniert, allerdings sind die Konfigurationshintergründe intransparent, der Nutzer kann nicht ausgewählt werden und die Verbindung scheint nicht wirklich stabil zu sein.

Ich habe wegen der besseren Konfigurierbarkeit, der höheren Stabilität und der deutlich besseren plattformübergreifenden Verwendbarkeit (Fritz und Windows mögen sich nicht) die OpenVPN-Variante zum Standard gemacht. Das hilft allerdings nur, wenn man die OpenVPN-Infrastruktur im Heimnetz verfügbar hat.

[#3]

---

@JKuhla  schrieb:
Weder das FB-eigene VPN

Die funktioniert definitiv sogar beides entweder VPN Fritzbox oder MyFritz App mit der 7.27 

[#4]

---

@JKuhla  schrieb:[...]

- Auch der Zugriff über den externen VPN-Standardport (1194 UDP) sollte gleichzeitig für MyFritz-VPN und OpenVPN möglich sein. [...]

---

Wie soll das denn gehen, woran soll die Box erkennen ob ein eingehendes Paket für das MyFritz-VPN-Gateway oder für das OpenVPN-Gateway bestimmt ist?

[#5]

---

@JKuhla  schrieb:

Für Lösungen und Anregungen jeder konstruktiven Art bin ich dankbar.

---

Das ist ja nun ein AVM-Thema, da dürfte AVM der bessere Ansprechpartner sein.

[#6]

@Thunder99 : Vielen Dank für Ihre Mühe. Vielleicht lassen wir doch noch andere zu Wort kommen.

@lejupp : Da ist natürlich was dran. Wahrscheinlich habe ich hinter MyFritz einfach mehr vermutet als einen simplen IP-Dynamisierer. Sinnvoll wäre dann natürlich, wenn man die Portzuweisung (für das integrierte VPN) beeinflussen könnte. OpenVPN lässt zumindest freie Port-Auswahl für den VPN-Dienst zu.

@olliMD : Da haben Sie wohl recht.

[#7]

@all:

Ich hab jetzt nochmal etwas rumprobiert und wahrscheinlich das Problem isoliert.

FB verhält sich bei der Portweiterleitung untypisch. Anders als es Router sonst tun. Bei der Portweiterleitung kann ein bestimmter *interner* Port nur einem (1) Netzwerkgerät zugeordnet werden. Normalerweise ist es so, dass in der Portweiterleitung durch den eingehenden (*externen*) Port ein Gerät identifiziert wird, an dessen IP die Pakete unter der internen Portkennung weitergeleitet werden. So können im LAN mehrere Geräte typische Ports geöffnet halten (z.B. bei RDP sehr relevant). Eigentlich eine wichtige Sache. 

Die FB scheint hier nicht sauber trennen zu können. Die Pakete - so meine Hypothese - werden trotz abweichender IP irgendeinem Gerät zugewiesen, das den entsprechenden Port geöffnet hat. Auf jeden Fall passiert das mit Ports, die in der FB offen sind - hier der 1194 UDP. Welches Paket auch immer ins LAN geschickt wird - identifiziert es sich intern über 1194 UDP, schluckt es die FB.

Ich habe nun die OpenVPN-Server mit jeweils eigenen Ports intern und extern konfiguriert und so scheint es zu funktionieren. Zumindest werden die Tunnel aufgebaut und IPs im LAN können korrekt adressiert werden.

Wäre vielleicht für AVM interessant, sich hier nochmal die Verfahren anderer Hersteller anzuschaun.

[#8]

Bei mir läuft openvpn auf einem völlig unkanonischen Port. Das empfielt sich schon deshalb, weil dann ein Angreifer das Gateway nur findet wenn er vorher einen Portscan macht und alle offenen Ports auf seine Lücke hin testet.

[#9]

---

@JKuhla  schrieb:
[...] So können im LAN mehrere Geräte typische Ports geöffnet halten (z.B. bei RDP sehr relevant). Eigentlich eine wichtige Sache. [...]

---

Nicht direkt zum Thema, aber vielleicht doch relevant. Hier ein Auszug aus einem Text von Microsoft zum Thema RDP am Internet:

Although Remote Desktop Services (RDS) can be a fast way to enable remote access for employees, there are a number of security challenges that need to be considered before using this as a remote access strategy. One of these challenges is that attackers continue to target the RDP and service, putting corporate networks, systems, and data at risk (e.g., cybercriminals could exploit the protocol to establish a foothold on the network, install ransomware on systems, or take other malicious actions). In addition, there are challenges with being able to configure security for RDP sufficiently, to restrict a cybercriminal from moving laterally and compromising data.

Andere Seiten empfehlen generell keine RDP-Hosts direkt ins Internet zu hängen. Warum lässt Du RDP nicht über das VPN laufen wenn Du schon eins hast?

[#10]

@lejupp :

Vielen Dank für Ihre Rückmeldung.  RDP war ein *Beispiel* für eine Anwendung, die im LAN womöglich eine Vielzahl von Adressaten unter einem Standardport hat. Die öffentliche Verwendung von 3389 TCP wäre *ein* Grund für die Vulnerabilität. Das könnte man durch die Portweiterleitung "NichtStandard -> Standard" zumindest etwas absichern. Klar könnte man jeden Terminal mit eigenem Port konfigurieren, das wäre aber nicht administrierbar.  Die Fritz!-Regel: "Keine Mehrfachverwendung von internen Ports" zwingt in diesem Szenario also ins Administrationschaos. Aber natürlich ist der Zugriff über einen VPN-Tunnel einfacher und sicherer (so man einen funktionierenden hat).

Die Microsoftempfehlung ist aber aus anderer Sicht sehr relevant. Sie bezieht sich eben auch auf RDP als Beispiel. Grundsätzlich weist sie aber darauf hin, dass Standardports, die auf das WAN lauschen immer angreifbar sind. Das ist eben genau der wunde Punkt des FRITZ!vpn. Es zwingt zur Verwendung des Standardports 1194 UDP ins WAN, korrumpiert aber 1194 UDP im LAN.  Widersinnig und gefährlich.

[#11]

---

@lejupp  schrieb:

Bei mir läuft openvpn auf einem völlig unkanonischen Port. Das empfielt sich schon deshalb, weil dann ein Angreifer das Gateway nur findet wenn er vorher einen Portscan macht und alle offenen Ports auf seine Lücke hin testet.

---

Genau. Das geht über die Port-Weiterleitung in den Fritz-Freigaben (WAN auf OpenVPN-Server). Für die Auswahl des internen OpenVPN-Ports ist dieses Argument aber nicht relevant. Der darf durchaus dem Standard entsprechen. Nur eben nicht bei Fritz! Denn die FB greift 1194 UDP (VPN-Standard) sogar intern ab und öffnet ihn mandatorisch sperrangelweit nach außen. Das ist genau das Problem.

[#12]

---

@JKuhla  schrieb:
[...] Die Fritz!-Regel: "Keine Mehrfachverwendung von internen Ports"[...]

Also eine Regel ist das bestimmt nicht, bestenfalls ein Bug. Ich habe hier eine 7580, zwei hohe hintereinanderliegende TCP-Ports sind intern auf den jeweils gleichen, hohen, Port an zwei verschiedenen Maschinen weitergeleitet. Dort lauscht jeweils der SSHd. Das läuft absolut problemlos

[#13]

@alle Das Problem ist doch nur teilweise gelöst. Eine Beobachtung würde ich von den Fritz-VPN-Nutzern im Forum gerne bestätigt oder widerlegt haben, vielleicht gibt es ja einen Tipp, das Problem zu umgehen:

Wenn ich in den VPN-Einstellungen meines Pixel5 (Android 11) die MyFritz-Adresse als Server eintrage (so sieht es die Anleitung vor), kann keine Verbindung hergestellt werden. Auch andere Dyn-Adressen versagen. Eine Verbindung kann nur mit der aktuellen IPv4 hergestellt werden.

Die MyFritz-Adresse an sich ist aber valide. Der Oberflächenzugang und der Ping sind positiv. Sogar wenn ich statt meiner gewöhnlichen DynDNS-Adresse in der OpenVPN-Konfiguration die MyFritz-Adresse eintrage, erhalte ich Zugriff. Es scheint, als ob die FB (7590 Fw7.27) die dynamische Notation anders als die native Form verarbeiten würde, und als ob noch eine weitere Information (Zertifikat oder Port-Angabe) fehlte. Wenn ich die LetsEncrypt-Zertifikat-Authentifizierung abschalte, oder den Standard-Port in der Server-Angabe der VPN-Konfiguration ergänze, bewirkt das allerdings keine Besserung.

Also: hat jemand Erfahrung unter Android 11 und Fw 7.27 mit der Verwendung der MyFritz-Adresse für den VPN-Zugang?

Bin für alle konstruktiven Tipps dankbar!

[#14 · Accepted solution]

@alle

So, nach umfangreichen Recherchen, Anfragen und Tests ist es jetzt klar (...). Unter Android 11 gibt es bekannte Probleme mit dem VPN-Tunneling von Pixel zu Fritzbox. Wenn das Android 11-Gerät einen APN (Access Point Name) verwendet, der auch IPv6 unterstützt, kann die MyFritz-Adresse nicht so aufgelöst werden, dass die FB eine VPN-Anfrage verarbeiten kann. AVM sieht die Ursache in Android 11, wahrscheinlich zeigen alle Beteiligten da mit allen Fingern einer Hand auf die jeweils Anderen.

Zwei Lösungen:

1) Anlage eines zusätzlichen APN-Eintrags im Smartphone, in dem nur folgende Einträge gegenüber dem v6 geändert werden:

APN: internet.telekom

Benutzername: t-mobile
Passwort: tm
Authentifizierungstyp: PAP
APN-Typ: default,supl 

APN-Protokoll IPv4

Diese Definition kann dann bei Bedarf aktiviert werden. Ist sie aktiv, ist der IPv6-Verkehr ins Internet abgeschaltet!

2) Verwendung der MyFritz-App für den Tunnelaufbau. Das funktioniert, allerdings sind die Konfigurationshintergründe intransparent, der Nutzer kann nicht ausgewählt werden und die Verbindung scheint nicht wirklich stabil zu sein.

Ich habe wegen der besseren Konfigurierbarkeit, der höheren Stabilität und der deutlich besseren plattformübergreifenden Verwendbarkeit (Fritz und Windows mögen sich nicht) die OpenVPN-Variante zum Standard gemacht. Das hilft allerdings nur, wenn man die OpenVPN-Infrastruktur im Heimnetz verfügbar hat.