IKEv2-VPN Tunnel steht aber irgendwann kein Traffic möglich

[wissbegieriger]

Hallo,

ich habe mir einen Cluster aus zwei ISG-4000 (mittels VRRP) gebaut.
Beide ISG-4000 haben einen Internetzugang und werden parallel betrieben um ein "Load-Balancing" zu erreichen.
Die Gegenstellen sind diverse Router mit diversen Anbindungen (LTE, DSL). Alle VPN-Verbindungen sind IKEv2 und alle Geräte verfügen über 10.32 RU7 bzw. RU8 bzw. RU9.
Dieses Verhalten tritt bei beiden ISG-4000 auf. Egal ob ich den Tunnel zu Gateway A oder Gateway B aufbauen lasse.

Nun kommt es bei einigen Routern vor das der Tunnel quasi einschläft und kein Traffic mehr möglich ist.
Die Tunnel steht jedoch weiterhin und das auch tagelang.
Der Tunnel wird aufrecht erhalten da DPD-Pakete regelmäßig gesendet und empfangen werden. Dies kann ich im VPN-Trace sehen.
Trenne ich den VPN-Tunnel (z.B. über den LANMonitor) wird er sofort wieder aufgebaut und der Traffic läuft direkt wieder bis der Tunnel einschläft.
Die Zeit bis zum einschlafen ist unterschiedlich aber 30 Minuten aufwärts.

Habt ihr eine Idee wie ich das Problem noch eingrenzen kann?
Vielen Dank!

[ua]

Moin,

Polling eingerichtet?
DPD auf beiden Seiten?

VG

[wissbegieriger]

Servus,

DPD ist auf beiden Seiten eingerichtet dadurch bleibt der Tunnel ja auch bestehen.
Die DPD-Pakete schaffen es ja auch durch den Tunnel, nur keine Nutzdaten wie beispielsweise ein Ping.
Dies funktioniert erst wieder nach einem Reconnect.

Ein Polling (Kommunikation/Protokolle/Polling-Tabelle?) ist nicht eingerichtet.
Was würde dieses in meinem Fall nutzen? Der Router würde erkennen das die Gegenstelle nicht verfügbar ist.
Ist es nicht nur ein Workaround ähnlich wie der Alive-Test aber keine Behebung des eigentlichen Problems das irgendwann keine Nutzdaten durch den Tunnel kommen?

Schöne Grüße

[ua]

Moin,

hatt ein ähnliches Problem, Tunnel stand aber keine DÜ möglich.
Bei mir hat ein IP-Polling geholfen (jeweils auf den LAN-IP der Gegenseite) seit dem keine Ausfälle mehr.
War eine schnelle Lösung, für eine Analyse richte die Zeit nicht und Funktion gibt halbe Punktzahl...

VG

[wissbegieriger]

Ich werde es mal mit dem Polling ausprobieren.
Jedoch werden die Router sporadisch genutzt. Mal stehen sie im Schrank und dann sind sie wieder einen Monat aktiv.
Da macht ein Polling von der "Zentrale" eigentlich keinen Sinn denn die Gegenstelle ist ja oft ausgeschaltet.

Aktuell habe ich (noch ) das Glück Zeit für eine Analyse zu haben jedoch habe ich gerade keine Ansatzpunkte mehr.
Eventuell bekomme ich ja noch in die Richtung ein paar Hilfestellungen

[backslash]

Hi wissbegieriger,

Die DPD-Pakete schaffen es ja auch durch den Tunnel, nur keine Nutzdaten wie beispielsweise ein Ping.
Dies funktioniert erst wieder nach einem Reconnect.

Da liegt offenbar ein Mißverständnis vor... DPD prüft nicht den Tunnel sondern nur die IKE-Instanz - genauer: es wird geprüft ob die Phase-1 SA noch besteht. Die Phase-2 SAs, die für die Nutzdaten genutzt werden, werden vom DPD hingegen nicht geprüft. Da die Phase-2 SAs i.A. deutlich kürzere Lifetimes haben, als die Phase-1 SA, laufend diese also bei bestehender Verbinung ab. Ohne Phase-2-SA ist keine Datenübertragung möglich. Normalerweise sollten die Phase-2-SA automatisch erneuert werden (Re-Keying), aber es gibt immer wieder Router, die damit Probleme haben (z.B. Fritzboxen). Und dann wird zwar DPD beantwortet, es können aber trotzdem keine Daten übertragen werden.

