Port Switch bei bestehender VPN Verbindung

[EFT]

Hallo Zusammen,

habe mitbekommen, dass es in der Vergangenheit schon häufiger Probleme bei einer Konstellation von direkter VPN Verbindung, ohne Zwsischenstation, zwischen LANCOM Router und Cisco Meraki Produkten gibt. Ein konkretes Beispiel wäre ein Tunnel, bei dem der Verbindungsaufbau über Port 500 initiiert wird und anschließend nach einem AUTH-Request seitens LANCOM, die Antwort von Meraki wiederum über den Port 4500 gesendet wird. Hiernach ist der Tunnel dann zerstört. Dieser Port Switch ist nicht nachvollziehbar und die Authentifizierungseinstellungen komplett identisch.
Hatte jemand schon ähnliche Erfahrungen, oder weis ggf. was bei Meraki gefixt wurde, damit es nicht mehr zu diesem Switch kommt?

[Schabensen]

Vielleicht hilft hier dies:
https://documentation.meraki.com/MX/Sit ... raki_Peers

[GrandDixence]

Für eine herstellerunabhängige und zukunftssichere VPN-Tunnellösung ist IKEv2/IPSec einzusetzen.
https://community.swisscom.ch/t5/Intern ... 476#M71728

IKEv2/IPSec verwendet für den VPN-Tunnelaufbau immer die Serverports:

UDP Port 500 und UDP Port 4500

für den Steuerkanal (IKE).

Details zum VPN-Tunnelaufbau mit IKEv2/IPSec:
https://www.heise.de/hintergrund/Einfac ... 70056.html

Seite 4 vom Heise-Artikel vereinfacht:

Bei IKEv2/IPSec wird ein Steuerkanal (IKE) und ein Datenkanal verwendet (IPSec/ESP). Der Steuerkanal dient dem VPN-Tunnelaufbau, zyklischen Schlüsselmaterialwechseln, Lebenstaktüberwachung (DPD -> Dead Peer Detection) und dem VPN-Tunnelabbau (IKE_DELETE). Durch den Datenkanal gehen alle Nutzdaten.

Ohne NAT-Komponente zwischen den beiden VPN-Endpunkte werden reine IP-Datenpakete in einer Spezialform (ESP) für den Datenkanal verwendet. Mit einer oder mehreren NAT-Komponente(n) zwischen den beiden VPN-Endpunkte kommt NAT-Traversal zum Einsatz. Dann wird der Datenkanal über den Serverport UDP 4500 abgewickelt.

Beim VPN-Tunnelaufbau werden 4 IKE-Telegramme benötigt. Grob gesagt, wird mit dem 1. und 2. IKE-Telegramm die Verschlüsselung des Steuerkanals zwischen den VPN-Endpunkten ausgehandelt (IKE SA_INIT). Mit dem IKE-Telegramm Nummer 3 und 4 erfolgt die Authentifizierung und die Aushandlung der Verschlüsselung vom Datenkanal (IKE_AUTH).

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

Falls hier weiter Hilfestellung erwünscht ist, ist mindestens der IKE-Trace zu veröffentlichen.

Häufigste Problemursache nach dem erfolgreichen VPN-Tunnelaufbau ist die fehlgeschlagene, zyklische Schlüsselmaterialaushandlung (Rekeying) für den Datenkanal. Siehe dazu:

fragen-zum-thema-vpn-f14/ikev2-dpd-nach ... ml#p114074

fragen-zum-thema-vpn-f14/vpn-netzbezieh ... ml#p114394

[EFT]

Hallo Zusammen,

danke erstmal für die schnellen und qualifizierten Antworten. Bin bisher davon ausgegangen, dass Port 4500 und 500 nur dann bespielt werden, wenn es ein NAT festgestellt wird. Deshalb erschien mir auch folgender Auszug aus dem Trace komisch (siehe screenshots). Hier steht der Tunnel schon via 4500 und anschließend kommt dann nochmal ein Init via 500 und ab da ist der Tunnel dann weg.

Screenshot1.png

