[Problem] Internet down, 2 VPN Laptops, ipv6 ??

hansxxx

Mitglied
Mitglied seit
25 Nov 2010
Beiträge
385
Punkte für Reaktionen
3
Punkte
18
Morgen zusammen,
seit etwa einer Woche bricht das Internet jede Stunde einmal zusammen, sobald meine Partnerin und ich gleichzeitig im Homeoffice sind. Wir beide nutzen eine VPN.
Siehe Log von der 7590.
Das Problem war zuvor nie. Wir waren ja öfter schon im Homeoffice. Jemand eine Idee?
 

Anhänge

  • A0667A28-DDF3-48BA-9526-ABDF065D804D.jpeg
    A0667A28-DDF3-48BA-9526-ABDF065D804D.jpeg
    839.5 KB · Aufrufe: 34
bricht das Internet jede Stunde einmal zusammen
Nö, das wäre dann wirklich schlimm.
Deine FB macht nur einen Resync.
Warum? Das sieht man in den Ereignissen nicht.
Da erstelle das nächste mal gleich nach dem Resync die Supportdatei.
Dann sieht man hoffentlich mehr.
 
Internet down? Hast du schon ein paar Mal den Internetstecker aus der Wand gezogen und wieder reingesteckt? :confused:
 
Sag mal wollte ihr mich veräppeln? Ganz doof bin ich nicht. Das Internet läuft mit Magentatv einwandfrei. Nur wenn wir zu zweit von zuhause arbeiten ist feierabend

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

[...]
Da erstelle das nächste mal gleich nach dem Resync die Supportdatei.
Dann sieht man hoffentlich mehr.
Kann ich dir die per Pn schicken?
 
Zuletzt bearbeitet von einem Moderator:
Dateien kann man nicht per PN schicken.

Wir benötigen auch nur einen kleinen Teil daraus, den kannst du hier veröffentlichen.
 
[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]

Welchen denn?
 
Das wissen andere hier besser.
 
Habt ihr mal probiert, dass sich einer als Gast verbindet?
 
Habe Sie jetzt ins Gastnetzwerk reingepackt. Ohne Zugriff auf das Heimnetzwerk

[Edit Novize: Beiträge zusammen gefasst - siehe Forumsregeln]

Auch im Gastnetzwerk zusammenbruch :mad:
 
Zuletzt bearbeitet von einem Moderator:
@hansxxx Bitte verhalte Dich den Regeln entsprechend, Du hast diese ja auch abgenickt ;)
Keine Schiebepostings => Nachträge gehören in den vorigen Beitrag
Keine Fullquotes => Wir wissen schon, was wir soeben erst gelesen haben

Ich habe mehrfach hinter Dir her geputzt, ab jetzt halte deine Beiträge bitte selbst sauber. Danke
 
  • Like
Reaktionen: hansxxx
Mein Vorschlag war einer im Haupt- und einer im Gastnetz.
 
Er hat stattdessen EINE ins Gastnetz reingepackt, nämlich Sie. :D
 
Mit VPN sollte die Internetstabilität in dieser Konstellation wenig bis nichts zu tun haben:
Jeder PC wird doch hoffentlich seinen eigenen VPN-Treiber haben, um sich in das jeweilige Firmennetz zu wählen - dass die Fritz das für die beiden Netze übernimmt, ist sehr unwahrscheinlich. ;)
Daher sind hier auch nur die normalen Daten, die irgendwo ins Netz fließen und von dort empfangen werden. Halt, wie jede andere Verbindung auch, z.B. die des Browsers, Mailclients usw...

Ich habe hier einen VPN-Server laufen, an dem aktuell 30 Clients dran hängen. Wenn nicht gerade intensiv gearbeitet wird und Daten getauscht werden, ist die Netzauslastung im Upload exakt unter 1%. Im Download gar nicht messbar. Als Fazit kann man sagen, die Auslastung der Internetanbindung ist nur so hoch, wie der aktuelle Datenaustausch der PCs/Geräte. Ob mit oder ohne VPN spielt für die Fritz absolut keine Rolle.
Warum auch? Die routet ja nur irgendwelche Datenpakete von A nach B, wie ohne VPN auch.

Daher vermute ich, das mit den Internetausfällen ist entweder ein blöder Zufall, dass die genau jetzt auftreten oder es gibt allgemein ein elektrisches Problem zwischen den PCs und dem Router. Das mit dem elektrischen Problem ist natürlich nur dann denkbar, wenn beide PCs per LAN dran hängen, per WLAN hat sich das eh erledigt.
 
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).
 
Egal, welche Einschränkungen es hier evtl geben sollte - dass die DSL-Verbindung abreißt, hat doch nichts mit VPN - in welcher Spielart auch immer - zu tun.
 
Wenn der "dsld" tatsächlich abstürzt (der muß schließlich auch die Passthrough-Verbindungen verwalten) und bei seinem Neustart (als einzelner Prozess, nicht die gesamte Box) genau dasselbe macht, wie bei jedem anderen Start auch (nämlich eine Synchronisation der Leitung anzuschieben), dann sehe ich nichts, was der gezeigten Folge von Meldungen im Event-Log des FRITZ!OS entgegenstehen sollte - außer die ggf. nicht ganz treffende Aussage: "DSL antwortet nicht.", die aber problemlos auch für "Die Verbindung zwischen den DSL-Komponenten und dem Rest der Firmware ist abgerissen." stehen kann und genau für diese Verbindung ist nun mal auch der "dsld" zuständig.

