[GELÖST] Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

[GELÖST] Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Beitrag von BjörnG »

Hallo werte Community,

nachdem ich jetzt zweimal gescheitert bin, einen 'alten' 1793VA LANCOM-Router gegen den 'neuen' 1900EF zu ersetzen, wende ich mich nun an euch.
Ich fürchte ich mache einen ganz banalen Fehler, aber sehe den Wald vor lauter Bäumen nicht. Daher beschreibe ich erst mal grob in Prosa, und bitte euch mir zu sagen, ob ich es richtig angehe, oder ob da ein grober Schnitzer drin sein könnte. Das Konstrukt habe ich so 'geerbt', ich kann nicht sagen warum das so gebaut wurde.

Die Tunnel sind von Dritten zur Verfügung gestellt, ich habe da nicht ohne weiteres Zugriff auf die Gegenstellen.
Soviel weiß ich noch:
Der IKEv1 Tunnel lauscht ob er aktiv ist, auf der Gegenstelle, und baut ihn von sich aus auf, wenn wir offline waren.
Der IKEv2 Tunnel ist nur da, wir müssen eine Verbindung aktiv bei ihm anfragen.

Szenario:

- 1 VPN Site-to-Site IKEv1 mit PSK terminiert auf dem 'alten' Router 1793VA (11.11.11.11).
   (WAN-Verbindung(IP) für den s2s kommt von vorgeschalteter FritzBox am 1793VA, also 2.2.2.2 => 11.11.11.11)
- 1 VPN Site-to-Site IKEv2 mit PSK terminiert ebenfalls auf den 'alten' Router 1793VA (11.11.11.11).
   (WAN-Verbindung(IP) für den s2s kommt von vorgeschalteter FritzBox am 1900EF, also 1.1.1.1 => 22.22.22.22. => 11.11.11.11)

Hier einmal bildlich dargestellt:
Bild

Der 1793VA soll außer Betrieb gesetzt werden, und der 1900EF alleiniger Router im Netz sein, beide WAN-Strecken terminieren dann hierauf.
Die WAN-Verbindungen am 1900EF konnte ich ohne Probleme mit dem Setup-Assistenten und IPoE einrichten. Kreuz-Pings zwischen Source und Destination IPs gingen fehlerfrei durch. D.h.:
PingSource WAN1(IP) zu IKEv1(TransIP) und IKEv2 (TransIP) erfolgreich.
PingSource WAN2(IP) zu IKEv1(TransIP) und IKEv2 (TransIP) erfolgreich.

Code: Alles auswählen

root@Multi-WAN-VPN-Gateway-LANCOM1900EF:/
> ping -r VPN-TransIP2 -a 2.2.2.2
 56 Bytes Data, 10 Packets transmitted, 10 Packets received, 0% loss

root@Multi-WAN-VPN-Gateway-LANCOM1900EF:/
> ping -r VPN-TransIP1 -a 2.2.2.2
 56 Bytes Data, 10 Packets transmitted, 10 Packets received, 0% loss

root@Multi-WAN-VPN-Gateway-LANCOM1900EF:/
> ping -r VPN-TransIP2 -a 1.1.1.1
 56 Bytes Data, 6 Packets transmitted, 6 Packets received, 0% loss

root@Multi-WAN-VPN-Gateway-LANCOM1900EF:/
> ping -r VPN-TransIP1 -a 1.1.1.1
 56 Bytes Data, 6 Packets transmitted, 6 Packets received, 0% loss
Firewall-Rules sind 1:1 vom 1793AV auf den 1900EF übertragen worden.
Verbindungseinstellungen der VPNs IKEv1 und IKEv2 sind ebenfalls 1:1 übertragen worden.

Wie ich bisher vorgegangen bin:

- Router 1793VA von den Netzen getrennt, vorgelagerte FritzBox auf 1900 EF gesteckt und die WAN-Strecken jeweils mit Assistent in Betrieb genommen.
- Geprüft ob beide WAN-Strecken am 1900EF funktional sind. Waren und sind sie.
- VPN IKEv1 Host der Gegenstelle eingetragen, damit die Verhandlungen beginnen können.
- VPN IKEv2 'aktiviert', damit auch hier der Tunnel neu aufgebaut wird.

Beide Tunnel funktionieren nicht. ich sehe mit 'trace + vpn', daß sie Anfragen senden, aber es kommen keine Antworten.

Hier mal der Trace vom IKEv2 am 1900EF: https://pastebin.com/7nPAmCiP

Ich kann, wie gesagt, nicht sehen, daß ich von der Gegenstelle eine Antwort bekomme.
Ich weiß aber auch nicht ob und wie ich an meiner Seite sehen kann, ob die Anfragen überhaupt raus gehen.

Ich bin für jeden Vorschlag oder Hinweis dankbar, also immer her damit. ;)

Und zu guter Letzt, das Forum und die Community hier sind spitze, macht bitte weiter so!

Nachtrag, der 1900EF hat eine aktuelle Firmware:

Code: Alles auswählen

> ls Firmware/Version-Table/

Ifc   Module            Version                         Serial-number
======---------------------------------------------------------------------
Ifc   LANCOM 1900EF     10.50.0619RU5 / 07.02.2022
ratlose Grüße,
Björn
Zuletzt geändert von BjörnG am 10 Mär 2022, 19:10, insgesamt 1-mal geändert.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Beitrag von GrandDixence »

