[Gelöst] VPN - Einstellungs Maske LAN<->LAN bei FB7490 u. UMTS-FB`s

Mit "leerer" ID geht wohl an der FB7490 (mit aktueller Labor 113.06.36-31739) nichts mehr.
Das wäre eine gute Nachricht ... es erspart nämlich die (bereits einmal erwähnten) Komplikationen, wenn man mehrere VPN-Verbindungen konfiguriert. Die Kombination aus "localid" und "remoteid" muß eindeutig sein, das ist es spätestens bei zwei leeren "remoteid"-Einträgen nicht mehr, denn die "localid" wäre (mit dem GUI) dieselbe.

Ansonsten wirfst Du jetzt die "Reservierung" eines LAN-Ports für eine VPN-Verbindung (ipsecbridge) mit einer "normalen" LAN-LAN-Verbindung durcheinander - solange da kein Haken bei "VPN beschränken" gesetzt ist, spielen die Einstellungen dahinter keine Rolle.

Falls es noch nicht richtig klar sein sollte ... Du kannst auf beiden Seiten das GUI nicht für die Konfiguration verwenden, wenn Du meinen Vorschlag mit den FQDN-Einstellungen für die IDs ausprobieren willst.

Der Fehlercode 0x202C (der dann sicherlich in der 7390 auftritt, denn die 7490 soll ja gar keine DNS-Auflösung machen) in der 7390 würde ja wieder darauf hinweisen, daß der Eintrag bei "remotehostname" nicht stimmt ... es ist nur noch mysteriös. Wenn Du das nicht auch bei "remotehostname" in der 7390 von Hand eingetragen hast, muß man ja fast wieder auf die Verwendung des GUI bei der 7390 tippen und daß dieses GUI einen (nicht bestehenden) Zusammenhang zwischen der "remoteid" und dem "remotehostname" unterstellt, habe ich deutlich geschrieben.

EDIT: Nach dem, was ich hier bisher gelesen habe, glaube ich einfach nicht daran, daß es sich wirklich um ein Problem mit irgendeiner Labor-Version handelt (außer vielleicht der neuen "Sperre" für leere "remoteid"-Angaben, wenn es die tatsächlich geben sollte) und ich da irgendwelche Feststellungen bei einem eigenen Test treffen könnte. Bisher liest sich das - nimm's mir nicht übel - alles nach Konfigurationsfehlern, die Du selbst verursachst. Dein Szenario ist nun mal mit dem eingebauten GUI (bekanntermaßen) nicht zu lösen - das mit einem Editor zu erledigen, ist aber auch keine "rocket science".
 
Zuletzt bearbeitet:
Danke @PeterPawn

Teil-Erfolg?

Zumindest waren die FBs kurzzeitig miteinander verbunden?

Entgegen älteren Anweisungen, wo fqdn local/remote jeweils leer vor jeweiligem import stehen sollten? habe ich die jeweilige FB-IP eingetragen. Ich kann zwar aus dem jeweiligen Netz nochnicht auf die entfernte FB zugreifen, da muss ich wohl noch mit den permissions Spielen/Nachlesen oder etwas mit Portweiterleitung Testen.

Der erste Versuch den entfernten Adressbereich (0-250) anzupingen scheiterte.

Die FB7490 meldet kurz nach "verbunden" x2027= timeout ... die FB7390 verbunden?

Zumindest nähere ich mich blauäugig einer Lösung ;)

LG
 
Entgegen älteren Anweisungen, wo fqdn local/remote jeweils leer vor jeweiligem import stehen sollten?
Das habe ich garantiert niemals so geschrieben ... das kann auch nicht funktionieren.

Wie gesagt, anhand dieser Angaben wählen die beiden Boxen den passenden VPN-Eintrag aus (der "name" spielt gar keine Rolle) und wenn die nicht zueinander passen, finden sie den richtigen Schlüssel nicht, usw. ... wie Du auf diese Idee kommst, das wäre eine "ältere Anweisung" gewesen, weiß ich nicht.

Ganz im Gegenteil, ich habe schon vorher irgendwo gefragt, ob man das mit den FQDN nicht lieber gleich richtig machen sollte, als ich noch annahm, einer von beiden könnte auch leer bleiben.

Vielleicht liest Du in diesem Licht ja noch einmal, was ich bisher geschrieben habe ... irgendwelche "Spiele" mit anderen Werten sind gar nicht notwendig.

Das wäre alles mit einer Veröffentlichung der tatsächlich verwendeten Konfigurationsdateien (mit maskierten DNS-Namen für die 7490 - natürlich in der Konfiguration der 7390) lange gegessen ... dann hätte man nämlich solche Fehler wie leere FQDNs bei "localid" und "remoteid" auf Anhieb gesehen.

EDIT: Warum Du nun die IP-Adressen beim fqdn-Eintrag besser findest als meinen Vorschlag mit "de.vpn.local" und "esp.vpn.local", verstehe ich aber auch nicht ... ich habe ja extra geschrieben, daß es (theoretisch in gewissen Grenzen) egal ist, was da steht ... es muß nur auf der anderen Seite genau gespiegelt sein.
 
Zuletzt bearbeitet:
Mea Culpa Mea maxima Culpa

Ich hatte in http://www.ip-phone-forum.de/showthread.php?t=282261&p=2127042&viewfull=1#post2127042 meine cfgs gepostet.
Dein Hinweis in http://www.ip-phone-forum.de/showthread.php?t=282261&p=2127052&viewfull=1#post2127052 habe ich fehlinterpretiert als "blonder Hans".

Mein grundsätzliches Problem war/ist, dass ich nicht weiss, wenn ich aus einer export-datei eine kryptische Zeichen-Kolonne bei fqdn hier poste, Mitleser dies dechiffrieren können durch einfachen Import in ihre eigene FB! Für Dich als Crack mag das banal/evident sein. Ein "Savant" bin ich nicht, sondern nur eher einfach gestrickter Anwender mit leider beschränktem Horizont ;)

Ich werde das aber statt mit der IP in der auch mit den von Dir genannten Dummies testen im Crosscheck. Wenn ich es richtig betrachte -werde ich mal testen- besteht u.U. auch die Möglichkeit ... zumindest mit dem Grundgerüst der jeweiligen GUI ... und den Exportdateien das hinzubekommen.

Ein Zusatz wie in hat das Problem gelöst wobei dies wohl in beiden cfgs kreuzweise eingetragen sein sollte.

Irgendwie stoppt die FB7490 nach geraumer Zeit die Verbindung obschon die FB7390 noch "verbunden" anzeigt?

Da habe ich schon eine Vorstellung weshalb und wie zu beheben. Bekanntermassen mögen Mobilfunkanbieter keine Dauerverbindungen und wechseln gerne öfters die IP.

LG und nochmals lieben Dank @PeterPawn für Deine Geduld + Mühe mit mir DAU ;)
 
Mein grundsätzliches Problem war/ist, dass ich nicht weiss, wenn ich aus einer export-datei eine kryptische Zeichen-Kolonne bei fqdn hier poste, Mitleser dies dechiffrieren können durch einfachen Import in ihre eigene FB! Für Dich als Crack mag das banal/evident sein. Ein "Savant" bin ich nicht, sondern nur eher einfach gestrickter Anwender mit leider beschränktem Horizont
Meinst Du ernsthaft, ich würde Dich dazu auffordern? Aber das ist auch gar nicht der Punkt ... ich habe bereits in #13 versucht klarzustellen, daß in einer hier veröffentlichten Konfiguration eigentlich gar keine verschlüsselten Daten mehr stehen dürf(t)en. Die kann ich dann nämlich auch nicht lesen ... somit auch nicht sagen, ob da richtige Werte stehen oder nicht.

Wenn Du nicht irgendeine Randbedingung "unterschlagen" hast, brauchst Du in jeder "acceslist" genau einen einzigen Eintrag für das Netz auf der Gegenseite im Format "permit ip any remote_lan_segment 255.255.255.0" und nichts weiter. Bei docmarten war das absolut etwas anderes, weil da noch die Forderung der Verbindung vom iPhone über die heimische FRITZ!Box auf die Insel dazu kam ... das kann man bei Dir sicherlich auch machen, aber erst einmal sollte das Grundgerüst funktionieren, bevor man mit "Schnörkeln" anfängt.

Es kann doch nicht so schwer sein, aus zwei Textdateien für den Import als VPN-Konfiguration die "geheimen" Angaben (das sind nur noch die DNS-Namen bei "remotehostname" und damit eigentlich nur eine einzelne Datei, die zu ändern ist ... der Rest ist schon aus den früheren Dateien bekannt - habe ich jetzt auch mehrfach versucht zu erläutern) zu maskieren und diese Dateien dann hier einzustellen.

Das hast Du zwar bereits einmal getan, danach habe ich Dir mehrfach "Anweisungen" (wenn Dir das denn lieber ist) gegeben, was Du ändern sollst. Nun weiß ich aber nicht, ob Du das jeweils verstanden und richtig umgesetzt hast (bzw. inzwischen weiß ich, daß das nicht der Fall war) ... soll ich mir die resultierenden Files jetzt im Geiste vorstellen?

Es kann doch kein Problem sein, nach einer mit dem Editor durchgeführten Änderung zwei Text-Dateien als CODE-Block in einen Beitrag einzufügen. Das Einzige, was Du bei funktionierender Konfiguration dann noch einmal in beiden Geräten ändern mußt, ist der "geheime Schlüssel". Aber selbst den kann/muß man eben erst einmal unverändert veröffentlichen (außer man verbürgt sich tatsächlich dafür, daß er auf beiden Seiten identisch ist) ... man kann ihn ja jederzeit durch einen neuen ersetzen (aber eben auf beiden Seiten), wenn es erst einmal funktioniert und das ist nicht vom konkreten Wert des PSK abhängig.
 
Ein Wenig Nachsicht?

...

Es kann doch nicht so schwer sein, aus zwei Textdateien für den Import als VPN-Konfiguration die "geheimen" Angaben (das sind nur noch die DNS-Namen bei "remotehostname" und damit eigentlich nur eine einzelne Datei, die zu ändern ist ... der Rest ist schon aus den früheren Dateien bekannt - habe ich jetzt auch mehrfach versucht zu erläutern) zu maskieren und diese Dateien dann hier einzustellen....

Damit habe ich mich als DAU halt schwer getan ;) Hättest Du "Maskieren" mit einer Codezeile als Bsp. erwähnt/erläutert? ... hinterher ist jeder DAU schlauer ;)

Das hast Du zwar bereits einmal getan, danach habe ich Dir mehrfach "Anweisungen" (wenn Dir das denn lieber ist) gegeben, was Du ändern sollst. Nun weiß ich aber nicht, ob Du das jeweils verstanden und richtig umgesetzt hast (bzw. inzwischen weiß ich, daß das nicht der Fall war) ...

Uneingeschränkt mehrfach betont, dass eben wohl NICHT verstanden bzw. korrekt umgesetzt wurde meinerseits!

Es kann doch kein Problem sein, nach einer mit dem Editor durchgeführten Änderung zwei Text-Dateien als CODE-Block in einen Beitrag einzufügen.

Die sicherlich leichteste Übung ;)

Das Einzige, was Du bei funktionierender Konfiguration dann noch einmal in beiden Geräten ändern mußt, ist der "geheime Schlüssel". Aber selbst den kann/muß man eben erst einmal unverändert veröffentlichen (außer man verbürgt sich tatsächlich dafür, daß er auf beiden Seiten identisch ist) ... man kann ihn ja jederzeit durch einen neuen ersetzen (aber eben auf beiden Seiten), wenn es erst einmal funktioniert und das ist nicht vom konkreten Wert des PSK abhängig.

Im Nachgang für mich verständlich, nur mögest Du mir Zubilligen, dass es "zig" Threads gibt, wo Users (aus Unwissenheit der tieferen Zusammenhänge) Configs Posten, wo als 1te Antwort kommt ... den "Bereich xy z.B. TR069-ID" besser unkenntlich machen ;)

Die wissende Mitleserschaft lacht sich dabei schlapp, der Hilfesuchende ist der Depp!

Vondaher betrachte BITTE mein Unvermögen aus dieser Warte.
Ich habe mich nachweisslich für Deine Hilfe bedankt ... keinen Hehl aus meiner Unbedarftheit/meinem Unvermögen gemacht ... für einen Frustbeitrag mich entschuldigt.

LG und mögen wir es dabei Bewenden Lassen?

OT: Wir hatten ~25.1.2015 via PN+Nachfolgend E-Mail-Kontakt. IdS würde ich das nicht als Penetranz -aus meiner Sicht- werten, wobei ich nur mutmassen kann, dass dies seither logarithmisch angestiegen ist -aus Deiner Sicht- ? Von daher habe ich vollstes Verständnis für Signaturen ... Support gehört ins Forum ... nur in betimmten Fällen -dem Übermitteln von cfgs- wäre es sinnvoller, dies per PN/Mail auf "Zuruf des Helfenden" zu erledigen? Das Resultat/Ergebnis kann ja wieder in einen Thread einfliessen?
 
Ich habe gar kein Problem damit, auch Nachsicht zu üben ... Du darfst auch nicht immer jedes Wort auf die Goldwaage legen. Das ständige Betonen, daß man mit einem Nachsicht üben möge, ist auch nicht gerade hilfreich: https://www.tty1.net/smart-questions_de.html#grovelling

Das Abschalten der PMs erfolgte definitiv nicht Deinetwegen ... das habe ich nie auch nur im Ansatz so geschrieben. Es ist tatsächlich die Summe der Anfragen insb. zu den Kabel-Modellen, die irgendwann auch die Lust auf ausführliche Antworten versiegen läßt - vor allem dann, wenn man jemandem dreimal dasselbe schreiben muß (nur jedesmal mit einem anderen Erklärungsansatz/-versuch), weil der es einfach nicht raffen will/kann und sich trotzdem seine Defizite in den Basiskenntnissen nicht eingestehen will ... aber das ist ein anderes Thema.

Was ich nun immer noch nicht abschließend verstanden habe ... funktioniert es denn nun? Wenn nicht, warum gibst Du dann jetzt auf? Gibst Du überhaupt auf? Es kann doch nicht mehr weit sein bis zum Ziel ... zwischendurch dachte ich, Du hättest wieder Mut gefaßt und würdest tatsächlich das Problem unter allen Umständen lösen wollen. Jetzt macht es wieder den Eindruck "sundowning" in Bezug auf Deine Motivation am Ende des Tages (den Demenz-Aspekt meine ich damit ausdrücklich nicht).

Und wer sich bei der Bitte um Hilfe (bei einer substantiierten Bitte, sonst muß man auch mal "konstruktiven Spott" aushalten können - wer dann lieber ignoriert werden will, wenn er Unsinn schreibt, kann das natürlich auch haben, bringt ihm aber noch weniger als eine Reaktion mit der Information, daß vermutlich die Frage von niemandem verstanden werden kann) hier als Depp fühlt, ist zu einem guten Teil selbst schuld ... bei einer ordentlichen Fragestellung und ordentlichen Antworten auf Nachfragen wurde hier m.W. immer noch jedem auch nach besten Kräften geholfen. Warum Du Dich da als Depp fühlst, weiß ich wahrlich nicht ... aber manchmal könnte man eben auch den Hinweis, daß man das doch alles schon einmal ge- und beschrieben hat, nur durch die Wiederholung derselben Erklärung ersetzen - das ist für den Antwortenden auch belastend, wenn er den Eindruck gewinnt, daß die Antworten eigentlich nicht genau gelesen werden.

Also ... wenn Du aufhören willst, ist das nach wie vor Deine Sache - niemand kann Dich zwingen bis zum Funktionieren durchzuhalten. Wenn Du jetzt die Erläuterungen verstanden hast und bereit sein solltest, den Inhalt der aktuellen Konfigurationsdateien mit uns zu teilen, können wir auch problemlos fortsetzen.

Um die Sicherheit Deiner Daten brauchst Du Dir dabei keine Sorgen machen, solange Du den "remotehostname" in der 7390-Konfiguration (also den Hostnamen der 7490) durch einen (erkennbar) anderen Namen ersetzt und - wenn es erst einmal funktioniert - auch den "key" noch einmal gegen einen neuen austauschst. Da die UMTS-Box ja von außen gar nicht zu erreichen ist (das gilt für alle, nicht nur für Dich), kann man da auch keinen Hostnamen "verraten" bzw. das bliebe ohne Konsequenzen. Der Rest in diesen Konfigurationdateien ist ohnehin schon bekannt ... die entscheidende Frage ist, ob Du das alles richtig zusammengesetzt hast zu einer funktionierenden Konfiguration. Die Antwort darauf kann man nur geben (und dann eventuelle Fehler suchen, wenn es wider Erwarten immer noch nicht funktioniert), wenn man diese Dateien kennt.

Und dazu kann man solche Dateien (wenn man die angeführten Maßnahmen im Anschluß auch ausführt) problemlos auch im Forum veröffentlichen. Vorsichtige Zeitgenossen ändern dann noch die tatsächlich verwendeten internen Netzwerk-Segmente ab (also 192.168.177.0/24 wird durch irgendwas wie 192.168.1.0/24 ersetzt), damit da keine gezielten Angriffe möglich sind ... das war bei Dir aber von Beginn an zu spät, denn die 177 und 183 waren schon in der ersten Konfiguration zu sehen. Die Meinungen, wie "gefährlich" solche Kenntnisse eigentlich sind, gehen ohnehin auseinander ... wenn ich die bei Dir verwendeten Adressen allerdings kenne und dazu noch Deine E-Mail-Adresse, kann ich Dir eben eher Malware per Mail unterschieben, die gezielt das lokale Netz scannt, als bei fehlender Kenntnis dieser Angaben. Es ist also nicht vollkommen gleichgültig, ob man diese Angaben kennt, aber es ist noch lange kein Beinbruch (und eine FRITZ!Box finde ich auch über die Notfall-IP).
 
Ok

Ich habe gar kein Problem damit, auch Nachsicht zu üben ... Du darfst auch nicht immer jedes Wort auf die Goldwaage legen. Das ständige Betonen, daß man mit einem Nachsicht üben möge, ist auch nicht gerade hilfreich: https://www.tty1.net/smart-questions_de.html#grovelling

Interessanter Link obschon man Demut vor dem "Crack" nicht unbedingt stets in den Malusbereich verschieben muss? ( halt Ansichtssache, aus welcher Position betrachtet!)

Das Abschalten der PMs erfolgte definitiv nicht Deinetwegen ... das habe ich nie auch nur im Ansatz so geschrieben. Es ist tatsächlich die Summe der Anfragen insb. zu den Kabel-Modellen, die irgendwann auch die Lust auf ausführliche Antworten versiegen läßt - vor allem dann, wenn man jemandem dreimal dasselbe schreiben muß (nur jedesmal mit einem anderen Erklärungsansatz/-versuch), weil der es einfach nicht raffen will/kann und sich trotzdem seine Defizite in den Basiskenntnissen nicht eingestehen will ... aber das ist ein anderes Thema.

Das hast Du sicherlich -allerortens in Deinen Beiträgen nicht flächendeckend erfasst meinerseits- mehrfach avisiert.

OT: So böze Geschichten wie O*S*C*A*M-Klient-Gedönse zusammen mit einem AVM-DVB-C ... da sind Begehrlichkeiten oportun und ist es verständlich, dass Deine ggfs. tiefergreifenden Erkenntnisse zu den Kabel-Boxen eher secret.

Was ich nun immer noch nicht abschließend verstanden habe... funktioniert es denn nun?


Ja tut es ;) Das Langzeitverhalten mal aussenvor ... das sporadische "Sich-Aufhängen" von älteren FBs wie 7270/7240 ist ja hier zigfach dokumentiert? -Naturgemäss soll ja ein voicefähiger UMTS-Stick ambivalent -GSM+VPN-InetVerbindung-arbeiten ;)


... sonst muß man auch mal "konstruktiven Spott" aushalten können ....

Da habe ich Null Problem mit

... bei einer ordentlichen Fragestellung und ordentlichen Antworten auf Nachfragen wurde hier m.W. immer noch jedem auch nach besten Kräften geholfen. Warum Du Dich da als Depp fühlst, weiß ich wahrlich nicht ... aber manchmal könnte man eben auch den Hinweis, daß man das doch alles schon einmal ge- und beschrieben hat, nur durch die Wiederholung derselben Erklärung ersetzen - das ist für den Antwortenden auch belastend, wenn er den Eindruck gewinnt, daß die Antworten eigentlich nicht genau gelesen werden.

Da gebe ich Dir vollkommen Recht! Des Lesens mächtig bin ich halbwegs. Nur um den "OttoWaalkes-Sketch Kleinhirn an Grosshirn" zu zitieren ... die Milz quatscht halt immer dazwischen :D

... wenn ich die bei Dir verwendeten Adressen allerdings kenne und dazu noch Deine E-Mail-Adresse, kann ich Dir eben eher Malware per Mail unterschieben, die gezielt das lokale Netz scannt, als bei fehlender Kenntnis dieser Angaben. Es ist also nicht vollkommen gleichgültig, ob man diese Angaben kennt, aber es ist noch lange kein Beinbruch (und eine FRITZ!Box finde ich auch über die Notfall-IP).

Das traue ich Dir ob der Möglichkeit zu ... nur ausser 2 Netzwerksegmenten 192.168.173.0/24 192.168.183.0/24 und den tatsächlichen IPs der Fritten? ... Wenn ich spasseshalber in meinem aktuellen IP-Net-Bereich, mit dem ich via VDSL verbunden bin, durchpinge, erkenne ich etliche FBs. Sind die alle wirklich gefährdet? Das würde ja jeglichen dyndns ad Absurdum führen?

Ein Empfang einer E-Mail mit Schadsoft hinter einer der FBs aussenvor.

LG
 
Das mit dem Malware-Unterschieben war schon als Empfang auf einem Client hinter der betreffenden FRITZ!Box gemeint. Da ist es eben einfacher/schneller, wenn man die verwendeten Netze schon kennt und nicht die möglichen 255 Netze mit privater Class-C-Adresse durchflöhen muß ... aber wie gesagt, eine FRITZ!Box hat ihren eigenen "Anker" im Netzwerk und ist ohnehin im LAN leicht zu finden.

Wenn es jetzt funktioniert, ist das ja auch schön ... aber Dein Bekannter ist ja wohl schon fast da - mußt Du die Box eben direkt nach ESP schicken.

Wenn Du dann noch den Thread auf "gelöst" oder "erledigt" setzen würdest ... Danke meinerseits (auch für das "doch noch zu einem Ende bringen", ist ja auch für den Helfer nicht so frustrierend ;)).
 
So ein Ärger?

Ich habe nachweislich das 1h-VPN-Halten-Problem übersehen/verdrängt!

Code:
08.11.15
	21:34:03	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.177.20.
08.11.15
	21:33:51	VPN-Verbindung zu <Platzhalter UMTS-Box>wurde getrennt. Ursache: 9 Dead Peer Detection
08.11.15
	20:20:14	Anmeldung an der FRITZ!Box Benutzeroberfläche von IP-Adresse 192.168.177.20.
08.11.15
	20:20:06	Die FRITZ!Box-Einstellungen wurden über die Benutzeroberfläche geändert.
08.11.15
	20:19:49	VPN-Verbindung zu <Platzhalter UMTS-Box> wurde erfolgreich hergestellt.

Womit könnte ich das Trafficschonend bewerkstelligen, dass das stabil gehalten wird?

LG
 
Dieses Problem existiert eigentlich zwischen zwei FRITZ!Boxen eher nicht ... zwar wird auch da ein Rekeying nach 54 Minuten ausgelöst, das führt aber nicht zu irgendwelchen Problemen - da gibt es auch nichts besonderes einzustellen, notfalls "always_renew" auf beiden Seiten noch auf "yes", wenn Du da etwas ggü. den bisherigen Files geändert haben solltest.

Ansonsten erneut (ich kann es nicht ändern): Konfigurationsdateien + Protokoll (in diesem Falle sogar noch wichtiger - meint auch die ike.log) des Fehlers. Selbst wenn die 7490 irgendwann ihrerseits aufgrund fehlender DPD-Antworten die Verbindung abbauen sollte, muß eine funktionierende 7390 diese Verbindung umgehend wieder herstellen. Wenn das nicht erfolgte, deutet das eher darauf hin, daß auf der 7390 die Internetverbindung nicht stabil ist bzw. sich aufgehangen hat - vielleicht bleibt ja dieser Stick auch ab und an mal hängen, auch solche Berichte gibt es ja.

Ein kurzes Ping (1 Paket) alle 60 Sekunden (oder was auch immer Dir ratsam erscheint) zu einer beliebigen Internetadresse und wenn dann mehrere Fehler nacheinander auftreten, hängt wohl der Stick und Du kannst gleich der DECT-Steckdose den Restart-Befehl übermitteln. Allerdings muß man bei UMTS immer etwas großzügiger sein (geht dann halt auf Kosten des Volumens), denn mit etwas Pech verschwindet das erste Ping-Paket immer im Nirwana - wobei das eigentlich bei einer FRITZ!Box nicht passieren sollte.
 
Wie zumeist üblich, behälst Du Recht ;)

Dieses Problem existiert eigentlich zwischen zwei FRITZ!Boxen eher nicht ... zwar wird auch da ein Rekeying nach 54 Minuten ausgelöst, das führt aber nicht zu irgendwelchen Problemen - da gibt es auch nichts besonderes einzustellen, notfalls "always_renew" auf beiden Seiten noch auf "yes", wenn Du da etwas ggü. den bisherigen Files geändert haben solltest..

Weil? mir 2-3 Fehler unterlaufen sind :mad:

Fehler1: Beim Aus+Ein-Stecken des Netzteiles der FB7390 (POR) ist das Netzteil-Anschlusskabel "Schlangenartig" in die dunkelste Ecke hinter dem Schreibtisch "Abgesunken/Verschwunden" ... fluchend -ohne Brille- hatte ich das falsche einer FB7240 1,4 statt 2,0A angeschlossen ... u.U. nicht ausschlaggebend ... aber UMTS-Sticks können ggfs. am USB-Anschluss schonmal grenzwertig Amperes benötigen ;)

OT-Zwischenfrage: Gibt es eigentlich einen erschwinglich-zu-erwerbenden-Adapter, mit dem man mit einem Standard-Multimeter zwecks Stromaufnahme-Beobachtung dieses in eine USB-Verbindung einschleifen kann? Egal welches USB-Gerät an einer FB angeschlossen, herrscht oftmals Uneinigkeit, was die/eine FB liefern kann bis zum "Abschalten" - Irgendeinen Überlast-Schutz wird Hard-/Softwaremässig wohl realisiert sein?

Ein entsprechendes Kabel dazu "Aufzudröseln" ... geschenkt :D

Fehler2: Bei einer in Notepad+ geöffneten vpn.cfg -hier der FB7490- hat sich diese -durch eine unbemerkte/versehntliche Touchpad-Berührung mit dem Handballen auf dem Netbook- in der Syntax "zerfleddert" ... nach dem Import war dies ertsmals nicht zu Erkennen!

Fehler3=Behoben?: Ich habe in beiden vpn.cfg`s die Zeile
Code:
always_renew = yes;
...
keepalive_ip = 192.168.xxx.xxx;
jeweils eingefügt.


