Ob zwei VPN-Verbindungen von Geräten HINTER einem Router gleichzeitig genutzt werden können, hängt auch davon ab, um welches VPN (bzw. welche Lösung) es sich handelt und wie der Router damit umgeht.
Bei einigen VPN-Solutions kommen auch (ungekapselte) Pakete zum Einsatz, die IP-Protokolle OHNE zusätzliche Portnummern verwenden (GRE mit IP-Protokollnummer 47, ESP mit 50, AH mit 51). Für solche Protokolle funktioniert dann natürlich auch das üblicherweise verwendete NAT (bzw. PAT) nicht, wo bei ausgehenden Verbindungen die interne Portnummer durch eine freie auf dem externen Interface (also mit der externen IPv4-Adresse) ersetzt wird und das in Antwort-Paketen aus dem Internet dann in der Gegenrichtung wieder rückgängig gemacht wird.
Bei solchen Konstellationen kann dann tatsächlich nur ein einzelner Client im LAN das VPN gleichzeitig verwenden - außer der Router trifft zusätzliche Vorkehrungen. Meist wird diese Eigenschaft eines Routers als "VPN Passthrough" bezeichnet, wobei hier oft zwischen PPTP-Passthrough und IPSec-Passthrough unterschieden werden muß und was der Router-Hersteller jetzt unter "VPN Passthrough" versteht, variiert auch sehr.
Bei IPSec (was auch bei MS mit L2TP/IPSec verwendet wird) gibt es häufig die erwähnte Einschränkung, daß nur ein Client gleichzeitig überhaupt ESP (was hier verwendet wird, GRE kommt eigentlich nur bei PPTP zum Einsatz) verwenden kann - es gibt ein paar Implementierungen, wo das zumindest dann auch mit mehreren Clients geht, wenn die Zieladressen der VPN-Verbindungen unterschiedliche Server (oder Konzentratoren) sind ... da kann man dann die Pakete auch wieder anhand der Kombination aus Sender- und Empfänger-Adresse auseinanderhalten. Bei PPTP gibt es dann im GRE-Header wieder eine "Call ID" (der GRE-Header ist noch unverschlüsselt), anhand derer man das Paket ggf. an den passenden Client im LAN senden kann - nur ist das (beim PPTP) alles deutlich aufwändiger und ich weiß nicht, ob das auch "in Hardware" (also mit dem Packet-Accelerator) vom GRX5 unterstützt wird und damit auch von AVM.
Auf alle Fälle gibt es auch bei AVM ein paar Einschränkungen, wie man hier:
https://avm.de/service/fritzbox/fri...es-anderen-Herstellers-im-Heimnetz-einsetzen/ nachlesen kann - allerdings sollen ja (nach dem KB-Artikel) auch bei IPSec keine Probleme auftreten, wenn die Gegenstellen unterschiedliche Adressen haben.
Ob die Implementierung aber in jeder Version auch so arbeitet, wie das vorgesehen ist (und die erste Homeoffice-Welle wg. der Pandemie lag ja noch vor der 07.2x), steht auf einem vollkommen anderen Blatt - ich kann mich gerade auch an irgendeine "Verbesserung" in den AVM-Infos für die neue Labor-Reihe erinnern, daß irgendwelche VPN-Pakete jetzt wieder "normal schnell" transportiert würden - selbst wenn das keinen direkten Zusammenhang mit dem Problem hier haben mag, illustriert es doch, daß auch da ständig gearbeitet wird und es auch mal Release-Versionen gibt, wo solche Dinge nicht optimal laufen.
======================================================================
Solange hier also im Dunklen bleibt, um was für ein VPN es sich (jeweils) handelt und wohin da verbunden werden soll, kann man auch nicht pauschal sagen, daß es (parallel) funktionieren müßte oder eben nicht. Zwei Laptops im LAN, die jeweils per MS-VPN (L2TP/IPSec) über einen VPN-Anbieter (über denselben Einwahlserver dort) arbeiten wollen, können jedenfalls durchaus zum Problem werden und zwei Leute in derselben Wohnung, die in derselben Firma (derzeit halt im Home-Office) arbeiten wollen/sollen, können genauso gegen die Wand fahren.
Spannend an diesem Fall ist es eigentlich nur, warum da die DSL-Verbindung (nach Event-Log) verloren gehen sollte ... ich rate mal, daß da tatsächlich der "dsld" abstürzt (das müßte entsprechende Spuren als "crash log" in der Support-Datei hinterlassen) und der dann bei seinem Neustart auch die neue Synchronisation anschiebt - aber das ist eben nur "geraten". Tatsächlich hätte ich eher erwartet, daß bei einem Absturz dieses Daemons (wenn das überhaupt tatsächlich die Ursache ist) vorsichtshalber die gesamte Box neu gestartet wird - einfach um eine "saubere Umgebung" zu haben.
Aber vielleicht irre ich mich hinsichtlich eine "Absturzes" ja auch und es ist nur die interne Fehlerbehandlung, die zur "Neu-Initialisierung" auf der WAN-Seite führt ... vielleicht liege ich sogar hinsichtlich der Konkurrenzsituation zwischen zwei Endgeräten um die portlosen Protokoll-Nummern daneben (in der konkreten Situation und bei den verwendeten VPN-Lösungen, denn generell gilt das dazu Geschriebene schon).
