@koyaanisqatsi
OK, das ist also der "Fehlerfall" ... sollte nach meiner Meinung auch nicht auftreten (entweder schlecht umgesetzt oder schlecht dokumentiert von AVM), aber gehen wir mal davon aus, daß AVM tatsächlich auch Traffic von so einem Gerät , welches ein Profil mit Whitelist zugewiesen bekam, an VPN-Clients aus demselben Netz (Host-LAN aka "conntype_user") oder auch an entfernte LANs (das wäre noch logischer, weil da die Ziel-IP nicht mehr im lokalen IP-Segment läge) unterdrückt.
Was gibt man jetzt genau in der Whitelist an, damit dieser Zugriff dann doch wieder funktioniert? Wo hat denn ein VPN-Client (mit Android) einen eigenen DynDNS-Namen her, den man da jetzt eintragen soll, wenn ich das richtig verstanden habe? Oder soll ich da tatsächlich den DynDNS-Namen der Box eintragen?
Aber selbst wenn das mit so einem Whitelist-Eintrag dann funktioniert, halte ich das auf folgendem Grund für einen Fehler: Soweit mir bekannt, gibt es nur eine einzige Whitelist in der Filterung des FRITZ!OS und die gilt für alle Profile, in denen diese Beschränkung aktiviert ist. Da gibt es keine individuelle Whitelist für Profile und schon gar keine für einzelne Geräte.
Damit führte so ein Eintrag für den VPN-Client (der dann zumindest der Theorie nach tatsächlich mit seiner (lokalen) IP-Adresse dort eingetragen werden könnte, denn die hat er ja) dann wieder dazu, daß jedes andere System mit einem Whitelist-Profil ebenfalls mit diesem Client "reden" darf ... und wenn das nicht tatsächlich mit dessen IP-Adresse in der Whitelist funktioniert, sondern über den DynDNS-Namen der Box selbst, dann sollte das auch wieder automatisch für jeden anderen VPN-Client hinter einer Host-LAN-Verbindung ebenfalls gelten und wäre dann so etwas wie ein "VPN erlaubt"-Eintrag (zumindest für Host-LAN-Verbindungen) in der Whitelist.
Wenn man in die Whitelist tatsächlich den eigenen (lokalen) DynDNS-Namen einträgt und der auf die externe IPv4-Adresse auflöst, aber per NAT-Hairpinning dann doch wieder lokal behandelt wird, ist das zumindest auch "komisch" und etwas undurchsichtig ... m.E. dann auch eher wieder ein unbeabsichtigter "side effect" als irgendeine sinnvolle (und absichtliche) Implementierung, weil das mit einer simplen Checkbox "Lokaler Zugriff auch über externe Adressen erlaubt" oder auch "Zugriff auf/für VPN-Clients erlaubt" (es sind ja eigentlich zwei getrennte Fälle) wesentlich simpler, eindeutiger und universeller zu lösen wäre bei der Konfiguration dieser (systemweiten) Whitelist.
Aber bei keiner dieser beiden Interpretationen verstehe ich nun meinerseits, wie das beim Einrichten des Szenarios beim TO helfen würde. Der will ja offensichtlich nicht seinen Server mit dem FTP-Service so weit von allem anderen abschirmen, daß der nur noch mit Adressen aus der Whitelist kommunizieren darf, sondern er will eine VPN-Verbindung so beschränken, daß darüber nur der FTP-Zugriff auf ein einzelnes Gerät funktioniert. Um die Unzulänglichkeiten (keine Filterung von eingehendem Verkehr über den Tunnel) weiß er und die sind in seinem Fall nicht relevant (das andere Netz ist also nur "bedingt feindlich"). Was sollte hier jetzt ein Profil für diesen Server bringen, bei dem nur noch der Zugriff auf Whitelist-Einträge möglich ist? Wo ist mein "missing link"?