Das Ganze scheint nun stabil -wenn 24h einer Aussage würdig- zu laufen?

Kleines Manko OT? In der UMTS-FB-7390 habe ich eine 1und1-MSN erfolgreich registriert *121# neben der proprietären *13# SIM-Nummer! Über die *121# kann ich zwar "rausrufen" empfange aber keine Anrufe?

Eine eingepflegte SIPGATE -MSN funktioniert auf Anhieb in beiden Richtungen (Raus-Call+Empfang)?

Beim ersten Vergleich innerhalb der Export-Datei ... sehr Umfangreich im Abschnitt voip.cfg... fällt auf, dass 1und1
stunserverport=3478 nutzt und sipgate 10000?

Ein Problem der eingesetzten SiM von 1&1 im Vodafone-Netz?

LG+Many TX nochmals an PeterPawn für Deine Geduld mit mir hier ...
 
Zuletzt bearbeitet:
Nach einigen Tagen des Probierens

habe ich nun folgende Erfahrung gemacht.

Die VDSL-7490 zeigt eigentlich -wenn ich als Client angeschlossenen bin- die VPN-Verbindung zur UMTS-7390 als "verbunden" an. Rufe ich die 7390 im Browser (FF) per IP auf ... nada ... im Ereignis-Log taucht simultan Ursache: 9 Dead Peer Detection bzw. IKE-Error 0x2027 =Timeout auf.

