• Der Fragesteller hat diesen Beitrag als gelöst markiert.

VPN/L2TP mit unifi - Abo zu langsam?

hed
Level 7
Level 7
21 von 40

Möglicherweise hat der User eine "wacklige" Verbindung die dauernd Reconnects provoziert welche die FIrewall der Firma wiederum dazu veranlasst, die IP irgendwann zu sperren.

 

Wie hier schon mehrmals erwähnt führt in diesem Fall kein Weg an der IT-Abteilung der Firma des erwähnten Users vorbei. Nur diese Fachleute können letztendlich sagen, weshalb die IP des Users für VPN gesperrt wird.

 

Fehlt die Bereitschaft diesen Fall End-to-End anzugehen, so wird eine systematische Fehlereingrenzung und Lösung  schwierig bis unmöglich.

kaetho
Super User
22 von 40

@Chaujeve29 du bist doch "die Firma", der VPN-Server geht auf deinen Anschluss? Und die Mitarbeiter versuchen, auf deinen VPN-Server zuzugreifen? Dann müsstest du doch nachvollziehen können, wo im eigenen Netz die IP geblockt wird?

Chaujeve29
Level 2
23 von 40

Am 14 März klappt die Verbindung mit der neuen IP zum ersten Mal:

Mar 14 08:32:26 06[IKE] <381> 85.4.62.191 is initiating a Main Mode IKE_SA
Mar 14 08:32:27 16[IKE] <remote-access|381> IKE_SA remote-access[381] established between 185.104.9.2[185.104.9.2]...85.4.62.191[10.0.0.6]
Mar 14 08:32:27 02[IKE] <remote-access|381> CHILD_SA remote-access{262} established with SPIs c05b0163_i c9d0335a_o and TS 185.104.9.2/32[udp/l2f] === 85.4.62.191/32[udp/l2f]
Mar 14 08:32:31 06[KNL] 10.255.255.0 appeared on ppp1
Mar 14 08:32:31 16[KNL] 10.255.255.0 disappeared from ppp1
Mar 14 08:32:31 08[KNL] 10.255.255.0 appeared on ppp1
Mar 14 08:32:31 14[KNL] interface l2tp1 activated
Mar 14 08:40:38 12[KNL] interface l2tp1 deactivated
Mar 14 08:40:38 03[KNL] 10.255.255.0 disappeared from l2tp1
Mar 14 08:40:44 16[KNL] interface l2tp1 deleted


Ab dem 21. läuft es nicht mehr:

Mar 21 23:34:42 10[IKE] <462> 85.4.62.191 is initiating a Main Mode IKE_SA
Mar 21 23:34:43 14[IKE] <remote-access|462> IKE_SA remote-access[462] established between 185.104.9.2[185.104.9.2]...85.4.62.191[10.0.0.8]
Mar 21 23:34:43 06[KNL] <remote-access|462> deleting policy 185.104.9.2/32[udp/l2f] === 85.4.62.191/32[udp/l2f] out failed, not found
Mar 21 23:34:43 06[KNL] <remote-access|462> deleting policy 85.4.62.191/32[udp/l2f] === 185.104.9.2/32[udp/l2f] in failed, not found
Mar 21 23:34:43 06[KNL] <remote-access|462> deleting policy 185.104.9.2/32[udp/l2f] === 85.4.62.191/32[udp/l2f] out failed, not found
Mar 21 23:34:43 06[KNL] <remote-access|462> deleting policy 85.4.62.191/32[udp/l2f] === 185.104.9.2/32[udp/l2f] in failed, not found
Mar 21 23:34:53 08[IKE] <remote-access|462> deleting IKE_SA remote-access[462] between 185.104.9.2[185.104.9.2]...85.4.62.191[10.0.0.8]

 

Tux0ne
Level 9
24 von 40

Kann er sich verbinden wenn du den VPN Server neu startest?

#restart vpn

 

