Teil 2 VPN Problem nach Uprade von 1781 auf 1803

[snooppycount]

allo zusammen

Never change a runnig system....

Ich habe einem 1803VAW per Import (Skript) von einem 1781VAW konfiguriert.
Mit der Hilfe vom Forum waren dann letzte Woche alle VPN-Verbidungen (IKEv1 und IKEv2) wieder funktional

Nun wird aber die VPN IKEv1 Verbindung "BZ_WLC", seit zwei Tagen, nicht mehr aufgebaut.
Aufbau WLC 4606+ (BZ_WLC) -> 1790VA -> Internet -> 1803 VAW (WEH03).

Die Verbindung wurde immer aktiv vom "BZ_WLC" zum "WEH03" aufgebaut werden.


Lokales Netz 192.168.10.x (Router .222). Entferntes Netz 192.168.1.x (Router BZ_WLC, .1).

show ipv4-fib auf 192.168.1.1 (BZ_WLC)
Ausgaben des Befehls
IPv4 Unicast FIB
Rtg-Tag 0

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
0.0.0.0/0 192.168.4.1 INTERNET 5 on Redistribute Static (5)
10.0.0.0/8 0.0.0.0 #Null 0 no Never Static (5)
127.0.0.0/8 0.0.0.0 #Loopback 1 no Never Loopback (0)
127.0.0.1/32 0.0.0.0 #Loopback 1 no Never Loopback (0)
172.16.0.0/12 0.0.0.0 #Null 0 no Never Static (5)
192.168.0.0/16 0.0.0.0 #Null 0 no Never Static (5)
192.168.1.0/24 0.0.0.0 INTRANET 3 no Redistribute Connected LAN (2)
192.168.1.1/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)
192.168.4.0/24 0.0.0.0 INTERNET 5 on Redistribute Connected WAN (2)
192.168.4.1/32 0.0.0.0 INTERNET 5 on Redistribute DHCP (15)
192.168.4.12/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)
192.168.10.0/24 0.0.0.0 WEH03 8 no Down Static Ifc Down (255)
192.168.200.0/24 0.0.0.0 GASTZUGANG 2 no Redistribute Connected LAN (2)
192.168.200.1/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)

Rtg-Tag 1

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
0.0.0.0/0 192.168.4.1 INTERNET 5 on Redistribute Static (5)
10.0.0.0/8 0.0.0.0 #Null 0 no Never Static (5)
127.0.0.0/8 0.0.0.0 #Loopback 1 no Never Loopback (0)
127.0.0.1/32 0.0.0.0 #Loopback 1 no Never Loopback (0)
172.16.0.0/12 0.0.0.0 #Null 0 no Never Static (5)
192.168.0.0/16 0.0.0.0 #Null 0 no Never Static (5)
192.168.1.0/24 0.0.0.0 INTRANET 3 no Redistribute Connected LAN (2)
192.168.1.1/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)
192.168.4.0/24 0.0.0.0 INTERNET 5 on Redistribute Connected WAN (2)
192.168.4.1/32 0.0.0.0 INTERNET 5 on Redistribute DHCP (15)
192.168.4.12/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)
192.168.10.0/24 0.0.0.0 WEH03 8 no Down Static Ifc Down (255)

Rtg-Tag 2

Prefix Next-Hop Interface ID Masquerading Redistribution Type (Distance)
--------------------------------------------------------------------------------------------------------------------------
0.0.0.0/0 192.168.4.1 INTERNET 5 on Redistribute Static (5)
10.0.0.0/8 0.0.0.0 #Null 0 no Never Static (5)
127.0.0.0/8 0.0.0.0 #Loopback 1 no Never Loopback (0)
127.0.0.1/32 0.0.0.0 #Loopback 1 no Never Loopback (0)
172.16.0.0/12 0.0.0.0 #Null 0 no Never Static (5)
192.168.0.0/16 0.0.0.0 #Null 0 no Never Static (5)
192.168.4.0/24 0.0.0.0 INTERNET 5 on Redistribute Connected WAN (2)
192.168.4.1/32 0.0.0.0 INTERNET 5 on Redistribute DHCP (15)
192.168.4.12/32 0.0.0.0 #Loopback 1 no Redistribute Local WAN (0)
192.168.10.0/24 0.0.0.0 WEH03 8 no Down Static Ifc Down (255)
192.168.200.0/24 0.0.0.0 GASTZUGANG 2 no Redistribute Connected LAN (2)
192.168.200.1/32 0.0.0.0 #Loopback 1 no Redistribute Local LAN (0)


VPN Trace auf dem lokalen 1803VAW

VPN-Status] 2025/09/08 10:13:14,110 Devicetime: 2025/09/08 10:13:14,090
VPN: Error: IFC-I-Remote-gateway-is-unspecified-or-zero (0x112a) for BZ_WLC (0.0.0.0 IKEv1)

[VPN-Debug] 2025/09/08 10:13:14,110 Devicetime: 2025/09/08 10:13:14,090 [Tunnel-Groups] Peer BZ_WLC without group has disconnected, ignored