Verbinde ich mich als Client mit der UMTS-7390 wird die Verbindung zur VDSL-7490 auch als "verbunden" angezeigt, nur kann ich diese sofort per IP erreichen.

Ich habe auch mit dem Parameter allways_renew = yes probiert. Aber dies zeigt in der VDSL-7490 keine Wirkung.

Diese -mittlerweile mit Labor 31822- "vergisst" wohl mangels Anforderung/Beschäftigung seitens der UMTS-7390 die VPN-Verbindung, da ja auch keine sinnvolle dyndns als remote-id zu einer privaten IP der UMTS-7390 eintragbar? (einfältig ausgedrückt).

Was jedoch reproduizerbar sehr gut funktioniert? Wenn ich die VDSL-7490 mal kurz "neu verbinden" lasse mit/zwecks neuer IP, bekommt die die UMTS-7390 dies über den dyndns/IP-Wechsel der 7490 sofort (~2Min) mit und baut wohl die VPN-Verbindung selbstständig/von sich aus wieder auf und sie steht wieder. Wie lange genau, habe ich noch nicht herausgefunden.

Da ich vorwiegend als Client hinter der VDSL-7490 agiere (agieren muss wegen räumlicher Distanz zur UMTS-7390 im Ernstfall) und nur sporadisch -alle paar Tage- auf die UMTS-7390 VPN-Zugriff benötige, scheint dies stabil als gangbare Lösung so zu laufen.

