VPN-Client bekommt keine Verbidung zu R883VAW

[Bogie]

Hallo,

wir haben folgende Situation. In der Zentrale steht ein Lancom R884VA (10.32.0023) mit fester IP Adresse. In einer Außenstelle steht ein Lancom R883VAW (10.32.0023) mit dynamischer IP Adresse.

Die RAS Profile der VPN Verbindungen wurden ursprünglich mit dem Setup-Assitenten erzeugt. VPN per NCP Client (11.14, IKEv2) in die Zentrale funktioniert. VPN Verbindungen (IKEv2) von mobilen Endgeräten in die Zentrale funktionieren auch. Eine Site-to-site Verbindung (IKEv2), von der Außenstelle zur Zentrale funktioniert auch. VPN Verbindungen (IKEv2) von mobilen Endgeräten in die Außenstelle funktionieren auch.

Zusätzlich wollen wir eine Backup Verbindung (IKEv2) mit NCP Client aus der Zentrale zur Außenstelle realisieren. Bisher haben wir jedoch weder mit automtisch erzeugten Profilen noch mit manuell angelegten Profilen Erfolg gehabt. Als Fehlermeldungen haben wir erhalten "Kein Medium gefunden" oder "Keine Gegenstelle gefunden" oder "falsche Benutzerdaten oder Passwort". Wir haben es zuerst mit komplexeren und dann mit einfachen Fully Qualified Domain names, Fully Qualified usernames und Passwörtern versucht. Wir bekommen immer dasselbe Bild und haben die IDs 100fach überprüft.

Eine IKEv2 Verhandlung scheint zu erfolgen. Der NCP Support konnte allerdings mit dem Lancom Trace nichts anfangen. Daher die Frage, kann man hier erkennen, was die Ursache für das Nichtzustandekommen der Verbindung ist?

[Jirka]

Hallo,

Zusätzlich wollen wir eine Backup Verbindung (IKEv2) mit NCP Client aus der Zentrale zur Außenstelle realisieren.

ist das sinnvoll?
Beschreibe mal den Fall, für den diese Verbindung dann ein Backup darstellen soll. - Ok, ist die Außenstelle weg, hilft die Backup-Verbindung auch nicht. Ist die Zentrale weg auch nicht. Ist die Zentrale weg und nur wieder da, weil der LANCOM (Blitzschaden, Hardwareschaden, Diebstahl, k. A.) durch einen "Speedport" ersetzt wurde, dann könnte sie was bringen. Dann müsstest Du den Fall jetzt aber auch herbeiführen, denn durch die bestehende VPN zwischen den Standorten kannst Du da keine weitere VPN drüber legen (gleiche (WAN-)IP-Adressen), es sei denn, Du arbeitest mit Zertifikaten.

Viele Grüße,
Jirka

[Bogie]

..., denn durch die bestehende VPN zwischen den Standorten kannst Du da keine weitere VPN drüber legen (gleiche (WAN-)IP-Adressen), es sei denn, Du arbeitest mit Zertifikaten.

Das ist die Frage, die ich mir auch gestellt habe. Aber warum funktioniert dann neben dem bestehenden VPN Tunnel von der Außenstelle zur Zentrale parallel eine VPN-Client Verbindung, nur umgekehrt von der Zentrale zur Außenstelle nicht?

[GrandDixence]

Die Verhandlung des IKE-Schlüsselmaterials schlägt fehlt. Entweder ist der Gateway im VPN-Server falsch oder gar nicht konfiguriert. Oder die Aushandlung der zu verwendeten Kryptografiemethoden schlug fehl.

Entsprechende VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
verwenden.

[Bogie]

Entsprechende VPN-Anleitung unter:

Gibt es so eine Anleitung auch, um damit die Einstellungen für Advanced VPN Client zu Lancom Routern zu überprüfen?

[GrandDixence]

Am einfachsten beginnt man mit VPN-Tunnel-Tests mit den in Windows und den Apple-Betriebssystemen integrierten VPN-Clients (native VPN Clients) für IKEv2/IPSec.

Oder noch besser: Erste Gehversuche mit der Android-App StrongSwan durchführen. Die Android-App StrongSwan hat eine ausführliche Logbuch/Log-File-Darstellung für die Fehlersuche.

Danach stellt man die Kryptografieverfahren auf die sichereren Verfahren gemäss Android-Anleitung um und testet mit dem Advanced VPN Client. Der Advanced VPN Client sollte diese sichereren Kryptografieverfahren unterstützen (ungetestet!).

[Bogie]

Das Client Profil für sich und die Verbindung funktionieren, sobald man von "außen" auf die Außenstelle zugreift.

Wenn man von der Zentrale über den Router (mit bestehendem Tunnel) auf die Außenstelle zugreift, kommt es zu den beschriebenen Effekten.
Wenn man allerdings von der Außenstelle über den Router (mit bestehendem Tunnel) mit einem ähnlichen Profil auf die Zentrale zugreift, funktioniert die Verbindung und wird parallel aufgebaut.

Was kann den Unterschied ausmachen?

[Jirka]

Hallo,

dass die Zentrale hier (also der Router der Zentrale) die VPN-Verbindung zur Außenstelle aufbaut und nicht umgekehrt.

Viele Grüße,
Jirka

[Bogie]

Das ist nicht der Fall, s.o.
In der Verbindungsliste der Zentrale steht die Haltezeit auf 0 und das E.Gateway ist leer.
In der Verbindungsliste der Außenstelle steht die Haltezeit auf 9999 und das E.Gateway auf der festen IP der Zentrale.

[Jirka]

Natürlich, ich meinte den umgekehrten Fall, sorry. Kommt von der Zentrale nun eine "Anfrage" (also mit der WAN-IP-Adresse der Zentrale), wird sie der VPN zwischen Außenstelle und Zentrale zugeordnet, da diese bereits besteht, wird die Sache abgewiesen. Steht aber alles schon in meinem Eingangsposting. Auch dass das sinnfrei ist und wann und wie es funktioniert. Und dass es außerhalb funktioniert, hast Du ja nachgewiesen, also ist doch alles ok.

Viele Grüße,
Jirka

[Bogie]

Nur meine Frage, warum das in umgekehrter Richtung funktioniert und parallel aufgebaut wird, wurde noch nicht behandelt.

[Jirka]

Hallo,

habe ich doch geschrieben:

Kommt von der Zentrale nun eine "Anfrage" (also mit der WAN-IP-Adresse der Zentrale), wird sie der VPN zwischen Außenstelle und Zentrale zugeordnet, da diese bereits besteht, wird die Sache abgewiesen.

Andersherum ist keine IP-Adresse hinterlegt in der Config, sondern nur 0.0.0.0.
Wenn Du das unbedingt brauchst, das habe ich auch schon geschrieben, dann arbeite mit Zertifikaten. Aber wenn Du es wirklich brauchst, nämlich als Backup, wie Du geschrieben hattest, dann geht doch alles, insofern verstehe ich nicht, wieso das jetzt unbedingt funktionieren soll, wo es eh keiner braucht.

Viele Grüße,
Jirka