Upgrade auf LCOS 10.80.0450 (SU4) - VPN funktioniert nicht mehr

[mundl]

Moin,

nachdem wir unseren 1781VA von 10.42/10.50 auf die aktuelle Firmware 10.80.0450 (SU4) umgestellt haben funktioniert die VPN Einwahl via IKEv2 nicht mehr. Dies trifft sowohl für NCP also macOS native clients zu. Neueinrichtung der VPN Verbindung für Apple/iOS wie in der LC KB beschrieben bringt keine Abhilfe (an sich waren die vorher erstellten Verbindungen auch mit dieser Anleitung erstellt, also kein Wunder).

LANmonitor zeigt folgendes an (Beispiel IKEv2 via macOS Client):

IPv6 Firewall:
DENY-ALL (inbound) - IPv6 ... - Paket zurückgewiesen

IPV4 Firewall:
intruder detection - UDP Paket IPv4 ... -Paket verworfen
port scan detection - TCP Paket IPv4 ... -Paket verworfen

Scheinbar hat das Upgrade etwas an der Firewall geändert, allerdings konnte ich beim Vergleich der empfohlenen LC KB VPN Firewall Einstellungen keine Diskrepanz erkennen. Muss aber sagen, dass ich mich erst seit einer Woche mit der Materie beschäftige.

Daher bitte ich um Nachsicht und bedanke mich für die Hilfe!

[Dr.Einstein]

Kannst du einmal prüfen, ob die (VPN)Firewall Regeln korrekt in IKEv2-IPv4-Regeln konvertiert wurden?

https://knowledgebase.lancom-systems.de ... d=32986050

Mit 10.80 sind keine VPN Firewallregeln mehr möglich / gültig. Diese dienten der SA-Erzeugung und sind nun direkt in die VPN-Konfiguration gewandert. Normalerweise lautet die zugeordnete VPN-Client Regel 0.0.0.0/0 zu 0.0.0.0/32

[mundl]

Kannst du einmal prüfen, ob die (VPN)Firewall Regeln korrekt in IKEv2-IPv4-Regeln konvertiert wurden?

https://knowledgebase.lancom-systems.de ... d=32986050

Mit 10.80 sind keine VPN Firewallregeln mehr möglich / gültig. Diese dienten der SA-Erzeugung und sind nun direkt in die VPN-Konfiguration gewandert. Normalerweise lautet die zugeordnete VPN-Client Regel 0.0.0.0/0 zu 0.0.0.0/32

Vielen Dank für den Tipp! Hab es nach dieser Anleitung versucht aber LANmonitor zeigt immer noch dieselben Fehler.

Komischerweise hat das Upgrade bei einem anderen Router (1790VA) mit identischen VPN Profilen keine Probleme verursacht.

[Dr.Einstein]

Baut sich denn der VPN Tunnel auf, oder gelingt schon der Aufbau nicht mehr. Wenn der Aufbau nicht mehr gelingt, logge dich bitte via SSH oder LanTracer auf den Router ein, starte die Trace VPN-Status und VPN-Debug

Code: Alles auswählen

trace # vpn-st vpn-de

Dort sollte dann erkennbar sein, wieso sich der Tunnel nicht mehr aufbaut. Vllt. hat sich eine Verschlüsselungsgruppe geändert. Wobei dies eigentlich beim reinen Patchen nicht passiert.

[mundl]

Baut sich denn der VPN Tunnel auf, oder gelingt schon der Aufbau nicht mehr. Wenn der Aufbau nicht mehr gelingt, logge dich bitte via SSH oder LanTracer auf den Router ein, starte die Trace VPN-Status und VPN-Debug

Code: Alles auswählen

trace # vpn-st vpn-de

Dort sollte dann erkennbar sein, wieso sich der Tunnel nicht mehr aufbaut. Vllt. hat sich eine Verschlüsselungsgruppe geändert. Wobei dies eigentlich beim reinen Patchen nicht passiert.

Nochmals danke - hier der Trace:


[VPN-Status] 2024/05/27 17:12:24,731 Devicetime: 2024/05/27 17:12:24,556
Peer AW-RZ: NAT-T keep-alive (0xFF) sent physically
transport: [id: 161440, UDP (17) {outgoing}, dst: xxx.xx.xx.xx, tag 0 (U), src: xxx.xxx.x.xxx, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, (R) iface: INTERNET (3), next hop: 192.168.0.1], local port: 4500, remote port: 4500

Mehrere Einträge mit UDP Ports (hier ein Beipsiel):

[ICMP] 2024/05/27 17:12:24,798 Devicetime: 2024/05/27 17:12:24,644 [INTRANET (2)]
Sending ICMP: Destination unreachable (3), port unreachable (3) packet, scope global, routing tag 0:
Invoking packet:
IPv4: xx.xx.xx.xx -> 255.255.255.255, Total-Len: 728
UDP : 10001 -> 15000, Total-Len: 708
--> Discarded, cause: global broadcast destination address

[ICMP] 2024/05/27 17:12:24,161 Devicetime: 2024/05/27 17:12:24,006
ICMP packet received
Internet Protocol Version 4
Header length: 20
Total length: 84
Payload length: 64
DiffServ field: 0x00 (DSCP: CS0, ECN: Not-ECT)
Identification: 0x457b
Flags: 0x4000
Fragment offset: 0
Time to live: 64
Protocol: ICMP (1)
Header checksum: 0xa3a5
Source: xx.xx.xx.28
Destination: xx.xx.xx.251
Internet Control Message Protocol
Type: Echo (ping) request (8)
Code: 0
Checksum: 0x4719
Identifier: 8283
Sequence number: 256
--> ignore packet for dynamic VPN: invalid extra data coding
--->TX [id: 198117, ICMP (1) {incoming unicast, fixed source address, negotiating}, dst: xx.xx.xx.28, tag 0 (U), src: xx.xx.xx.251, hop limit: 64, pmtu: 1500, iface: INTRANET (2), mac address: xx:xx:xx:xx:xx:xx, port 2] Echo reply, ID: 8283, Seq: 256

[mundl]

Wäre wirklich sehr dankbar für weitere Tipps. Tut mir leid falls ich da was übersehen habe oder ein banaler Anfängerfehler vorliegt.

[Frühstücksdirektor]

Hallo,

der Trace sagt mir jetzt nichts verwertbares. Kannst du mal den Trace starten und laufen lassen und danach einen Client eine Verbindung aufbauen lassen?

Am besten vpn-status und vpn-debug Trace (wie oben schon geschrieben).

Viele Grüße,
Frühstücksdirektor

[plumpsack]

transport: [id: 161440, UDP (17) {outgoing}, dst: 185.17.35.17, tag 0 (U), src: 192.168.0.106, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, (R) iface: INTERNET (3), next hop: 192.168.0.1], local port: 4500, remote port: 4500

185.17.35.17

NOVENTI Health SE

Evtl. solltest du NICHT solche IP-Adressen posten.

Das könnte, ->mal wieder<- , zu Problemen führen!