Und genau das kannst du mit einem Polling prüfen und wenn das scheitert, die Verbnindung komplett trennen und wieder neu aufbauen.

Da macht ein Polling von der "Zentrale" eigentlich keinen Sinn denn die Gegenstelle ist ja oft ausgeschaltet.

Das polling läuft nur, wenn die Verbindung aufgebaut ist und daher ist es egal, ob von der Zentrale oder der Fililae gepollt wird. Trotzdem macht man das Polling üblicherweise von der Filiale aus, damit die Zentrale nicht unnötig durch die pings belastet wird - inbesondere, wenn sie hunderte Tunnel terminiert.

Gruß
Backslash

[wissbegieriger]

Hi backslash,

aber es gibt immer wieder Router, die damit Probleme haben (z.B. Fritzboxen). Und dann wird zwar DPD beantwortet, es können aber trotzdem keine Daten übertragen werden.

Die verwendeten System sind alle von Lancom (ISG-4000, 9100+, 7100+, 1781VA-4G, 1790-4G, usw...)

Und genau das kannst du mit einem Polling prüfen und wenn das scheitert, die Verbnindung komplett trennen und wieder neu aufbauen.

Das Polling ist aber quasi nur die Hilfe für die Überprüfung ob der Tunnel funktionell ist.
Es ist eine Abhilfe um einen Fehler in der Phase2 auszumerzen aber nicht zu beheben, oder?
Gibt es eine Möglichkeit (z.B. ein Trace?) zu überprüfen ob der Fehler in der Phase 2 besteht und ob es z.B. am Re-Keying liegt?

Mich wundert das es halt bei einigen Lancom-Routern auftritt und bei anderen nicht. Ich kann es nicht an einem bestimmten Gerätetyp oder Firmware festmachen....

Schöne Grüße

[GrandDixence]

Ob das Rekeying des Steuerkanals des VPN-Tunnels (IKE => Phase-1 SA) korrekt funktioniert, sollte mit einer auf wenige Minuten reduzierte Schlüsselmateriallebensdauer des Steuerkanals (/Setup/VPN/IKEv2/Lebensdauer/IKE-SA-Sec ) kontrolliert werden (wenn der VPN-Tunnel eingerichtet wird).

Ob das Rekeying des Datenkanals des VPN-Tunnels (IPSec/ESP => Phase-2 SA/Child SA) korrekt funktioniert, sollte mit einer auf wenige Minuten reduzierte Schlüsselmateriallebensdauer des Datenkanals (/Setup/VPN/IKEv2/Lebensdauer/Child-SA-Sec ) kontrolliert werden (wenn der VPN-Tunnel eingerichtet wird).

Wenn bereits eine Überwachung des Steuerkanals mit DPD eingerichtet wurde UND das Rekeying des Datenkanals einwandfrei funktioniert, erachte ich eine Überwachung des Datenkanals (mit ICMP-Polling) als überflüssig. Weshalb sollte das Rekeying des Datenkanals plötzlich nicht mehr funktionieren?

Bitte die Release Note der neusten LCOS-Versionen beachten! Ich habe im Kopf, dass in der neusten LCOS-Version ein VPN-Problem bei "Load-Balancing"-Konstellationen behoben wurde.

Allgemein bei Problemen mit Dead Peer Detection (DPD) und ICMP-Polling durch den VPN-Tunnel sollten die Beiträge unter:
fragen-zum-thema-vpn-f14/fast-kein-traf ... 16434.html

fragen-zum-thema-vpn-f14/ikev2-loadbala ... 17345.html

fragen-zum-thema-vpn-f14/windows-10-mit ... 4-s15.html

beachtet werden.

[backslash]

Hi wissbegieriger,

Die verwendeten System sind alle von Lancom (ISG-4000, 9100+, 7100+, 1781VA-4G, 1790-4G, usw...)

das mit der Fritzbox war ein Bei9spiekl. Es kann auch ein einer fehlerhaften Konfiguration liegen.

Wenn z.B. die Netzbeziehungen nicht übergreuz exakt gleich sind und die Lifetimes so sind, daß die SA beim Responder zuerst rausaltert, dann kann es sein, daß der Responder die SA nicht neu ausgehandelt bekommt und du somit auch in das Problem rennst... genauso gut kann das Internet in dem Moment gestört sein, in dem das Rekeying statt findet.