Anmerkung: Momentan teste ich diese Konstellation ... FB7490-VDSL und FB7390-UMTS stehen ~1m auseinander ;) ... Als Client mit LAN-Kabel-Umstöpseln kein Akt. Als Ziel soll die UMTS-FB7390 mal zukünftig in ~3000KM Entfernung zuverlässig agieren :D

LG und will be continued ... wen es interessiert?

Nachtrag: Gerade die UMTS-FB7390 auf Labor 31823 via LAN-Verbindung gebracht -via UMTS-Verbindung wäre Traffic-Ressourcen-Verschwendung- ...

OT: Lässt sich eigentlich die "Zwangsexport-Erstellung" irgendwie überspringen? Hintergrund: Beim Updaten hoch und runter mehrerer FBs mit derselben FW ist der Download "zugepflastert" mit Export-Dateien! -auch wenn sie alle dasselbe PW haben. Nur die fix vorgegebne Namens-Gebung ist doof!
Bsp:
Code:
FRITZ.Box Fon WLAN 7390 84.06.36-31764LABOR_BETA_14.11.15_2202.export

Datum Uhrzeit FW-Stand erkennbar! Nur weiss ich in ein paar Tagen noch, zu welcher FB7390 diese gehört? Würde mir wünschen, man könnte dies vor dem Abspeichern Namenstechnisch Verändern/Ergänzen können? als Bsp.
Code:
FRITZ.Box Fon WLAN 7390[COLOR="#FF0000"]-Keller[/COLOR]- 84.06.36-31764LABOR_BETA_14.11.15_2202.export
 