screenshot2.png

[backslash]

Hi EFT,

das ist abert kein Portswitch, das sind 2 verschiedene Verbindungen von denen Erste an Port 4500 geht und die Zweite an Port 500- zu erkennen an den unterschiedlichen SPIs 0x8411... bzw. 0xcc9d...
Wenn die jetzt beide von der gleiche IP-Adresse kommen und in der Zweiten etwas von "initial contact" steht, dann killt eben diese "initial contact" Notification die erste Verbindung...

leider ist das nicht zu erkennen, weil es im Screenshot nur einen Teil des Pakets zeigt - daher: wenn man Traces einstellt, dann diese in einer

Code: Alles auswählen

...

Umgebung vollständig als Text einfügen und nicht als Screeshot.

versucht da Meraki besonders schlau zu sein und schießt sich damit selbst ins Knie?

Gruß
Backslash

[EFT]

Hallo Zusammen,

anbei ist ein Auszug des Trace als Datei. Sollte soweit alles wichtige anonymisiert sein.

[backslash]

Hi EFT

bis hier lebt die erste Session noch:

Code: Alles auswählen

[VPN-Status] 2024/09/26 19:47:48,863
Peer IKEV2_Verbindung_IKEV2 [responder]: Received an INFORMATIONAL-REQUEST of 80 bytes (encrypted)
Gateways: EIGENE_ÖFFENTLICHE_IP_ADRESSE:4500<--VPN_GEGENSTELLE:4500
SPIs: 0x8411321AZ2ADA4F1A612FW29BAA6E96, Message-ID 100
DPD-REQUEST

dann kommt eine neue rein:

Code: Alles auswählen

[VPN-Status] 2024/09/26 19:48:02,961
Peer IKEV2_Verbindung_IKEV2: Received an IKE_SA_INIT-REQUEST of 464 bytes
Gateways: EIGENE_ÖFFENTLICHE_IP_ADRESSE:500<--VPN_GEGENSTELLE:500
SPIs: 0xCC9D0EF002E8CF0B0000000000000000, Message-ID 0
Peer identified: IKEV2_Verbindung_IKEV2
IKE_SA ('', '' IPSEC_IKE SPIs 0xCC9D0EF002E8CF0B35330CF6A3D98ABC) entered to SADB
Received 5 notifications: 
  +NAT_DETECTION_SOURCE_IP(0XD1B19156222F75F0D022CCC92D5C5EE8093F659B) (STATUS)
  +NAT_DETECTION_DESTINATION_IP(0x70X)CC62EFE8DE78W24C79693BDF6631F8658216) (STATUS)
  +IKEV2_FRAGMENTATION_SUPPORTED (STATUS)
  +SIGNATURE_HASH_ALGORITHMS(0x0002000300040005) (STATUS)
  +REDIRECT_SUPPORTED (STATUS)
Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled
+IKE-SA:
  IKE-Proposal-1  (4 transforms)
    ENCR : AES-CBC-256
    PRF  : PRF-HMAC-SHA-256
    INTEG: HMAC-SHA-256
    DH   : 14
+Received KE-DH-Group 14 (2048 bits)

und irgendwann kommt dann das Paket mit dem "initial contact":

Code: Alles auswählen

[VPN-IKE] 2024/09/26 19:48:03,026
[IKEV2_Verbindung_IKEV2] Received packet after decryption:
IKE 2.0 Header:
Source/Port         : VPN_GEGENSTELLE:4500
Destination/Port    : EIGENE_ÖFFENTLICHE_IP_ADRESSE:4500
Routing-tag         : 0
Com-channel         : 396
| Initiator cookie  : CC 9D 0E F0 02 E8 CF 0B
| Responder cookie  : 35 33 0C F6 A3 D9 8A BC
| Next Payload      : ENCR
| Version           : 2.0
| Exchange type     : IKE_AUTH
| Flags             : 0x08   Initiator
| Msg-ID            : 1
| Length            : 352 Bytes
ENCR Payload
| Next Payload      : IDI
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 324 Bytes
| IV                : 68 X) E0 1C 0B 00 AD 32 E2 8E E4 33 DA F1 D0 8B
| ICV               : 99 85 A1 6C 24 63 39 A3 FE 8A 29 5B 52 4B DC 43
IDI Payload
| Next Payload      : NOTIFY
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 12 Bytes
| ID type           : IPV4_ADDR
| Reserved          : 0x000000
| ID                : VPN_GEGENSTELLE
NOTIFY Payload
| Next Payload      : IDR
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 8 Bytes
| Protocol ID       : <Unknown 0>
| SPI size          : 0
| Message type      : STATUS_INITIAL_CONTACT