Es ist eine Abhilfe um einen Fehler in der Phase2 auszumerzen aber nicht zu beheben, oder?

wenn du das so sehen willst... Das gleiche könntest du dann auch vom DPD sagen. In einer fehlerfreien Welt braucht man schließlich keine Überwachung...

Mich wundert das es halt bei einigen Lancom-Routern auftritt und bei anderen nicht. Ich kann es nicht an einem bestimmten Gerätetyp oder Firmware festmachen....

Was letztendlich der Grund ist, mußt du schon selbst herausfinden - das deutet aber schon auf Konfiguratuionsprobleme hin...

Gruß
Backslash

[wissbegieriger]

Servus zusammen,

erst einmal vielen Dank für die bisherige Hilfestellungen!

Es ist mal wieder soweit ein Router hat eine VPN-Verbindung aber es kommen keine Daten mehr durch den Tunnel.

Ich habe einen Trace (VPN-Debug, VPN-IKE) laufen lassen. Dieser hat folgendes geliefert:

Code: Alles auswählen

echo "
[VPN-IKE] 2020/06/16 18:20:03,896  Devicetime: 2020/06/16 18:20:04,336
[ROUTER_FERN] Sending packet before encryption:
IKE 2.0 Header:
Source/Port         : 10.111.139.4:4500
Destination/Port    : 10.111.251.95:22771
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x00   
| Msg-ID            : 142
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 30 44 48 4C AF 26 F0 E1 BE 11 66 F5 64 D8 2E EA
| ICV               : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F

[VPN-IKE] 2020/06/16 18:20:03,896  Devicetime: 2020/06/16 18:20:04,336
[ROUTER_FERN] Sending packet after encryption:
IKE 2.0 Header:
Source/Port         : 10.111.139.4:4500
Destination/Port    : 10.111.251.95:22771
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x00   
| Msg-ID            : 142
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 30 44 48 4C AF 26 F0 E1 BE 11 66 F5 64 D8 2E EA
| Encrypted Data    : 7D C0 04 24 D9 31 4D 93 10 35 70 E7 D9 1B 64 29
| ICV               : F0 B4 12 F0 DD E6 B0 B3 E9 F3 E7 49 E4 82 F1 CC

[VPN-Debug] 2020/06/16 18:20:03,896  Devicetime: 2020/06/16 18:20:04,336
Peer ROUTER_FERN: Received a request to establish an exchange for (ISAKMP-PEER-ROUTER_FERN, SEND-DPD)
INFORMATIONAL (37) exchange created:
  ROUTER_FERN, ISAKMP-PEER-ROUTER_FERN, ComChan 51
  SPI 0x9AFD68DB1F35F9DB405C5916DB580167, MSG-ID 0x0000008E, flags 0x00000074
Peer ROUTER_FERN: Constructing an INFORMATIONAL-REQUEST (DPD-REQUEST) for send
Message encrypted successfully
Message authenticated successfully
Non-ESP-Marker Prepended
Sending an INFORMATIONAL-REQUEST (DPD-REQUEST) of 80 bytes (responder encrypted)
Gateways: 10.111.139.4:4500-->10.111.251.95:22771, tag 0 (UDP)
SPIs: 0x9AFD68DB1F35F9DB405C5916DB580167, Message-ID 142
Payloads: ENCR

[VPN-IKE] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,370
[ROUTER_FERN] Received packet:
IKE 2.0 Header:
Source/Port         : 10.111.251.95:22771
Destination/Port    : 10.111.139.4:4500
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x08   Initiator
| Msg-ID            : 154
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 3D 46 D8 3B 0D 5A 63 76 36 46 13 5F 16 13 53 96
| Encrypted Data    : D6 1D 32 F2 14 22 06 9E 6C E3 FD 23 7A 1D D3 4C
| ICV               : 5E 97 BF 23 F3 0A 60 88 A5 EF DA 63 AB D1 A9 52

[VPN-IKE] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,371
[ROUTER_FERN] Received packet after decryption:
IKE 2.0 Header:
Source/Port         : 10.111.251.95:22771
Destination/Port    : 10.111.139.4:4500
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x08   Initiator
| Msg-ID            : 154
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 3D 46 D8 3B 0D 5A 63 76 36 46 13 5F 16 13 53 96
| ICV               : 5E 97 BF 23 F3 0A 60 88 A5 EF DA 63 AB D1 A9 52
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F

