Dann tippe ich doch mal wieder - frank und frei - auf MTU-Probleme, wo erst nach mehrfacher Wiederholung von Paketen dann ein geringerer Wert für die Verbindung benutzt wird.
Mein "üblicher" Tipp für einen "Ausschlußtest": Virtuellen Adapter benutzen und MTU (zunächst mal) auf einen Wert zwischen 1200 und 1300 einstellen (Standard ist 1380, iirc):
https://www.shrew.net/static/help-2.1.x/vpnhelp.htm?GeneralSettings.html
Wenn's das nicht bringt, die Einstellungen wieder rückgängig machen, ansonsten kann man sich mit schrittweise höheren Werten an die nutzbare Paketgröße heranrobben.
Die damit verbundene Theorie wäre es eben, daß die verwendeten Protokolle die verfügbare Paketgröße überschreiten und - im Falle von TCP-Verbindungen - dann nach Timeouts (und beim nächsten Sendeversuch) die Größe Stück für Stück reduziert wird, bis es dann irgendwann doch noch paßt. Allerdings paßt die auch wieder nicht so recht dazu, daß auch
ping (also ICMP-Pakete mit geringer Größe) nicht durchkommen sollen.
Gleichzeitig werde ich das Gefühl nicht los (obwohl es weder explizit erwähnt, noch explizit ausgeschlossen wird), daß hier die eine VPN-Verbindung beendet wird und unmittelbar (oder zumindest sehr kurz) danach dann die andere verwendet werden soll. Wenn diese Vermutung(!) zutreffen sollte, dann kann es auch gut sein, daß die vorherige Verbindung (bzw. deren SAs, die ja auch mit entsprechenden XFRM-Regeln verbunden sind) erst mal durch die DPD (Dead Peer Detection) abgeräumt werden muß, bevor mit derselben Client-IP (die ja am zur Einwahl verwendeten Konto hängt, wenn das hier eine "conntype_user"-Verbindung ist - auch das ist ja nur eine Vermutung, weil nicht explizit vom Fragesteller erwähnt) dann eine Verbindung aufgebaut werden kann/sollte. Zumindest würde das erwähnte Timing auch zu dieser Theorie passen - DPD-Pakete sollten beim AVM-VPN im 30 Sekunden-Abstand gesendet werden und nach dreimaligem Timeout wird die Verbindung als "getrennt" behandelt und die SAs abgeräumt - zumindest war das früher mal so. Aber auch hier gilt - wie immer bei VPN-Problemen - der Blick in die Protokoll-Dateien als "Königsweg" bei der Erkennung, wo es nun konkret im Netzwerk klemmen könnte ... zumal man beim Shrewsoft-Client ja ALLES protokollieren lassen kann, bis hinunter zur Paketebene und wenn man da dann Timeouts beim Warten auf Antworten und daraus folgende Wiederholungen sieht, dann darf man davon ausgehen, daß die Pakete den Peer nicht (bzw,. nicht gültig) erreicht haben und der gar keine Chance auf eine Antwort hatte.
Aber mal ehrlich (nicht als "Angriff" mißverstehen) ... mit dem, was man zu diesem Problem alles NICHT weiß, kann man ganze Bibliotheken füllen. Zwar ist es hier kaum bekannt bzw. eher selten "diskutiert", aber den "Shrewsoft VPN Client" gibt es eben nicht nur für Windows, sondern auch für *nix:
https://www.shrew.net/software - und die einzige Erwähnung von "Windows" findet sich hier in diesem Beitrag und in der Signatur von irgendjemand anderem. Es ist also noch nicht einmal ZWINGEND, daß es hier auch um die Windows-Version des Clients geht ... zumal VNC (im Gegensatz zu RDP oder TeamViewer - wobei letzterer auch "VNC-ähnlich" arbeitet, afaik) auch eher selten ist beim Zugriff auf die graphische Oberfläche eines "entfernten" Computers (auch wenn Raspbian einen VNC-Service - out of the box - mitbringt).
Dazu kommt dann noch die fehlende Kenntnis, WAS das nun wirklich für eine VPN-Verbindung ist ("conntype_user" vs. "conntype_lan") und das Fehlen SÄMTLICHER Protokolle - sowohl auf der FRITZ!Box- als auch auf der SC-Seite. Das ist also - bei allen, unterstelle ich jetzt mal - maximal "educated guessing" und falls tatsächlich eine Theorie zutreffen sollte, wäre das - angesichts der zahlreichen Möglichkeiten, bei der Konfiguration von IPSec-VPNs etwas falsch zu machen - auch mehr ein Zufallstreffer (oder eben ein "häufig begangener Fehler") als das Ergebnis einer "echten Fehlersuche".