Sieht so aus als ob IPsec funktioniert aber bei L2TP nichts mehr kommt.

 

 Kann zB sein, dass der User die Verbindung nicht terminiert und diese dann im Server hängen bleibt. Weiss ja nicht wie stabil diese Unifi VPN Server sind. Habe da bez. Router/Firewall eher meine Qualitätszweifel. 
Ich meine 23:34. Muss da der Remoteworker noch was machen oder lässt er seine Maschine einfach laufen?

Jeder ist beim Provider den er verdient
Jeder ist beim Provider den er verdient
Chaujeve29
Level 2
25 von 40

Habe den Restart einmal gemacht. Bisher habe ich immer den Controller neu gestartet und bin davon ausgegangen, dass dies einem Neustart des VPN Servers gleichkommt.

Wenn bei L2TP nix mehr kommt, was heisst das genau? Wird das in der meiner Firewall geblockt oder beim User?
Bewusst eine IP habe ich nicht geblockt und die Einstellungen sind immer noch System-Default. Ich könnte einmal ein Backup vom 14. März einspielen, als das VPN kurz lief.

Kann gut sein, dass der User so spät noch am Rechner ist. Er bearbeitet Playlisten und bedient einen Kinoprojektor damit. Dass er seine Maschine laufen lässt glaube ich eher nicht, doch ich hake da einmal nach....

GrandDixence
Level 1
26 von 40

Die veröffentlichten Auszüge aus den Logdateien machen mir den Eindruck, als werde in diesem Unify-Produkt als VPN-Server StrongSwan eingesetzt. StrongSwan ist ein kostenloses Open Source-Produkt, ein Schweizer Produkt und wird mit Schweizer Steuergeld mitfinanziert.

https://de.wikipedia.org/wiki/StrongSwan

 

StrongSwan gilt als "die" Referenzimplementierung von VPN-Tunneln mit IKEv2/IPSec.

 

Beginnen wir mit der Fragerunde mit den "bösen" Fragen:

 

a) Wird IKEv2 oder das veraltete IKEv1 eingesetzt? "Main Mode" stinkt nach IKEv1!

b) DPD (Dead Peer Detection) korrekt auf dem VPN-Server konfiguriert?

c) Weshalb wird IKE(v2)/L2TP und nicht IKE(v2)/IPSec eingesetzt?

 

https://de.wikipedia.org/wiki/Layer_2_Tunneling_Protocol

 

https://en.wikipedia.org/wiki/IPsec

 

d) Verfügbarkeit des Internetanschluss des Problem-Users mit dem "Broadband Quality Monitor" kontrolliert? Keine rote Paketverlustkurve in den 24 Stunden-Aufzeichnungen vom Broadband Quality Monitor sichtbar? Siehe dazu:

https://community.upc.ch/d/8569-gigaconnect-aussetzer/25

 

e) Welcher VPN-Client wird eingesetzt?

 

f) Netzwerkdatenverkehr des problematischen VPN-Tunnels aufgezeichnet und mit Wireshark ausgewertet?

https://community.upc.ch/d/8569-gigaconnect-aussetzer/25

 

L2TP sollte nur für Spezialanwendungen eingesetzt werden! L2TP arbeitet auf OSI Layer 2. IPSec auf OSI Layer 3. In 80% aller Einsatzfällen von VPN-Tunneln ist eine auf OSI Layer 3 basierende VPN-Tunnellösung die bessere Wahl und somit IKEv2/IPSec die besser geeignete Lösung.

 

Es sollte klar sein, dass hier keine kompetente und tiefgreifende Hilfestellung zu StrongSwan erwartet werden darf.

Editiert
Chaujeve29
Level 2
27 von 40

@GrandDixence: Vielen Dank:

a,b,c) Bisher habe ich mit der WebGUI von unifi gearbeitet (7.0.23) und dort kann ich IKE nicht wählen. Ausser bei einer Site-to-Site Konfiguration, was hier nicht der Fall ist, oder? Von einem Eingriff über das Terminal wird abgeraten und ich müsste mich erst schlau machen, habe auch etwas Respekt davor.