Zuletzt bearbeitet:
Hallo Micha0815,
habe gerade Deine Host-to-Fritzbox VPN-Config (conntype_user) angesehen;
hier sind mir zwei Optimierungs-Punkte aufgefallen:

1.) accesslist beinhaltet nach meiner Ansicht Redundanzen,
"permit ip any ..." beinhaltet doch "permit ip 192.168.177.0 255.255.255.0 ..."
Code:
vpncfg {
        vpncfg_version = 1;
        connections {
SNIP
                conn_type = conntype_user;
                name = "Micha0815";
SNIP
                use_xauth = no;
...
                accesslist = 
                             "permit ip 192.168.177.0 255.255.255.0 192.168.177.201 255.255.255.255", 
                             "permit ip any 192.168.177.201 255.255.255.255";
        }



2.) xauth ist abgeschalten
hier verwende ich immer zusätzlich zu PSK noch die Authentifizierung per FB-User/Pwd
Code:
        use_xauth = yes;
                xauth {
                         valid = yes;
                         username = "fritzbox_username";
                         passwd = "fritzbox_user_password";
                }

LG Riverhopper
 
@Micha0815:
Ehe das jetzt in "den falschen Hals" kommt ... Riverhopper meint hier (hoffentlich) nur die VPN-Verbindung aus #1, die den Namen "Micha0815" hat - das hat mit der LAN-LAN-Kopplung der beiden Boxen (um die es in der Folge nur noch geht in diesem Thread) rein gar nichts zu tun. Bitte bringe das beim Basteln mit diesen Konfigurationen nicht durcheinander.

Auch halte ich persönlich die zusätzliche Verwendung von "xauth" eher für unnötig ... solange der (in #1 richtigerweise nicht erkennbare) Wert in "key" (das ist ja der PSK) ausreichend stark ist (ich plädiere immer für 32 Zeichen Zufall, dafür funktioniert z.B. folgendes selbst auf der FRITZ!Box recht gut:
Code:
echo "$(tr -dc A-Za-z0-9_ < /dev/urandom | dd if=/proc/self/fd/0 of=/proc/self/fd/1 bs=1 count=[B]32[/B] 2>/dev/null)"
, die 32 ist die Anzahl der benötigten Zeichen), ist die zusätzliche Identifikation des Benutzers (wenn nicht mehrere denselben PSK verwenden) eigentlich nicht notwendig bzw. ich sehe den zusätzlichen Sicherheitsgewinn nur dann, wenn man auf dem verbindenden Client diese Credentials nicht permanent speichert (zumindest das Kennwort nicht). Konfiguriert man sich hingegen sein Smartphone (oder was auch immer) so, daß da eine automatische Anmeldung erfolgt, bringt dieses zweite "secret" eigentlich nichts.

@Riverhopper:
Das ist in #1 auch keine mit dem GUI konfigurierte Verbindung, die einem Benutzer der Box zugeordnet ist (boxuser_id = 0) ... das mit dem "xauth" ist also so eine Sache. Wenn damit tatsächlich ein FRITZ!Box-Konto verbunden werden soll, ist dieses "xauth" (in Grenzen) sinnvoll ... ansonsten eher nicht und solange das eine Verbindung mit "aggressive mode" in P1 ist, führt ohnehin kein Weg an einen "strong secret" für den PSK vorbei.
 
Danke Euch Beiden

@Riverhopper

Den User-Account hatte ich vor geraumer Zeit mit dem AVM-Tool erstellt. Der macht keine Probleme, sofern als Client hinter der VDSL-7490 mit IP 192.168.177.1 und diese verbunden.

@PeterPawn

Prinzipiell bin ich bemüht mir hinreichend lange PWs auszudenken und zu Verwenden. Je nach Anwendung etwas kürzer oder bei wichtigen Dingen z.B. PayPal auch ziemlich lang!

Bsp: Für eine Fritte verwende ich die Anfangsbuchstaben eines merkbaren Satzes Case-Sensitiv und einigen ersetzten Sonderzeichen?