[VPN-Debug] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,371
Peer ROUTER_FERN [responder]: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: 10.111.139.4:4500<--10.111.251.95:22771
SPIs: 0x9AFD68DB1F35F9DB405C5916DB580167, Message-ID 154
Payloads: ENCR
QUB-DATA: 10.111.139.4:4500<---10.111.251.95:22771 rtg_tag 0 physical-channel WAN(1) vpn-channel 51
transport: [id: 1139524, UDP (17) {incoming unicast, fixed source address}, dst: 10.111.251.95, tag 0 (U), src: 10.111.139.4, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, iface: WAN_LTN02 (5), mac address: 08:b2:58:14:b6:41, port 0], local port: 4500, remote port: 22771, flags: UDP_ENCAPSULATION
+IKE_SA found and assigned
+Exchange created (flags: 0x00000070)
Message verified successfully
Message decrypted successfully
Payloads: ENCR

[VPN-IKE] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,371
[ROUTER_FERN] Sending packet before encryption:
IKE 2.0 Header:
Source/Port         : 10.111.139.4:4500
Destination/Port    : 10.111.251.95:22771
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x20 Response  
| Msg-ID            : 154
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 2C 1E FF 8B 56 8C D3 75 10 F7 2C 4A B0 78 98 79
| ICV               : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F

[VPN-IKE] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,372
[ROUTER_FERN] Sending packet after encryption:
IKE 2.0 Header:
Source/Port         : 10.111.139.4:4500
Destination/Port    : 10.111.251.95:22771
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x20 Response  
| Msg-ID            : 154
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : 2C 1E FF 8B 56 8C D3 75 10 F7 2C 4A B0 78 98 79
| Encrypted Data    : 0E 09 43 6C 1B A1 50 AC F4 CA D8 BE 72 BD F5 5A
| ICV               : FB 56 0A A0 99 FF 19 35 17 DD 96 B2 30 0D 01 D9

[VPN-Debug] 2020/06/16 18:20:03,911  Devicetime: 2020/06/16 18:20:04,372
Peer ROUTER_FERN: Constructing an INFORMATIONAL-RESPONSE for send
Message encrypted successfully
Message authenticated successfully
Non-ESP-Marker Prepended
IKE_SA(0x9AFD68DB1F35F9DB405C5916DB580167).EXPECTED-MSG-ID raised to 155
+(request, response) pair inserted into retransmission map
Sending an INFORMATIONAL-RESPONSE of 80 bytes (responder encrypted)
Gateways: 10.111.139.4:4500-->10.111.251.95:22771, tag 0 (UDP)
SPIs: 0x9AFD68DB1F35F9DB405C5916DB580167, Message-ID 154
Payloads: ENCR

[VPN-IKE] 2020/06/16 18:20:03,989  Devicetime: 2020/06/16 18:20:04,385
[ROUTER_FERN] Received packet:
IKE 2.0 Header:
Source/Port         : 10.111.251.95:22771
Destination/Port    : 10.111.139.4:4500
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x28 Response  Initiator
| Msg-ID            : 142
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : D4 B0 90 FA 3E DF 94 F4 2A 05 29 6F AF 99 79 2D
| Encrypted Data    : 99 A1 AA AF 1D D4 26 C1 7A EC A1 72 D4 FA 6E D8
| ICV               : 9A 66 9D 3E 77 F0 D5 01 26 68 C6 51 14 6E 39 99

[VPN-IKE] 2020/06/16 18:20:03,989  Devicetime: 2020/06/16 18:20:04,385
[ROUTER_FERN] Received packet after decryption:
IKE 2.0 Header:
Source/Port         : 10.111.251.95:22771
Destination/Port    : 10.111.139.4:4500
Routing-tag         : 0
Com-channel         : 51
| Initiator cookie  : 9A FD 68 DB 1F 35 F9 DB
| Responder cookie  : 40 5C 59 16 DB 58 01 67
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : INFORMATIONAL
| Flags             : 0x28 Response  Initiator
| Msg-ID            : 142
| Length            : 80 Bytes
ENCR Payload
| Next Payload      : NONE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 52 Bytes
| IV                : D4 B0 90 FA 3E DF 94 F4 2A 05 29 6F AF 99 79 2D
| ICV               : 9A 66 9D 3E 77 F0 D5 01 26 68 C6 51 14 6E 39 99
Rest                : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0F