d+f) Schau ich mir noch an, muss mich aber erst noch einlesen.

e) Windows 10 oder 11 mit "Bordmitteln", also kein extra VPN-Client.

Eigentlich wollte ich nur ein einfaches VPN für maximal 10 User einrichten und dachte es gibt eine einfache Lösung. Nun bewahrheitet sich meine Befürchtung, dass dem nicht so ist.

P.S. Gestern hat die Verbindung wieder einmal geklappt.

Vielen Dank euch allen für die Inputs

Chaujeve29
Level 2
28 von 40

Mittlerweile denke ich, dass es der Leitung/Hausanschluss liegt.
Der User hat mir einige Daten notiert, wann es nicht geht und wann es funktioniert. Aus den angegebenen Zeiten lässt sich kein Muster ableiten.

Deshalb werde ich einmal openVPN auf unifi einsetzen und schauen, ob dieses zuverlässiger ist.


Nochmals vielen Dank allen, welche mir so Geduld geholfen haben.

hed
Level 7
Level 7
29 von 40

@Chaujeve29 

 

Wenn es ein Problem mit der Installation/Hausanschluss gibt, so sollte man das beheben und nicht zur Symptombekämpfung  mit einem andern VPN versuchen.

kaetho
Super User
30 von 40

Der Ansatz, die Leitung richtig zu stellen, bevor man mit einem anderen VPN-Tool, ist in einer perfekten Welt sicher richtig.

In der realen Welt wird der Aufwand für @Chaujeve29 aber vermutlich geringer sein, das mit dem anderen VPN-Tool zuerst zu versuchen.

Ich habe da aber grundsätzlich mit UDM und VPN meine Bedenken, das scheint laut diversen Forenbeiträgen zielich tricky/zickig zu funktionieren (ich habs auch nicht sauber hinbekommen 😞). Ein Raspi mit Wireguard, ins UDM-Netz eingebunden ist für mich stressfreier.

Wenn dann auch das nicht sauber funktioniert, gibt es ein Argument mehr, die andere Hausinstallation richtig stellen zu lassen.

hed
Level 7
Level 7
31 von 40

@kaetho 

 

Ein sauberes Fundament zu legen bevor man ein Haus darauf baut, ist auch in der realen Welt die übliche Vorgehensweise. Aber manche Leute bauen halt lieber auf Sand.

Chaujeve29
Level 2
32 von 40

Ihr habt ja Recht mit dem Fundament!

Nur wenn ein zeitgemäßes Abo dem User zu teuer ist, dann wird das mit dem Hausanschluss in Ordnung bringen wohl nix😉

 

Deshalb die Idee mit openVPN...

 

Trotzdem danke

hed
Level 7
Level 7
33 von 40

Nun ja, eine Lösung ist am Ende nur so gut und stark, wie das schwächste Glied in der Kette.

GrandDixence
Level 1
34 von 40

Fundament des Internetanschlusses kontrollieren:

 

- Verfügbarkeit des Internetanschlusses mit einem 24h/7 Tage-Leitungstest per ICMP-Polling (Ping-Test) kontrollieren. Zum Beispiel: Broadband Quality Monitor.

- und Paketverlustrate des Internetanschlusses messen. Zum Beispiel: CNLab-Geschwindigkeitstest

 

Siehe dazu die entsprechenden Hinweise und Links unter:

https://community.upc.ch/d/8569-gigaconnect-aussetzer/25

 

hed
Level 7
Level 7
35 von 40

@GrandDixence 

 

Man kann bei Problemen mit dem Anschluss die Leitung auch von Swisscom messen lassen. Dabei werden auch Installationsmängel wie z.B. BridgeTaps erkannt.

GrandDixence
Level 1
36 von 40