(...)

und genau das führt dann dazu, daß die alten SAs abgebaut werden:

Code: Alles auswählen

[VPN-Status] 2024/09/26 19:48:03,029
Peer IKEV2_Verbindung_IKEV2 [responder]: Received an IKE_AUTH-REQUEST of 352 bytes (encrypted)
Gateways: EIGENE_ÖFFENTLICHE_IP_ADRESSE:500<--VPN_GEGENSTELLE:500
SPIs: 0xCC9D0EF002E8CF0B35330CF6A3D98ABC, Message-ID 1
CHILD_SA ('', '' ) entered to SADB
Switching to local port 4500 and remote port 4500
Received 5 notifications: 
  +INITIAL_CONTACT (STATUS)
  +MOBIKE_SUPPORTED (STATUS)
  +ADDITIONAL_IP4_ADDRESS(0x50957766) (STATUS)
  +EAP_ONLY_AUTHENTICATION (STATUS)
  +MESSAGE_ID_SYNC_SUPPORTED (STATUS)
+Received-ID  VPN_GEGENSTELLE:IPV4_ADDR matches the Expected-ID VPN_GEGENSTELLE:IPV4_ADDR
+Peer identified: IKEV2_Verbindung_IKEV2
+Peer uses AUTH(PSK)
+Authentication successful
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0x6231CE4D27F2C5FE5577BD18409A61CA) removed from SADB
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0x6231CE4D27F2C5FE5577BD18409A61CA) freed
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0x8411321AZ2ADA4F1A612FW29BAA6E96) removed from SADB
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0x8411321AZ2ADA4F1A612FW29BAA6E96) freed
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0xCC9D0EF002E8CF0B35330CF6A3D98ABC) removed from SADB
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-1-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xC6862307 Inbound-SPI 0x7D016BAD) removed from SADB
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-1-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xC6862307 Inbound-SPI 0x7D016BAD) freed
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-2-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xC7047303 Inbound-SPI 0xB33C71Z2) removed from SADB
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-2-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xC7047303 Inbound-SPI 0xB33C71Z2) freed
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-0-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xCA996446 Inbound-SPI 0x82D874B5) removed from SADB
CHILD_SA ('IKEV2_Verbindung_IKEV2', 'IPSEC-0-IKEV2_Verbindung_IKEV2-PR0-L0-R0' IPSEC_ESP Outbound-SPI 0xCA996446 Inbound-SPI 0x82D874B5) freed
IKE_SA ('IKEV2_Verbindung_IKEV2', 'ISAKMP-PEER-IKEV2_Verbindung_IKEV2' IPSEC_IKE SPIs 0xCC9D0EF002E8CF0B35330CF6A3D98ABC) entered to SADB
TSi: (  0,     0-65535,     LOKALE_IP_VPN_GEGENSTELLE-LOKALE_IP_VPN_GEGENSTELLE  )
TSr: (  0,     0-65535,        LOKALE_IP-LOKALE_IP     )
+CHILD-SA:
  ESP-Proposal-1 Peer-SPI: 0xC4694A22 (3 transforms)
    ENCR : AES-CBC-256
    INTEG: HMAC-SHA-256
    ESN  : NONE

warum die Gegenseite das "initial contact" sendet, mußt du dort ergründen...


Gruß
Backslash

[backslash]

Hi EFT,

ich vermute mal, das ist ein Rekeying, das so richtig schief läuft..