Wenn AVM da nichts vollkommen umgestoßen haben sollte, führt das Laden der Treiber und der Start weiterer Prozesse (bei VR9 wären das "dsl_control" und "dsl_monitor") jedenfalls noch nicht zum Versuch einer DSL-Synchronisation. Der "dsl_monitor" (bei VR9-Boxen) läuft bei AVM üblicherweise sogar dann mit, wenn die Box in Wirklichkeit nur über LAN1 (bei den VR9-Boxen gibt's noch keinen "WAN" genannten Port für Ethernet-Uplinks) als Router arbeitet.

Anders als bei den Kabel-Boxen, wo das CM ja tatsächlich ein eigenes System (mit eigenem Prozessor) ist und mit dem eigentlichen FRITZ!OS nur über eine (interne) Netzwerk-Verbindung kommuniziert, ist das bei DSL alles auf einer "Maschine" und wenn der "dsld" bei seinem Start die Synchronisation startet, ist das nur logisch und konsequent ... daß er das generell können muß, sieht man an den verfügbaren Buttons im GUI, mit denen man (programmgesteuert und auch ohne Neustart der kompletten Box) auch die erneute DSL-Synchronisation erzwingen kann.

Sollte der "dsld" hier also tatsächlich neu starten (das war schon weiter oben im Thread meine Prämisse), würde es mich eher wundern, wenn da keine neue DSL-Synchronisation stattfände. Nur ist es sicherlich noch lange nicht klar, daß/ob der auch tatsächlich neu startet - aber genau dafür gibt es ja die Support-Datei und ich wollte eigentlich nur die "theoretische Grundlage" aufzeigen, wie das beschriebene Verhalten, die diversen VPN-Implementierungen (jenseits des AVM-IKEv1) und die gezeigten Messages im Event-Log zueinander passen könnten.
 
Als "Fehlerbehandlung" hätte ich auch eher einen Neustart als einen Resync vermutet, aber ich lasse mich auch überzeugen.
Jedenfalls wäre jetzt ein guter Zeitpunkt für die fehlenden Angaben von hansxxx wie der VPN-Typ.

Mit mehreren parallelen Windows-L2TP/IPSec-VPN-Verbindungen über AVMs Router hatte ich seit März 2020 an mehreren Standorten keinerlei Probleme. Auch Doppel-NAT hinter Telekom-Zwangsrouter und 7560 war dabei unauffällig.
 
Bei einem kurzen Blick auf andere Beiträge des TE, würde ich auch die Repeater und Telekom IP-TV mit auf den "Ursachen-Zettel" schreiben, um dem Crash-Grund näher zu kommen.
Da die Telekom imho Dual-Stack anbietet, könnte man als erstes mal IPv4-Only probieren, um erste Fehlerquellen auszuschliessen und auf IP-TV mal verzichten?

dass die DSL-Verbindung abreißt, hat doch nichts mit VPN
Das Problem kann schon an der Datenmenge und Auslastung liegen. Wenn Video-Streams durch den Tunnel gesandt werden, kann VPN schonmal die komplette Bandbreite nutzen, wo dann selbst SIP-Telefonie kaum nutzbar ist.
Da gab es immerwieder mal hier im eigenen Umfeld krude Ereignisse, falls einiges am Limit gleichzeitig auftrat.
LG
 
Sollte der "dsld" hier also tatsächlich neu starten (das war schon weiter oben im Thread meine Prämisse), würde es mich eher wundern, wenn da keine neue DSL-Synchronisation stattfände.
Wenn der dsld crasht und neu gestartet wird, dann wird er doch kaum vorher noch einen Abschiedsgruß "DSL antwortet nicht" im Log hinterlassen.
Auch glaube ich irgendwie nicht daran, dass die DSL-Verbindung dann "irgendwann" abreißt, so wie ich es oben heraus lese - der Abbruch wäre sofort beim Aufbau der 2. VPN-Verbindung der Fall: Eine der beiden VPN-Verbindungen funktioniert, die andere hat das Nachsehen. Oder meinetwegen auch: die 2. Verbindung wird gestartet, der dsld crasht sofort und startet neu
Oder halt es geht ganz einfach parallel mit vielen Verbindungen, wie bei mir auch...
SINEMA Remote Connect.png
Hier sind 4 Benutzer mit je einer openvpn-Verbindung über den Siemens-Server (VMWare-Linux-Maschine) mit einem der aktuell 22 aktiven Geräte verbunden. (Die Geräte sind zusätzlich zu Openvpn auch noch per IPSec mit dem Server verbunden!) Also sind aktuell 22 IPSec-Verbindungen und 26 openvpn-Verbindungen aktiv, davon haben 8 Verbindungen einen regen Datenaustausch.
Und die Fritz langweilt sich dabei, in der Auslastung kann ich beim aktuellen VDSL100 rein gar nichts an Datenmengen sehen. Früher bei ADSL16 war in der Tat was zu sehen, aber auch da war es keine Auslastung der DSL-Anbindung.

Das Problem kann schon an der Datenmenge und Auslastung liegen. Wenn Video-Streams durch den Tunnel gesandt werden, kann VPN schonmal die komplette Bandbreite nutzen
Jepp, bei einer VDSL-Bitrate von ~100/40 Mb/s wird das mit 1-2 Videostreams aber schwer zu erreichen sein. trotzdem kann der TE ja mal schauen, was da an Auslastung passiert, wenn da 2 VPN-Verbindungen aufgebaut sind.
Wenn magenta-TV problemlos funktioniert, wird es meiner Einschätzung nach auch nicht daran liegen, dass die Box nun ans ackern kommt. Vergessen wir nicht, die Netzteile altern, aber wir sprechen hier von ein recht neuen Box (7590). Ist das Netzteil nicht "einfach" defekt und lässt die Box dann auch anlasslos regelmäßig neu starten - einen Defekt durch Alterung sollten wir hier noch ausschließen können. ;)
 
Zuletzt bearbeitet:
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.