Nach dem Motto "Vertrauen ist gut, Kontrolle ist besser" sollte man als zahlender Kunde selber prüfen, ob die Dienstleistung (hier: Internetanschluss) vollständig und einwandfrei erbracht wird. Die beschriebenen Werkzeuge können vom Endkunde selbstständig und unabhängig eingesetzt werden und erlauben eine regelmässige Kontrolle des Internetanschlusses.

 

Ich empfehle die regelmässige Kontrolle des Internetanschlusses mit diesen Werkzeugen. So kann der Kunde technische Mängel frühzeitig erkennen und beheben lassen. Die Mechanismen "Sendewiederholung" (TCP-Retransmissions) und "Vorwärtsfehlerkorrektur" (FEC) "bügeln" weniger gravierende technische Mängel des Internetanschlusses oder des eigenen Netzwerks einfach aus, so dass der Kunde keine Performance- und Verfügbarkeitseinbussen feststellt.

 

Erst wenn der technische Mangel so gravierendem Ausmass annimmt, dass diese Mechanismen den Mangel nicht mehr "wegbügeln" können, spürt es der Kunde als Performance- oder Verfügbarkeitseinbusse.

 

Aber wie immer haben meine Aussagen empfehlenden Charakter. Jeder Endkunde, jede Endkundin muss selber für sich entscheiden, was er/sie benötigt und umsetzen will. Siehe dazu auch meine Empfehlungen zur Realisierung des Internetanschlusses:

https://community.swisscom.ch/t5/Internet-Allgemein/Internet-Anschluss-m%C3%B6glich-bei-Kabel-und-T-...

 

https://community.swisscom.ch/t5/Internet-Allgemein/Swisscom-vs-Cablecom-vs/m-p/690413#M63874

Editiert
kaetho
Super User
37 von 40

Alles richtig, schön und gut. Wenn ich aber die Posts von @Chaujeve29 richtig interpretiere, ist es nicht sein Anschluss, sondern ein Anschluss eines Mitarbeiters. Und wenn ich weiter richtig interpretiere, interssiert es diesen Mitarbeiter genau 0,0% was die Ursache ist, er "bockt" einfach und ist nicht bereit, an der Installation was zu verändern.

Wie würdet ihr da reagieren? Auch mit Binsenweisheiten?

Chaujeve29
Level 2
38 von 40

@kaetho , @GrandDixence , @hed 

Ihr habt ja alle recht, aber leider will der User nicht begreifen dass es ohne seine Mitarbeit nicht geht. Jeglicher Aufwand seinerseits ist ihm zuviel.

Deshalb habe ich ihm nun noch ein ovpn File gemacht. Nun hat er eine Alternative wenn's wieder einmal mit L2TP/IPsec nicht läuft.

Und ich habe wieder meine Ruhe, hoffentlich.....

hed
Level 7
Level 7
39 von 40

@kaetho 

 

Wenn sich ein Mitarbeiter renitent verhält so sollte man sich allenfalls überlegen, ob er für die Firma noch tragbar ist.

hed
Level 7
Level 7
40 von 40

@GrandDixence 

 

Mit solchen Tools misst du die Leitung nachdem die IB die FCS ausgebügelt hat und du siehst letztendlich auch nur die Auswirkung von nicht korrigierbaren Fehlern auf der Applikationsebene resp. Layer 3 oder 4. Die Messungen von Swisscom sind da sehr viel näher am Layer 1 dran.

 

Wie auch immer, meiner Meinung nach ist es für den technisch nicht affinen Kunden völlig ausreichend, wenn man ab und zu einen Speedtest macht und einen Blick auf die Diagnoseseite des Routers wirft.

 

Ein guter Indikator für eine gute Verbindung ist oft auch eine Real-Time-Applikation (Telefonie) oder TV. Da schlagen Störungen relativ schnell durch d.h. sie sind hörbar oder sichtbar. 

Editiert
Nach oben