Die Namen für P1-IDs sollten zwar inhaltlich keine Rolle spielen, aber wenn sie als FQDN ausgewiesen sind, könnte es sein, daß die Box daran trotzdem irgendetwas drehen will, denn die "local"-Domain ist m.W. diejenige (und als solche auch reserviert, so weit ich weiß), welche für mDNS/avahi/Bonjour verwendet wird.
Ich habe so etwas jedenfalls bisher noch nicht gehört, daß beim Import einer syntaktisch richtigen VPN-Konfiguration (ansonsten kommt auch ein Fehler) eine Einstellung nicht übernommen wurde, solange nicht spätere Änderungen diese Einstellung wieder aufgehoben haben.
In einem
anderen Thread habe ich versucht zu beschreiben, wie der Import einer VPN-Konfiguration meines Erachtens arbeiten müßte (internes "Modell" der Verbindungen, wo der Reihe nach die Eigenschaften gesetzt werden und das am Ende "auf einen Rutsch" wieder in die vpn.cfg serialisiert wird - alles nur geschlußfolgert, kein gesichertes Wissen wegen "closed source"), weil es eben auch ein "Mischen" von Einstellungen geben kann.
Wenn da also nach dem Import der Konfiguration keine weiteren Änderungen vorgenommen wurden, müßte man das ja in der resultierenden vpn.cfg auch richtig sehen können ... hier hat man nur das Problem, daß die Daten der IDs für P1 verschlüsselt gespeichert werden und man nicht wirklich sehen kann, was dort steht, solange man nicht selbst entsprechenden Aufwand beim "Entschlüsseln" treibt. Nach dem, was Du oben schreibst (die Daten im Klartext), machst Du das aber wohl ohnehin schon ... da würde ich neu importieren und unmittelbar im Anschluß nachsehen, was dort hinterlegt wurde in der Datei vpn.cfg (noch vor jedem Restart).
Bliebe noch die Vermutung, daß "umts.vpn.local" aus irgendeinem Grund in der AVM-Firmware "speziell" ist ... wenn ich es richtig verstehe, hat er ja auch aus beiden Konfigurationen genau diesen Wert entfernt, unabhängig davon, in welcher Einstellung der stand. Wenn da irgendeine "Syntax-Prüfung" für FQDNs stattfinden sollte (ob es die wirklich gibt, weiß ich auch nicht ... trotzdem empfehle ich immer, einen Parameter, der dem Namen nach FQDN sein soll, auch so aufzubauen, was Du zweifellos gemacht hast), könnte das der gemeinsame Punkt sein, an dem sich die Zeichenketten für verschiedene Einstellungen wieder so treffen, daß da ein bestimmter Wert in verschiedenen Einstellungen nicht so richtig konveniert.
Ist aber auch nur geraten ... nimm mal probehalber besser gleich andere Namen, deren TLD nicht "local" ist.
Der Fehler in der 7490 (0x202d) würde allerdings heißen, daß der DNS-Name der Gegenstelle nicht korrekt aufgelöst wurde (DNS-Timeout). Das wäre ein vollkommen anderer Fehler - auch sollte so ein 0x202d nicht dauerhaft auftreten, weil ein DNS-Server den Namen entweder kennt oder eben nicht, aber es sollte eine Antwort geben und kein Timeout beim Warten auf eine solche.
Aber das Protokoll der 6340 (die 109.irgendwas ist hoffentlich tatsächlich eine explizit nur Deiner 6340 zugewiesene öffentliche IPv4-Adresse, die auch eingehende Verbindungen zuläßt, sonst klappt das ohnehin nicht mit dem VPN, eine Seite braucht schon eine öffentliche IP - eine 6340 wird ja eher nicht an einem DSL-Anschluß hängen) deutet eigentlich auch darauf hin ("unknown remote peer"), daß da die Identifikation in P1 nicht so richtig klappt (aber die Pakete ankommen, was die Frage nach der Erreichbarkeit obselet erscheinen läßt) und das kann sie natürlich nicht, wenn die IDs nicht genau zueinander passen. Nur bei 1:1-Übereinstimmung wird die richtige Verbindung in der vpn.cfg und damit auch der passende PSK gefunden. Das Protokoll der 7490 enthält dann wieder nur "normale" Timeouts (0x2027), die ja auch erklärlich sind, solange die 6340 nicht antwortet (und das macht sie nur, wenn sie den "remote peer" erkennt und akzeptiert, ein NACK gibt es beim UDP für IPSec nicht).
) noch in Form einer "native IPv6 address". Letzteres würde dann ohnehin die Erreichbarkeit von reinen IPv4-Angeboten im Rest des Internets arg einschränken.