Die Anzeige konnte schon immer mehr VPN-Verbindungen enthalten ... wieviele tatsächlich gleichzeitig
aktiviert sein können, habe ich nie probiert, da ich automatisch nur die jeweils benötigte Verbindung aktivieren lasse - wenn es Einschränkungen in der Anzahl gab, dann können die nur den Editor im GUI und die gleichzeitig aktiven Verbindungen betroffen haben, denn als "deaktiviert" konnten schon immer mehr verwaltet werden:
Anhang anzeigen 84918Anhang anzeigen 84919
Allerdings werden nach meinen Versuchen bei einem "cfgtakeover" (also "ausgewählte Einstellungen wiederherstellen") nur die ersten 7 Verbindungen angeboten und auch bei "Alle Einstellungen auswählen" nur diese ersten 7 Verbindungen übernommen - das paßt m.E. nicht zu der AVM-Angabe von 12 unterstützten VPN-Verbindungen oder es ist noch nicht in allen Teilen umgesetzt und beim cfgtakeover kam dann noch ein "off by one"-Fehler hinzu.
BTW und als "Bestandsaufnahme" alter Probleme:
Der zuverlässigste Weg, alle VPN-Verbindungen zu Netzen mit IPv4-Adressen der Form "192.168.xxx.0/24" funktionsunfähig zu machen, besteht nach wie vor darin, eine lokale Route für 192.168.0.0/16 anzulegen, weil alle "nicht VPN"-Ziele in solchen Segmenten über ein lokales Gateway zu erreichen sind. Da die Firmware es immer noch für eine gute Idee hält, sich bei einer LAN2LAN-VPN-Verbindung auf die "default"-Route zu verlassen, damit die Pakete am "dev dsl" vorbeikommen, braucht man in so einem Szenario (wie es bei mir nun mal existiert) zwangsweise eigene Aktionen, die dafür sorgen, daß Pakete für alle aktivierten VPN-Ziele auch wirklich über "dev dsl" gehen, weil es die originale Firmware einfach nicht gebacken kriegt.
Meine erste Meldung dieses Problems (als Labor-Feedback) stammt noch aus 2013, später (23.01.2014) kam dann eine "richtige" Support-Anfrage mit "CID3544938" dazu ... entweder es hat niemand im AVM-Support verstanden, wo das Problem überhaupt liegt (die damaligen Reaktionen legen das nahe) oder es ist einfach nicht wichtig genug. Sollte also jemand mal einen FRITZ!Box-Admin beim VPN in den Wahnsinn treiben wollen, einfach eine solche Route über das GUI anlegen und freundlich vor sich hin lächeln ...
Auch für eine "Umleitung" des eigentlich für einen VPN-Tunnel vorgesehenen Traffics auf der FRITZ!Box kann man mit einer solchen Route sorgen, da das Eintragen einer Route für das entfernte VPN-Netz über ein lokales Gateway nicht unterbunden wird (weder bei Editieren noch beim Setzen im Rahmen der Netzwerk-Initialisierung) - für diese Editier-Beschränkungen (die ja u.a. auch das Gastnetz betreffen) werden aktivierte VPN-Verbindungen (und ich meine "enabled", was intern dann "activated" wird und nicht den Verbindungsstatus (state)) überhaupt nicht berücksichtigt, genauso wenig wie bei der Änderung der lokalen IPv4-Einstellungen auf potentielle Konflikte mit vorhandenen VPN-Gegenstellen getestet wird.
Um der Frage zuvorzukommen, warum man denn überhaupt so eine Route einstellen will ... ich habe ein Netz aus verschiedenen FRITZ!Boxen und in meinem LAN mehr als eine WAN-Anbindung. Wenn Daten an eine entfernte FRITZ!Box zu übertragen sind, wird jeweils die benötigte VPN-Verbindung aktiviert und zwar auf dem Router, der gerade frei ist oder zumindest als erster wieder frei wird. Damit variieren also die Routen zu den jeweiligen FRITZ!Boxen, weil es gut sein kann, daß Gegenstelle A mal über die FRITZ!Box selbst und mal über das zentrale Gateway (und eine andere FRITZ!Box) zu erreichen ist. Da es einige Netze sind und die Anzahl der lokalen Routen in einer FRITZ!Box wohl auch begrenzt ist, bietet sich eine "unschärfere (gemeinsame) Route" für all diese Netzsegmente an und das funktioniert auch ganz ordentlich, wenn man denn parallel dazu jeweils eine speziellere Route für gerade aktivierte VPN-Verbindungen setzt. Dankenswerterweise hat AVM ja das Eintragen von Routen über andere Interfaces als "dev lan" blockiert, damit braucht man für solche spezielleren Routen eben Shell-Zugriff und die Umsetzung des beschriebenen Szenarios ausschließlich über HTTP-Requests zum Ändern von Einstellungen ist nicht mehr möglich.