Hallo, ich frage mich schon immer, warum sich in manchen Umgebungen eine IKEv2 client Verbindung via Lancom Adv. VPN Client (Windows oder Mac) zum eigenen Lancom VPN Router via public IP oder DNS problemlos aufbauen lässt und in manchen nicht. Wenn es nicht funktioniert erscheint immer:
ERROR - 2110: XAUTH wrong UserId or Password
Eigentlich wird das nur probiert um ein VPN Profil zu testen. Klappt es nicht dann verbinde ich das Endgerät immer mit einem mobilen Hotspot wo es dann immer funktioniert.
Hat das auch schon Jemand von Euch beobachtet oder kann mich erleuchten?
Danke!
VPN Client Verbindung von intern
Moderator: Lancom-Systems Moderatoren
-
- Beiträge: 2921
- Registriert: 12 Jan 2010, 14:10
Re: VPN Client Verbindung von intern
Hab die Erfahrung gemacht, es liegt an der WAN Verbindung des Routers. PPP-VDSL verhält sich anders als DHCPoE / IPoE.
Re: VPN Client Verbindung von intern
Das habe ich auch beobachtet und keine Lösung gefunden.
Jetzt kommt mir der leise Verdacht, das es daran liegen könnte, in welcher Reihenfolge die Verbindungen konfiguriert wurden und das möglicherweise Lanconfig beim Schreiben der Config die Reihenfolge ändert.
Und das das Verhalten anderes ist, wenn man was mittels Script macht.
Jedenfalls hatte ich auch schon sollte VPN Verbindungen,
Die mal gehen und dann in ähnlicher Situation nicht.
Vielleicht hat es auch mit der Besonderheit der LCOS Firewall zu tun, die einmal aufgebaute Sessions auch
dann weiter erlaubt, wenn eine neue Regel diese Session eigentlich blocken würde.
Ich meine , VPN Traffic wird ja letztlich auch durch Firewall Regeln erlaubt oder geblockt.
Das kann dann insgesamt unübersichtlich werden.
Also wenn wir hier mal genau herausfinden würden,
warum das beschreibende Problem auftritt,
würden wir alle viel lernen …
Viele Grüße
ts
Jetzt kommt mir der leise Verdacht, das es daran liegen könnte, in welcher Reihenfolge die Verbindungen konfiguriert wurden und das möglicherweise Lanconfig beim Schreiben der Config die Reihenfolge ändert.
Und das das Verhalten anderes ist, wenn man was mittels Script macht.
Jedenfalls hatte ich auch schon sollte VPN Verbindungen,
Die mal gehen und dann in ähnlicher Situation nicht.
Vielleicht hat es auch mit der Besonderheit der LCOS Firewall zu tun, die einmal aufgebaute Sessions auch
dann weiter erlaubt, wenn eine neue Regel diese Session eigentlich blocken würde.
Ich meine , VPN Traffic wird ja letztlich auch durch Firewall Regeln erlaubt oder geblockt.
Das kann dann insgesamt unübersichtlich werden.
Also wenn wir hier mal genau herausfinden würden,
warum das beschreibende Problem auftritt,
würden wir alle viel lernen …
Viele Grüße
ts
TakeControl: Config Backup für LANCOM Router, ALC, APs und Switche...
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
https://www.linkedin.com/posts/activity ... 04032-DNQ5
https://www.nmedv.de
-
- Beiträge: 1061
- Registriert: 19 Aug 2014, 22:41
Re: VPN Client Verbindung von intern
PPP-VDSL hat hier wohl eine Path-MTU < 1500 Byte. => Wireshark + VPN-Traces (VPN-IKE und VPN-Debug) konsultieren und das dritte und vierte IKE-Telegramm beim VPN-Tunnelaufbau untersuchen (IKE-AUTH). Die IKE_AUTH-Telegramme sind desöftern > 1500 Byte gross und werden somit zerstückelt übertragen (fragmentiert).
fragen-zur-lancom-systems-routern-und-g ... ml#p112848
Ich habe einen Beitrag von Backslash im Hinterkopf mit der Aussage das XAUH unsicher ist...
fragen-zur-lancom-systems-routern-und-g ... ml#p112848
Ich habe einen Beitrag von Backslash im Hinterkopf mit der Aussage das XAUH unsicher ist...
Re: VPN Client Verbindung von intern
Hi GrandDixence,
genau: XAUTH sollte tunlichst nicht verwendet werden, denn wegen des (meist öffentlich gemachten) Gruppenkeys kann *JEDER* einerseits die eigentliche Authentifizierung (Austausch von Username und Paßwort) im Klartext mitlesen und andererseits sich gar selbst als Server ausgeben und so eine Man-In-The-Middle-Attacket fahren, ohne bemerkt zu werden...
Durch den öffentlichen Gruppenkey ist der nächste Security-GAU, der kommt, wenn XAUTH auch noch zusammen mit dem ebenfalls unsicheren Aggressive-Mode läuft (was bei XAUTH eigentlich immer der Fall ist) eigentlich egal.
Der Aggressive-Mode ist "offline" angreifbar, d.h. ein selbst ein Brute-Force-Schutz ist wirkungslos denn ein Angreifer kann den Key mit einer einzigen Anfrage an den Server brechen.
Daher ist XAUTH auch im IKEv2 nicht mehr spezifiziert worden...
Gruß
Backslash
Code: Alles auswählen
Ich habe einen Beitrag von Backslash im Hinterkopf mit der Aussage das XAUH unsicher ist...
Durch den öffentlichen Gruppenkey ist der nächste Security-GAU, der kommt, wenn XAUTH auch noch zusammen mit dem ebenfalls unsicheren Aggressive-Mode läuft (was bei XAUTH eigentlich immer der Fall ist) eigentlich egal.
Der Aggressive-Mode ist "offline" angreifbar, d.h. ein selbst ein Brute-Force-Schutz ist wirkungslos denn ein Angreifer kann den Key mit einer einzigen Anfrage an den Server brechen.
Daher ist XAUTH auch im IKEv2 nicht mehr spezifiziert worden...
Gruß
Backslash