Gruß
Backslash

[EFT]

Vielen Dank, für die Unterstützung!

[EFT]

Kleiner Nachtrag zu dem Thema:

hier konnte noch nicht festgestellt werden, wieso der INITIAL_CONTACT bei bestehender Verbindung kommt, aber es gibt eine andere Interessante Info seitens dem CISCO-Meraki:

,,..When Meraki initiates the negotiation and passes the IKE-AUTH packets, it expects to receive ESP packets without UDP encapsulation..."
,,...the response with UDP encapsulation causes Meraki to ignore these packets..."
,,...it seems at there is a compatibility issue, as different vendors implement IPSec differently"

Dachte hier gibt es einen geräteübergreifenden Standard, an den sich gehalten wird?

[GrandDixence]

Dachte hier gibt es einen geräteübergreifenden Standard, an den sich gehalten wird?

RFC 7296 ist die "Spezifikation/Standard" vom Protokoll IKEv2:
https://www.rfc-editor.org/info/rfc7296

Offensichtlich ist der Meraki nicht konform zur RFC 7296. Somit ist man selber schuld, wenn man für einen VPN-Tunnel mit IKEv2/IPSec einen VPN-Endpunkt einsetzt, welcher nicht konform zu RFC 7296 ist.

Der LANCOM-Router mit dem Betriebssystem LCOS erlaubt den Betrieb von einwandfreien VPN-Tunnels per IKEv2/IPSec mit einem VPN-Endpunkt realisiert mit der Software StrongSwan. StrongSwan unterstützt RFC 7296:
https://wiki.strongswan.org/projects/st ... Standards/

Im LCOS-Referenzhandbuch kann ich im Kapitel "IKEv2" nachlesen, dass LCOS VPN-Tunnels mit IKEv2/IPSec konform zu RFC 7296 unterstützt:
https://www.lancom-systems.de/docs/LCOS ... asics.html

Bei der Verwendung von IKEv2 werden RFC 7296, RFC 7427 und im IKEv2-Client-Betrieb RFC 5685 unterstützt.

Ich lese zum Beispiel im Kapitel 2.11 vom RFC 7296:

IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
AH associations for the same IP addresses over which it runs. The IP
addresses and ports in the outer header are, however, not themselves
cryptographically protected, and IKE is designed to work even through
Network Address Translation (NAT) boxes. An implementation MUST
accept incoming requests even if the source port is not 500 or 4500,
and MUST respond to the address and port from which the request was
received. It MUST specify the address and port at which the request
was received as the source address and port in the response. IKE
functions identically over IPv4 or IPv6.

und im Kapitel 2.23 vom RFC 7296:

Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec
endpoint that discovers a NAT between it and its correspondent (as
described below) MUST send all subsequent traffic from port 4500,
which NATs should not treat specially (as they might with port 500).

An initiator can use port 4500 for both IKE and ESP, regardless of
whether or not there is a NAT, even at the beginning of IKE. When
either side is using port 4500, sending ESP with UDP encapsulation is
not required, but understanding received UDP-encapsulated ESP packets
is required. UDP encapsulation MUST NOT be done on port 500. If
Network Address Translation Traversal (NAT-T) is supported (that is,
if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
all devices MUST be able to receive and process both UDP-encapsulated
ESP and non-UDP-encapsulated ESP packets at any time. Either side
can decide whether or not to use UDP encapsulation for ESP
irrespective of the choice made by the other side. However, if a NAT
is detected, both devices MUST use UDP encapsulation for ESP.

Und wenn ich im VPN-Status-Trace lese:

Peer (initiator) is not behind a NAT. NAT-T is disabled
We (responder) are not behind a NAT. NAT-T is disabled

Dann erwarte ich einen VPN-Tunnel, dessen Datenkanal (IPSec) mit ESP realisiert wird (IP-Pakete Nr. 50) und der Steuerkanal (IKEv2) wird über Serverport UDP 500->4500 realisiert.
https://de.wikipedia.org/wiki/IPsec#Enc ... load_(ESP)