"PeterPawnistam1.6.1967geborenundwohntin12679Berlin"

als zu verwendendes PW käme: PPia1.6.1967*+wi12679B
als zu verschlüsselndes PW <32Zeichen zum Einsatz?

In einer Export-Datei ist das ellenlang? Wäre das wirklich zu "einfach"?

Wenn ja müsste ich mir eine andere PW-Vergabe ausdenken!

LG
 
@Micha0815:
Kennwörter sind immer so eine Sache ... für echte Logins (wo man das also eingeben muß) ist Deine Methode ja geeignet. Für solche Sachen wie einen PSK (gilt selbst für WLANs, wenn man definitiv vorher schon weiß, daß man das entweder per C&P übertragen oder per QR-Code setzen kann) ist halt ein zufälliges Kennwort wesentlich stärker.

Bei meiner Methode ergeben sich für jedes verwendete Zeichen 63 denkbare Möglichkeiten (26 in A-Z, 26 in a-z, 10 in 0-9 und der Unterstrich), das macht dann bei 32 Zeichen
Code:
63 hoch 32 = 3,7922554357346399397004274365604e+57
- das ist eine Zahl mit 57 Stellen - denkbare Kombinationen für ein Kennwort. Da bei echtem Zufall auch alle Zeichen mit derselben Häufigkeit auftreten können, muß man also im schlechtesten Fall diese Anzahl von Kombinationen austesten.

Bei Deiner Methode ergibt sich jetzt (ich rechne mal mit 10 verschiedenen Sonderzeichen + dt. Umlauten inkl. ß, die Du verwenden würdest, was bei Kennwörtern aber schon mal zu Problemen führen kann, deshalb lasse ich die für gewöhnlich aus) für jedes Zeichen eines aus 26 Großbuchstaben, 26 Kleinbuchstaben, 7 Umlauten, 10 Ziffer und 10 Sonderzeichen (als Hausnummer) = 79 mögliche Zeichen im Vorrat. Nehme ich jetzt die von Dir o.a. 22 Zeichen als Länge, bringt das
Code:
79 hoch 22 = 5,5949474058748087917216280838536e+41
verschiedene Kombinationen. Immer noch reichlich ... und auch sicher, aber eben "unsicherer" als die andere Variante (und zwar um 16 Zehnerpotenzen).

Das ist aber auch eine Milchmädchenrechnung, weil eben mit statistischen Methoden das ganze noch weiter zu reduzieren ist. Wenn ich weiß, daß Du solche Sätze verwendest, darf ich mit einiger Wahrscheinlichkeit davon ausgehen, daß Du am Beginn einen großen Buchstaben stehen hast, weil eben Sätze im Deutschen mit einem großen Buchstaben beginnen. Das reduziert (so wenig das auf den ersten Blick auch ausmachen mag) die möglichen Kombinationen schon auf
Code:
(79 hoch 21) * 29 = 2,0538414527894867716446482839463e+41
, was weit weniger als 50% des ersten Wertes sind - damit ist der Aufwand für das "Knacken" durch bloßes Probieren (brute force) schon um mehr als die Hälfte reduziert. Aber es ist immer noch eine große Zahl.

Meine Chancen bei so einem Brute-Force-Angriff kann ich aber noch weiter verbessern, wenn ich berücksichtige, daß es nun mal auch im Deutschen eine Häufigkeitsverteilung von verwendeten Buchstaben gibt und die Kombinationen mit den häufigeren Buchstaben zuerst probiere. Es gibt eben nur sehr wenige Worte, die mit einem "x" beginnen und auch viele weitere Buchstaben tauchen einfach am Beginn eines Wortes wesentlich seltener auf als andere (q, z, c).

Dummerweise helfen manche "password policies" teilweise sogar bei solchen Reduktionen ... wenn ich zum Beispiel weiß, daß ein Kennwort drei Stellen hat (nur als Hausnummer, damit es übersichtlich bleibt), aber einen Großbuchstaben, einen Kleinbuchstaben und eine Ziffer enthalten muß, fallen automatisch jede Menge Kombinationen weg ("Ab1" wäre möglich, "AB1" schon nicht mehr) - gleiches gilt für andere (unsinnige) Festlegungen (keine zwei identischen Zeichen nacheinander, keine Zahlenfolgen (1234), usw.).

Also ... so eine Satzbildung ist sicherlich nicht schlecht (und für zu merkende Kennwörter sicherlich ideal, wenn man diese denn auch mal wechselt, was m.E. nach die wenigsten machen, wenn sie sich so einen Satz erst einmal eingeprägt haben) - gegenüber einem wirklich zufälligen Kennwort ist sie jedoch um Größenordnungen schlechter. Ob und welche Auswirkungen das hat, steht auf einem anderen Blatt ... aber ein Kennwort aus fünf Großbuchstaben bietet eben nur 26 ** 5 = 11881376 verschiedene Kombinationen, die sind mit einem automatisierten Verfahren ruckzuck durchgerechnet.

Daher empfehle ich immer die Verwendung eines Kennwort-Safes, der dann mit einem solchen Satz, wie Du ihn beschrieben hast, gesichert wird und dann aber wirklich zufällige Werte da verwendet, wo man diese nicht von Hand eingeben muß. Erstens verringert das die Wahrscheinlichkeit, daß man eben doch dasselbe Kennwort an mehreren Stellen verwendet und zweitens macht es das periodische Wechseln von Kennwörtern einfacher, weil man sich nur einen neuen Hauptschlüssel merken muß und nicht jedes einzelne Kennwort bzw. den Satz zu seiner Ableitung.
 
hallo PeterPawn und andere Interessierte,
ich hab die "PSK-Length" bei VPN-Cfg-Erstellung per FB VPN Web-IF (FW 06.0x) geprüft:
http://fritz.box/system/vpn_print.lua
Code:
iPhone, iPad oder iPod touch
    Wählen Sie auf dem Homescreen Ihres iPhones, iPads oder iPod touch das Symbol "Einstellungen".
    Öffnen Sie das Menü "Allgemein / VPN / VPN hinzufügen".
    Wählen Sie als VPN-Betriebsmodus "IPSec".
    Tragen Sie in die Felder folgende Angaben ein:
        Beschreibung:          CT_User_XXXX
        Server:                xxxxx.dyndns.org
        Account:               FB_User_XXXX
        Kennwort:              FB_User_KW
        Zertifikat verwenden ist deaktiviert
        Gruppenname:           FB_User_XXXX
        Shared Secret:         1234567890123456

Android-Geraet (ab Version 4.0.4 - Ice Cream Sandwich)

Waehlen Sie auf dem Homescreen Ihres Android-Geraetes "Einstellungen / Weitere Einstellungen / VPN / VPN-Netzwerk hinzufuegen".
Tragen Sie in die Felder folgende Angaben ein:
        Name:                  CT_User_XXXX
        Typ:                   IPSec Xauth PSK
        Server-Adresse:        xxxxx.dyndns.org
        IPSec Identifier:      FB_User_XXXX
        IPSec Pre-Shared Key:  1234567890123456

Ergebis:
  • der PSK wird automatisch vorgegeben und hat 16 Chars Länge und erfüllt somit nicht die "PeterPawn Recommendation" von 32 ;-) d.h. man sollte manuell "nachtunen".
  • es wird per Default XAUTH mit FB-User/Pwd verwendet.