[VPN-Debug] 2020/06/16 18:20:03,989  Devicetime: 2020/06/16 18:20:04,385
Peer ROUTER_FERN [responder]: Received an INFORMATIONAL-RESPONSE of 80 bytes (encrypted)
Gateways: 10.111.139.4:4500<--10.111.251.95:22771
SPIs: 0x9AFD68DB1F35F9DB405C5916DB580167, Message-ID 142
Payloads: ENCR
QUB-DATA: 10.111.139.4:4500<---10.111.251.95:22771 rtg_tag 0 physical-channel WAN(1) vpn-channel 51
transport: [id: 1139524, UDP (17) {incoming unicast, fixed source address}, dst: 10.111.251.95, tag 0 (U), src: 10.111.139.4, hop limit: 64, DSCP: CS6, ECN: Not-ECT, pmtu: 1500, iface: WAN_LTN02 (5), mac address: 08:b2:58:14:b6:41, port 0], local port: 4500, remote port: 22771, flags: UDP_ENCAPSULATION
+IKE_SA found and assigned
Message verified successfully
Message decrypted successfully
Payloads: ENCR

[VPN-Debug] 2020/06/16 18:20:03,989  Devicetime: 2020/06/16 18:20:04,385
IKE_SA(0x9AFD68DB1F35F9DB405C5916DB580167).SEND-MSG-ID raised to 143
Peer ROUTER_FERN: Trigger next pended request to establish an exchange
  Current request is ISAKMP-PEER-ROUTER_FERN
  IKE_SA is not REPLACED
There are 0 pending requests";

Wenn ich den Trace richtig interpretiere funktioniert die VPN-Kommunikation denn es werden diverse Nachrichten zwischen den Geräten getauscht.

Allgemein bei Problemen mit Dead Peer Detection (DPD) und ICMP-Polling durch den VPN-Tunnel sollten die Beiträge...

Ich bin mir gar nicht mehr sicher ob es ein VPN-Problem oder z.B. ein Routing-Problem ist

Gehe ich im LANmonitor auf "Verbindung trennen" wird sofort die Verbindung (Initiator hat 9999) wieder aufgebaut.
Dies kann ja nur sein wenn der Tunnel per Handshake beendet wird ansonsten müsste der Initiator das Tunnelende erst per DPD feststellen was einen Augenblick dauert.

Als Lifetimes verwende ich die von Lancom per Default festgelegten, ich ändere sie, wie von GrandDixence vorgeschlagen auf kurze Werte und schaue was dann passiert.
Es reicht doch dies auf der Seite vom Responder zu machen, oder?

[GrandDixence]

daß die SA beim Responder zuerst rausaltert, dann kann es sein, daß der Responder die SA nicht neu ausgehandelt bekommt und du somit auch in das Problem rennst...

Der VPN-Endpunkt bei welchem zuerst die Schlüsselmateriallebensdauer abläuft, startet die Neuverhandlung des neuen Schlüsselmaterials (Rekeying). Und wenn dies gelegentlich nicht funktioniert, liegt ein Programmierfehler im Programmcode (LCOS) vor, welcher behoben werden sollte. Für ein solches Fehlverhalten ist ICMP-Polling nur Symptombekämpfung und keine Ursachenbekämpfung!

https://www.heise.de/security/artikel/E ... 70056.html

genauso gut kann das Internet in dem Moment gestört sein, in dem das Rekeying statt findet.

Eine Anwendung, die UDP nutzt (=> IKE), muss gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen und ggfs. auch Sicherungsmaßnahmen vorsehen.
https://de.wikipedia.org/wiki/User_Datagram_Protocol

Fehlen diese Sicherungs- und Korrekturmassnahmen im RFC 7296, so muss dies als schwerer "Designfehler" erachtet werden. Gemäss Kapitel "2.1. Use of Retransmission Timers" vom RFC 7296 wurden aber entsprechende Sicherungs- und Korrekturmassnahmen vorgesehen:
https://tools.ietf.org/html/rfc7296
Ob diese Sicherungs- und Korrekturmassnahmen auch korrekt in LCOS implementiert wurden, ist eine andere Frage.

Der Integritätsschutz von IKE (=> GCM) schützt zuverlässig vor verfälschten UDP-Pakete/IKE-Telegramme.