[VPN-Status] 2025/09/08 10:13:14,110 Devicetime: 2025/09/08 10:13:14,090
VPN: connecting to BZ_WLC (0.0.0.0 IKEv1)
unspecified or zero remote gateway

[VPN-Status] 2025/09/08 10:13:14,203 Devicetime: 2025/09/08 10:13:14,198
VPN: local reconnect lock active for BZ_WLC

[VPN-Status] 2025/09/08 10:13:14,325 Devicetime: 2025/09/08 10:13:14,310
VPN: local reconnect lock active for BZ_WLC

[VPN-Status] 2025/09/08 10:13:15,031 Devicetime: 2025/09/08 10:13:15,024
VPN: Error: IFC-I-Remote-gateway-is-unspecified-or-zero (0x112a) for BZ_WLC (0.0.0.0 IKEv1)


Bin nun etwas ratlos, auch bei der Fehlersuche.

Auf den "BZ_WLC" komme ich aktuell nur per "HTTP-Tunnel" via 1790VA.
Der 1790VA ist auch per VPN verbunden.


Danke im Voraus
Jürgen

[GrandDixence]

[VPN-Status] 2025/09/08 10:13:15,031 Devicetime: 2025/09/08 10:13:15,024
VPN: Error: IFC-I-Remote-gateway-is-unspecified-or-zero (0x112a) for BZ_WLC (0.0.0.0 IKEv1)

Dieses LANCOM-Gerät soll als Initiator den VPN-Tunnel aufbauen, weiss aber nicht, wohin es (remote gateway) das erste IKE-Telegramm für den VPN-Tunnelaufbau schicken soll. => Konfigurationsparameter:

Setup > VPN > VPN-Gegenstellen > Entferntes-Gw

kontrollieren.
https://www.lancom-systems.de/docs/LCOS ... _19_9.html

[snooppycount]

Hallo

Der trace ist vom Router, der die Verbindung annehmen soll 1803VAW (WEH03).

Der WLC kann ja nicht von außen erreicht werden, da er hinter dem 1790VA steht und muss daher die Verbindung aufbauen, oder?
Hatte ja bisher auch immer funktioniert. Auf dem WLC ist als entferntes Gateway die DynDns Adresse vom WEH03 hinterlegt.
Ich vermute das Problem auf dem 1803VWA (WEH03), oder liege ich falsch?


Danke

[GrandDixence]

Hier sollte man nicht Vermutungen anstellen. Sondern mit den üblichen Fehlersuchwerkzeugen den Fehler eingrenzen.

Was liefern die Traces vpn-ike, vpn-debug und vpn-status auf dem VPN-Tunnel aufbauenden LANCOM-Gerät (Initiator) für aussagekräftige Fehlermeldungen?

[snooppycount]

Hallo

Kann ich die erstellte Traceaufzeichnung ("*.lct"), ohne Sicherheitsbedenken, hier posten?
Wird die zugeörige ("*.spf") Datei auch benötigt?

Gruß

[backslash]

Hi snooppycount

die Trace-Datei ist eher unkritsich...

mit der .spf-Datei solltest du aber vorsichtig sein. In ihr sind zwar alle Paßwortfelder durch "<content replaced>" ersetzt, Paßwörter können aber auch in Feldern auftauchen, die nicht als Paßwortfeld markiert sind (z.B. in der Aktionstabelle für Dyndns-Updates)

zudem wird die .spf Datei zur Fehlersuche erstmal nicht benötigt

Gruß
Backslash

[snooppycount]

Hallo Backslash

Danke für die Info.
Hier nun die Datei.

Danke im Voraus
Jürgen

[Dr.Einstein]

Die Gegenseite lehnt den Tunnelaufbau in der Phase 2 ab. Wenn du also die Ursache herausfinden willst, musst du den gleichen Trace auf der anderen Seite starten.

Denke, du hast etwas mit den Netzbeziehungen. Hast du überprüft, ob vorher VPN-Firewallregeln existieren? Diese musst du bei neueren Firmwareständen in VPN überführen.

Ansonsten noch der Hinweis: Du nutzt IKEv1. Du solltest diesen Tunnel durch IKEv2 ersetzen. Einfach mittels Assistenten > Gegenstelle löschen, danach auch mittels Assistenten über Kreuz eine neue Site-to-Site-Verbindung einrichten. Dort erledigt sich das VPN-Regelwerk dann eh, weil der Assi eine 255.255.255.255-er Regel erzeugt.

[snooppycount]

Hallo Dr.Einstein

Manchmal sieht man (wenn zu lange vor dem PC) den Wald, vor lauter Bäumen nicht
Ja, ich hatte zwar die Firewallregel neu erzeugt (und IHMO zig mal geprüft), allerdings mit einem Tippfehler zum Netz

Nun funktioniert der Tunnel wieder, und ich werde das demnächst auf IKEv2 umstellen.

Dankeschön!
Jürgen