LG Riverhopper
 
der PSK wird automatisch vorgegeben und hat 16 Chars Länge und erfüllt somit nicht die "PeterPawn Recommendation" von 32
Wenn sich das AVM mal zu Herzen nehmen würde ... immerhin ist das aber jetzt schon recht lang für das "Eintippen" in das Smartphone oder Tablet - ich hatte extra andeuten wollen, daß ich die 32 Zeichen (auch das ist ja eher willkürlich, das können auch 31 oder 33 sein) immer dann sehe, wenn es automatisch übernommen werden kann ... daher auch der Hinweis auf C&P oder QR-Code. Aber hier sehe ich schon einen Kompromiß zwischen Komfort und Sicherheit ... so etwas wirkt sicherlich manchmal sogar albern, aber beim "aggressive mode" ist eben die Stärke des PSK (solange es keine Zertifikate gibt) der entscheidende Punkt.

In diesem Kontext würde ich mir auch wünschen, daß AVM eine entsprechende Sicherung in den GUI-Editor für LAN-LAN-Verbindungen einbaut. Wenn ich das richtig sehe (gerade an einer 7390 getestet), ist das selbst bei der neuesten Labor-Firmware noch nicht implementiert, daß bei der Eingabe eines VPN-PSK das "Kryptometer" für die Anzeige der Kennwortentropie eingeblendet wird und auch ein Button zur Generierung eines zufälligen Schlüssels, den man dann zumindest auf einer Seite der Verbindung nutzen könnte, wäre schon nicht so verkehrt.

So ein PSK muß dann natürlich auf sicherem Weg an die Gegenstelle übermittelt werden, aber da ist eben wieder C&P beim Fernzugriff auf das andere GUI möglich und sicherlich häufig auf der Fall, wenn ein Einzelner beide Endpunkte konfiguriert.

Was ich bei diesem GUI auch noch vermisse (um es etwas anwenderfreundlicher zu machen für Leute, die sich damit nicht so auskennen) ist eine Möglichkeit, aus dem Import einer (mit Kennwort exportierten) Konfigurationsdatei einer anderen Box (nur für eine einzelne VPN-Verbindung) die eigenen Einstellungen zu generieren.

Ich würde sogar soweit gehen, daß ich einen weiteren Punkt in diesem Assistenten für nützlich halte, der dann wirklich den Namen "Assistent" auch verdient. Das würde ich mir in etwa so vorstellen, daß (nur für die Zeit so einer Konfiguration) auf einer Box per Knopfdruck der Fernzugriff auf TR-064 freigeschaltet wird (mit gesondertem Port, der aber am Ende auch auf dem Webserver der Box terminiert) und die für den Zugriff auf diese zusätzliche Verbindungsmöglichkeit notwendigen Daten angezeigt werden (DynDNS-Name, Port, temporärer Benutzername, temporäres Kennwort). Dann kann man auf der Gegenseite bei einem passenden Assistenten diese Angaben in eine Maske eintragen und die lokale Box stellt dann eine Verbindung her und konfiguriert auf der entfernten Box die zur eigenen Konfiguration passende "gespiegelte" Konfiguration. Im Prinzip ist das nichts weiter als eine Anwendung von TR-069-Funktionen, die ohnehin schon vorhanden sind - die Gegenstelle ist halt nicht der ACS eines Providers, sondern eine andere FRITZ!Box.

Nach meiner Vorstellung sollte ziemlich jeder mit halbwegs normalem technischen Verständnis mit so einem Assistenten umgehen können und es würden - nach dem, was ich hier bisher so erlebt habe, würde ich das so einschätzen - 3 von 4 Fehlern bei solchen LAN-LAN-Kopplungen auch entfallen (nun ist das aber sicherlich leider nicht im Fokus von AVM, solche LAN-LAN-Kopplungen zu erleichtern, User-Verbindungen mit Smartphone/Tablet dürften der häufigere Fall sein). Angefangen beim immer wieder beliebten Eintragen der entfernten Gateway-Adresse anstelle des Netzwerk-Präfixes - ja selbst die Suche nach einem nicht überlappenden Netzwerk-Präfix und die Umkonfiguration eines Endpoiints bei Konflikten (idealerweise noch mit der Auswahl, welcher es sein soll) wäre bei so einer Aktion möglich, braucht allerdings eine "bessere Logik" und ist (logischerweise) auch nicht immer hundertprozentig zu automatisieren ... aber entscheidende Fortschritte bei vielen "Heimanwendern" würde das schon ermöglichen.

So eine Funktion könnte ich mir allerdings auch als Ergänzung eines MyFRITZ!-Kontos bei AVM ganz gut vorstellen ... wer seine Boxen ohnehin dort verwaltet, könnte dann auf Knopfdruck (an jeder Box, nicht bei AVM - damit das unter Kontrolle des Besitzers abläuft) diesen Mechanismus in Gang setzen - meinetwegen noch mit Angabe des "Namens" der Gegenstelle, obwohl auch der nicht unbedingt notwendig wäre, wenn man diesen Zugang eben nur temporär und für sehr kurze Zeit (meinetwegen 2 Minuten, innerhalb derer die Kommunikation begonnen haben muß) einrichtet und dann eben die beiden Boxen, die sich innerhalb dieser Zeit melden, miteinander "vermittelt", denn natürlich müßte die eigentliche Einrichtung nach wie vor direkt zwischen den Boxen und nicht über den AVM-Server als Relay ablaufen.

Das entschärft dann auch das Problem, daß bei den Kunden entsteht, die neben der MyFRITZ!-Anmeldung einer FRITZ!Box auch noch ein weiteres DynDNS-Konto verwenden. In meiner 7490 sind insgesamt drei DynDNS-Adressen eingerichtet (1x MyFRITZ!, 2x eigener Service) ... bei 10 Versuchen des Einrichtens über den GUI-Editor wurde aber immer der MyFRITZ!-Name als "localid" verwendet (inzwischen habe ich es dann mal getestet, ob das nur bei mir so ist oder immer, weiß ich aber auch noch nicht sicher).

Wenn also ein Kunde dann den GUI-Editor verwendet, um sich auf zwei Boxen ein LAN-LAN-VPN mit jeweils einer anderen DynDNS-Adresse zu konfigurieren, muß das zwangsläufig fehlschlagen, weil wohl jede Box als "localid" ihre eigene MyFRITZ!Adresse verwendet (ohne Möglichkeit der Auswahl bei mehreren DynDNS-Namen, die aber alle einwandfrei im "self-signed certificate" aufgeführt sind) und als "remoteid" eben das, was der Kunde beim Anlegen der Verbindung als "Internetadresse" der VPN-Gegenstelle eingetragen hat. Das hat im Extremfall nicht eine einzige Übereinstimmung - in keiner Richtung. Hier würde allerdings schon eine SELECT-Box mit den lokalen DynDNS-Namen beim Anlegen einer Verbindung helfen ... aber man kann ja auch klotzen anstatt zu kleckern. Ein Thema für irgendeine Abschlußarbeit wäre so ein "Automatismus" (oder zumindest die Untersuchung der möglichen Wege dafür) allemal und die TU (oder auch die HU) ist ja nicht so weit entfernt vom AVM-Stammsitz.
 