Im Trace sind nur die 4 DPD-Telegramme zu senden (2 IKE-Telegramme pro VPN-Endpunkt: 1x Anfrage, 1x Antwort). Wurde der VPN-Tunnel korrekt konfiguriert, prüft jeder VPN-Endpunkt eigenständig, ob der VPN-Tunnel (präzise: Steuerkanal => IKE) noch "lebt".

Ob der Steuerkanal (IKE) oder der Datenkanal (IPSec/ESP) noch lebt, ist auf der entsprechenden VPN-Statusseite ersichtlich (LCOS-Menübaum/Status/VPN/Irgendetwas). Auf dieser VPN-Statusseite ist auch die aktuelle Schlüsselmateriallebensdauer ersichtlich.

Ich empfehle:

- alle VPN-Endpunkte mit der genau gleichen LCOS-Version zu betreiben.
- alle VPN-Endpunkte auf die aktuellste LCOS-Version zu aktualisieren
- die Konfiguration aller VPN-Endpunkte mit der entsprechenden VPN-Anleitungen unter:
fragen-zum-thema-vpn-f14/vpn-via-androi ... tml#p97795
abzugleichen.
- VPN-Tunnel gemäss den Empfehlungen von BSI TR-02102-3 zu konfigurieren (zum Beispiel: Schlüsselmateriallebensdauer)

Ansonsten läuft man Gefahr, sinnlos Zeit zu verlieren mit einer eigentlich überflüssigen Fehlersuche...

[backslash]

Hi GrandDixence,

Der VPN-Endpunkt bei welchem zuerst die Schlüsselmateriallebensdauer abläuft, startet die Neuverhandlung des neuen Schlüsselmaterials (Rekeying).

das ist beim LANCOM auch so - aber z.B. eine Fritzbox hat damit Probleme, weshalb ich sie als Beispiel nannte...

Und wenn dies gelegentlich nicht funktioniert, liegt ein Programmierfehler im Programmcode (LCOS) vor, welcher behoben werden sollte.

Es muß nicht an Fehlern im LCOS liegen. Das Rekeying kann auch scheitern, wenn die Netzbeziehungen nicht passen, warum ich das ja als Beispiel nannte. In dem Fall funktioniert der Tunnel solange nicht, bis der Initiator selbst das Rekeying anstößt

Und zu deinen anderen Bemerkunen zum Thema Designfehler kann ich nur sagen: Aus der Fehlerbeschreibung des Threadstarters darauf zu schleißen, halte ich für extrem gewagt. Meine Kristallkugel jedenfalls läßt diesen Schluß nicht zu


Gruß
Backslash

[Jirka]

Sehe ich auch so.

[wissbegieriger]

Ob der Steuerkanal (IKE) oder der Datenkanal (IPSec/ESP) noch lebt, ist auf der entsprechenden VPN-Statusseite ersichtlich (LCOS-Menübaum/Status/VPN/Irgendetwas). Auf dieser VPN-Statusseite ist auch die aktuelle Schlüsselmateriallebensdauer ersichtlich.

Gerade habe ich wieder den Fall, der Tunnel lief einige Zeit und nun ist keine Übertragung möglich.
Unter Status/VPN/IKE sehe ich einen Eintrag zur der Gegenstelle und er altert auch.
Unter Status/VPN/ESP sehe ich zwei Einträge zur Gegenstelle welche auch altern.

Dies bedeutet doch das eigentlich alles in Ordnung ist, oder?

- VPN-Tunnel gemäss den Empfehlungen von BSI TR-02102-3 zu konfigurieren (zum Beispiel: Schlüsselmateriallebensdauer)

Zu der Lebensdauer finde ich keinen Hinweis in der TR. Dort wird auf die RFC7296 verwiesen in der ich aber auch keine Zeitangaben finde.
Übersehe ich die Stellen? Welche Zeiten empfehlt ihr?

Schöne Grüße

[GrandDixence]

Dies bedeutet doch das eigentlich alles in Ordnung ist, oder?

Ohne ein Screenshot und Angaben zum realisierten VPN-Tunnel nicht beurteilbar. Einfach weiter beobachten, bis man das Prinzip verstanden hat.

Mit dem VPN-Trace VPN_Debug nachsehen, weshalb die zu übertragenden IP-Pakete (z.B. Ping) nicht durch den VPN-Tunnel übertragen werden.

Zu der Lebensdauer finde ich keinen Hinweis in der TR. Übersehe ich die Stellen?

Kapitel 3.4 vom BSI TR-02102-3 beachten.