Der Verbindungsaufbau bei IKEv2 erfolgt mit 4 IKE-Telegramme.
https://www.heise.de/security/artikel/E ... 70056.html

Beim Erkennen einer NAT-Situation im Netzwerkpfad zwischen den beiden VPN-Endpunkten werden:

- die ersten 2 IKE-Telegramme (IKE_SA_INIT-REQUEST und IKE_SA_INIT-RESPONSE) über UDP Port 500 abgewickelt.

- das 3. IKE-Telegramme und alle nachfolgenden IKE-Telegramme werden über UDP Port 4500 abgewickelt (NAT-Traversal).

Aus den Aufzeichnungen ist ersichtlich, dass das 3. IKE-Telegramm (IKE_AUTH-REQUEST) versendet wird, aber kein 4. IKE-Telegramm empfangen wurde (IKE_AUTH-RESPONSE). Somit schlägt der Aufbau des VPN-Tunnels fehl.

Ich empfehle ein Downgrade auf eine LCOS-Firmware aus dem "Stable"-Zweig (Aktuell: 10.42 RU6).
https://www.lancom-systems.de/produkte/ ... ebersicht/

https://www.lancom-systems.de/downloads/

Danach kontrollieren, ob die LANCOM-VPN-Konfiguration der entsprechenden VPN-Anleitung unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
entspricht.

Und schliesslich muss man mit Wireshark auf die Jagd nach dem 4. IKE-Telegramm (IKE_AUTH-RESPONSE) gehen. Mit der Jagd beginnen am WAN-Port der Fritzbox und sich dann Durcharbeiten bis zum WAN-Port des LANCOM-Routers.
alles-zum-lancom-advanced-vpn-client-f3 ... ml#p108170

Viel Glück bei der Fehlersuche!
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Beitrag von BjörnG »

Moin GrandDixence.
GrandDixence hat geschrieben: 28 Feb 2022, 21:54 Der Verbindungsaufbau bei IKEv2 erfolgt mit 4 IKE-Telegramme.
https://www.heise.de/security/artikel/E ... 70056.html

Beim Erkennen einer NAT-Situation im Netzwerkpfad zwischen den beiden VPN-Endpunkten werden:

- die ersten 2 IKE-Telegramme (IKE_SA_INIT-REQUEST und IKE_SA_INIT-RESPONSE) über UDP Port 500 abgewickelt.

- das 3. IKE-Telegramme und alle nachfolgenden IKE-Telegramme werden über UDP Port 4500 abgewickelt (NAT-Traversal).

Aus den Aufzeichnungen ist ersichtlich, dass das 3. IKE-Telegramm (IKE_AUTH-REQUEST) versendet wird, aber kein 4. IKE-Telegramm empfangen wurde (IKE_AUTH-RESPONSE). Somit schlägt der Aufbau des VPN-Tunnels fehl.
Ich hab das jetzt seit Sonntag genau nicht gesehen. Vielen Dank, das hilft echt weiter. Und vielen Dank für deine Mühe und ausführliche Antwort.

Ich schaue mir die Release-Notes der Firmware mal an. Ich bin eher der Typ 'Fluch nach Vorn'. Kannst Du aus dem Stehgreif sagen warum Du den Downgrade empfiehlst?

Grüße,
Björn
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Beitrag von BjörnG »

Hinweis: Ich glaube ich habe den Fehler gefunden.

Ich habe der Regel zum jeweiligen VPN Tunnel in der Firewall keinen Routing-Tag der zu benutzenden WAN-Verbindung gegeben... :roll:

Das passiert wenn man von einem single-WAN auf Multi-WAN-Router umsteigt. Das war jetzt echt zu banal... Mal schauen wann ich ein Zeit Fenster finde um das zu prüfen. Rückmeldung ob das der Fehler war, so plausibel er auch zu sein scheint, wird kommen.

Gebt mir 2-3 Wochen Zeit. ;)
Benutzeravatar
BjörnG
Beiträge: 12
Registriert: 14 Feb 2022, 14:30

Re: Migration 1793AV zu 1900EF scheitert an IKEv1 und IKEv2 site to site

Beitrag von BjörnG »

Heureka, ich hab die letzten zwei Wochen soviel über site-to-site VPN gelernt, wie ich es bewusst die letzten -gefühlt- zwei Jahrzehnte vermieden hab mich damit auseinander zu setzen.

Jetzt musste ich.

Es GEHT !!! Der Threat kann direkt als 'gelöst' markiert werden. (Finde nichts, wo ich das einstellen kann...)

Vielen Dank für die Unterstützung.

Was hatte ich verpeilt?

Beim Umstieg auf den Multi-WAN-Router hatte nicht nicht berücksichtigt, daß in den Firewall-Regeln für die VPN-Verbindungen auch die Routing-Tags angegeben werden müssen. Blöd, aber an sowas einfachen kann man scheitern...

Beim IKEv1 wäre ich fast gescheitert, weil alles richtig konfiguriert war... Es fehlte aber trotzdem noch was...
Schon blöd, wenn man der Verbindung lokale und remote IPs mitgibt um die Auth. zu starten, dann aber zusätzlich noch eine VPN-ID (also die zugewiesene LAN-IP der Fritz!Box zum LANCOM) angeben muss... Da muss man erst mal drauf kommen...
Antworten