Danke und

Eigentlich wollte ich mich @PeterPawn in#37 und Riverhopper in #38 schon längst Bedankthaben.

Das Problem der PSK-Key-Länge habe ich verstanden. Bzgl. #39 hapert es etw. mit dem Durchblick auch wenn ich das mehrfach gelesen habe!

Deshalb erstmal die prinzipielle Frage?

Wenn 2 FBs eine VPN-LAN-LAN-Verbindung aufgebaut haben und ein "bözer Mensch" den PSK-Key kennt/bruteforced ... wie kann er in den aufgebauten VPN-Tunnel Eindringen?

OK vorstellbar, dass er als vermeintliche "Kopie einer FB" sich ausgibt? Nur dann -sofern ich eine FB-GUI als sicher betrachte mit einem halbwegs "starken" PW (- mehr als 16 Zeichen vergebe ich üblicherweise nicht, da ich mir die sonst nicht merken kann und üblicherweise nicht ständig mit einem Schlüssel-Container-USB-Stick unterwegs bin-) hat der Tunnelbroker ja immernoch die Hürde, über mein GUI-PW in eine der FBs Einzudringen? um z.B. VOIP-Accounts zu stehlen/zu Missbrauchen?

Imho sollte dies ja in den jeweiligen Ereignis-LOGs erkennbar sein? oder PUSH-Mails?

Btw. Pinge ich mal den aktuellen IP-Bereich im letzen Segment meiner aktuellen DSL-Provider-IP "durch" und klicke auf "opened" sehe ich etliche FB-GUIs. Nur die Kombi Username+PW anzutesten manuell wohl eher sinnlos?

Imho sperrt die FB-GUI ja falsche PW-Eingaben mit logaritmischer Verzögerung ... zumindest bei der mehrfachen GUI-Falsch-PW-Eingabe steigt die Wartedauer-für-Neueingabe recht schnell an (ob logaritmisch, exponentiell o.ä. weiss ich nicht ... zumindest musste ich aus Versehen schonmal 20-30 Miunten warten als VPN-Client, da ich ich PW-Zettel verkrost hatte) was ein Bruteforcing eher sinnlos erscheinen lässt?

Zum eigentlichen Thema.

Ich habe nun die Eingangskonstellation einige Zeit beobachtet/getestet. Leider hängt sich die FB7390 in Verbindung mit dem E3131 manchmal auf!

Dahingehend, ohne dies in den LOGs zu erkennen, dass der E3131 unter USB-Devices einfach "verschwindet". Unter I-Net-Verbindung=getrennt nix erscheint, und der E3131 einfach mit dem 2mal-kurz-Grün-Blinken verharrt?

Die GSM-Mobilfunknummer scheint in der GUI noch registriert ... ist sie aber nicht!

Ein Neustart via Stromlos oder selbst ein An+Abstecken des E3131 behebt das Problem. Nur bleibt die momentane Ernüchterung, dass egal welche FB-Stick-Konstellation, das "Sich-Aufhängen" weiterhin besteht. Hier u.a. ja seit Jahren bekannt ;)

Umsomehr erstaunt mich dieser Hinweis dass ein FB7490 in der E3131-Kombi keine Probleme machen soll?

LG

Hintergrund: Mangels Vorort-Präsenz-Möglichkeit mag meine FB7240+K3765 sich trotz täglichem Neustart manchmal 2-3Tage einfach nicht "Melden". Ob der Stick, das Netzteil oder FB schwächelt, lässt sich aus der Ferne nicht eruieren. Als Cross-Check kann ich dies nur über die Traffic-Daten meines ES-Providers erkennen, wobei die lokale Mobilfunkempfangslage auch aussenvor bleibt?

Als Bsp-Auszug zw. 22 und 26.11.2015

Code:
Datos
noviembre
  	CONCEPTO 	DESTINO 	FECHA 	DURACIÓN 	IMPORTE
datos	datos gratis	internet	28/11/2015 21:04:37	0.37	0,00€
datos	datos gratis	internet	28/11/2015 20:04:37	0.24	0,00€
datos	datos gratis	internet	28/11/2015 18:34:37	0.38	0,00€
datos	datos gratis	internet	28/11/2015 17:04:37	0.38	0,00€
datos	datos gratis	internet	28/11/2015 16:04:37	0.25	0,00€
datos	datos gratis	internet	28/11/2015 14:34:37	0.37	0,00€
datos	datos gratis	internet	28/11/2015 13:04:37	0.39	0,00€
datos	datos gratis	internet	28/11/2015 12:04:37	0.24	0,00€
datos	datos gratis	internet	28/11/2015 10:34:37	0.37	0,00€
datos	datos gratis	internet	28/11/2015 09:04:37	0.38	0,00€
datos	datos gratis	internet	28/11/2015 07:34:37	0.37	0,00€
datos	datos gratis	internet	28/11/2015 06:04:37	0.84	0,00€
datos	datos gratis	internet	27/11/2015 21:34:37	2.17	0,00€
datos	datos gratis	internet	27/11/2015 20:04:37	0.24	0,00€
datos	datos gratis	internet	27/11/2015 19:04:37	0.23	0,00€
datos	datos gratis	internet	27/11/2015 18:04:37	0.25	0,00€
datos	datos gratis	internet	27/11/2015 16:34:37	0.37	0,00€
datos	datos gratis	internet	27/11/2015 15:34:37	0.24	0,00€
datos	datos gratis	internet	27/11/2015 14:34:37	0.25	0,00€
datos	datos gratis	internet	27/11/2015 13:04:37	0.4	0,00€
datos	datos gratis	internet	27/11/2015 11:34:37	0.37	0,00€
datos	datos gratis	internet	27/11/2015 10:04:37	0.37	0,00€
datos	datos gratis	internet	27/11/2015 08:34:37	0.37	0,00€
datos	datos gratis	internet	27/11/2015 07:34:36	0.25	0,00€
datos	datos gratis	internet	27/11/2015 06:04:36	0.81	0,00€
datos	datos gratis	internet	27/11/2015 05:34:40	0.13	0,00€
datos	datos gratis	internet	26/11/2015 18:04:40	2.93	0,00€
datos	datos gratis	internet	26/11/2015 06:34:40	3.4	0,00€
datos	datos gratis	internet	26/11/2015 06:04:37	5	0,00€
datos	datos gratis	internet	26/11/2015 06:04:36	0.57	0,00€
datos	datos gratis	internet	22/11/2015 04:34:23	0.37	0,00€
datos	datos gratis	internet	22/11/2015 03:04:23	0.38	0,00€
datos	datos gratis	internet	22/11/2015 01:34:23	0.26	0,00€
datos	datos gratis	internet	22/11/2015 00:04:23	0.43	0,00€
datos	datos gratis	internet	21/11/2015 23:04:23	0.24	0,00€
datos	datos gratis	internet	21/11/2015 22:04:23	0.26	0,00€
datos	datos gratis	internet	21/11/2015 21:04:23	0.26	0,00€
datos	datos gratis	internet	21/11/2015 19:34:23	0.38	0,00€
datos	datos gratis	internet	21/11/2015 18:04:23	0.36	0,00€
datos	datos gratis	internet	21/11/2015 16:34:23	0.37	0,00€
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.