VPN Lancom <-> MacOS Sonoma 14.4.1 (integrierter VPN Client)

[AS1306]

@All, da ich es mir aktuell einfach nicht erklären kann mal eine Frage in die Runde. Ich nutze seit geraumer Zeit die Anbindung unserer Apple Geräte an das interne LAN via VPN mittels Nutzung des integrierten Apple VPN Clients (IKEv2). Dies funktioniert sehr zuverlässig und stabil. Bisher. Diverse Air M1 und MPro laufen tadellos mit Sonoma 14.2 - habe am Freitag dann ein Air M3 mit 14.4.1 anbinden wollen. Fehlanzeige. Bekomme einfach keine Verbindung etabliert. Da ich das schon zigmal konfiguriert habe, bin ich langsam verzweifelt. Hat sich mit dieser Version etwas verändert? Habe gerade das MPro mit M1 Chip auf 14.4.1 gehieft ... und es geht mit allen Profilen, die ich angelegt habe. So auch mit dem für das neue Air M3 ... ???

Die Standardkonfiguration ist gemäß Anleitung https://www.johnlose.de/wp-content/uplo ... gebase.pdf - ohne die PFS Deaktivierung realisiert. Das 8 Minuten "Problem" kenne ich nicht, zumindest hier nie aufgetreten. Binde ich hingegen iOS Geräte an, so muss ein Profil für die PFS Deaktivierung hinterlegt sein! (Anleitung: https://knowledgebase.lancom-systems.de ... El+Capitan)

Da doch so manche Updates zwischenzeitlich auf dem Lancom landeten, frag ich mich, ob es da einen Zusammenhang gibt. Zumindest musste hier eine Anpassung im Bereich des lokalen dig. Signatur Profils (Stichwort: DEFAULT-ECDSA) erfolgen. Anyway, bin für jeden Tip dankbar ... irgendwie seh ich wahrscheinlich den Wald vor Bäumen nicht.

Grüße aus Berlin

HKP1793VA-W D2024-04-01 T111037.txt

[Dr.Einstein]

Geh mal testweise auf DH14 runter. Soweit ich mich erinnere, hat sich Lancom in der Vergangenheit schwer damit getan, zwischen Phase 1 und Phase 2 unterschiedliche DH-Gruppen zu verarbeiten. Das merkt man auch, wenn das PFS Verfahren gewählt wird, und bei Verlängerung eine andere DH Gruppe zum Einsatz kommt (macht Cisco gerne). Sieht man auch schön daran, dass Lancom anders als andere Hersteller hierbei gar nicht zwischen P1 und P2 unterscheiden.

Phase 1 Mac:

AES-GCM-16
PRF-HMAC-SHA-256
256-BIT RANDOM ECP (DH Group 19)

AES-GCM-16
PRF-HMAC-SHA-256
2048-BIT MODP (DH Group 14)

Phase 2 Mac:

AES-CBC-256
HMAC-SHA-256, HMAC-SHA1
2048-BIT MODP (DH Group 14)

Ein Versuch schadet denke ich nicht.

[AS1306]

@Einstein, danke für´s Feedback! Habe mal unter Verschlüsselung alles jenseits DH14 deaktiviert ... wenn das mit auf DH14 runtergehen gemeint war. Leider das gleiche Verhalten. Zumal der Trace auf den 1. Blick gleich aussieht ... Ich bin verwirrt.

So sah es dann aus: https://www.lancom-systems.de/docs/LCOS ... ption.html … der Trace aber nahezu identisch, was heißt, dass wieder DH Group 19 aufgerufen / angefragt wurde. Kann man den Trace diesbezüglich noch fein tunen? Ich habe jetzt einen Trace mit dem Mac der funktioniert und einen vom M3 wo es nicht geht … sehen für mich gleich aus, was die Struktur betrifft.

[Dr.Einstein]

Welchen Eintrag hast du geändert? Die Default Verschlüsselung oder die von deinem Client. Denk dran, am Anfang kann ein Client mit 0.0.0.0 nicht zugeordnet werden sodass der DEFAULT Eintrag greift.

[AS1306]

Den Defaulteintrag im Lancom … alle Häkchen raus bis auf DH14 wie im Bild zu sehen unter dem angegebenen Link. Im integrierten Client (Mac Air M3) sehe ich da nirgends eine Option das beeinflussen zu können.

[Dr.Einstein]

Dann muss aber der Payload beim Aushandeln komplett anders sein. Der Client fragt ja mit DH19 an, und schickt dafür sogar die entsprechenden Zufallszahlen:

Code: Alles auswählen

KE Payload
| Next Payload      : NONCE
| CRITICAL          : NO
| Reserved          : 0x00
| Length            : 72 Bytes
| DH Group          : 19
| Reserved2         : 0x0000
| DH-Key(512 bits)  : 13 CE D1 38 A7 6D F3 3A E5 1B 0B D2 E9 10 7B C2
|                     87 E8 47 FB 3C 57 F3 B2 9A 88 DC 0B D5 42 82 04
|                     5F 1C 81 FC FF 98 31 16 9A 95 8A 4B 64 77 73 4F
|                     41 46 E9 21 73 32 A2 79 67 CA 6E AD 43 8E 07 7A

Wenn du nur 14 akzeptierst, muss der Client neu aushandeln und dir danach eine Zufallszahl auf Basis DH14 schicken. Aber gut, schade, dass es das nicht wahr. Hatte ich wie gesagt schon ein paar Mal als Fehler. Irgendwas gefällt dem Client nicht, immerhin sagt der Lancom ja, die Verbindung steht.

[AS1306]

Yep, das ist es ja was mich auch irritiert. Gleiche Konfiguration auf anderen Rechner funktioniert ja. Ich denke daher nicht, dass es der Lancom ist. Nur was dem Client hier nicht schmeckt ist mir ein Rätsel. Habe jetzt auch diverse andere Profile versucht. Überall geht es, nur nicht auf diesem Gerät … … das war immer DAS Kriterium für mich.

[Dr.Einstein]

Poste mal gleiches Profil, unterschiedliche Clients, gleiche Trace wie vorher, dass man den Sachverhalt nebeneinander stellen kann.

[AS1306]

... mal die beiden "Anmeldungen" im Vergleich ... und zur Vervollständigung auch der ganze Trace als TXT File. Die IP 80.187.85.18 stammt aus dem Mobilfunknetz (mobiler Router) und ist temporär, die anderen sind alle feste IP´s, daher auch "gewandelt".

Grüße aus Charlottenburg

HKP1793VA-W D2024-04-01 T111037.txt

MacPro_14.4.1-WellWorking.txt

MacAM3_14.4.1-NotWorking.txt

[Dr.Einstein]

Ich würde bei FQDN / FQUN aufpassen. Du verwendest

MacBookA_01@home.de:USER_FQDN

Das Format ist eine Email-Adresse, du oder der Client wählt aber FQDN aus. Gerade Android hat da automatische Logik drin ob der String ein @ oder ein . enthält. Gleich das mal ein wenig an, vllt. macht der Client in der neuen Version hier komische Sachen ...

[AS1306]

Hi Einstein, ja da ist etwas echt merkwürdig. Ich verwende IMMER FQUN ... merkwürdig ist jetzt, dass ich beim Verbindungsaufbau beim MAC einfach mal da in den Anmeldeeinstellungen die TLD .de entfernte und plötzlich wurde die Leitung grün. Im LAN-Monitor mal geschaut. Keine VPN Verbindung etabliert. Dann mittels Terminal mal versucht einen PING abzusetzen ... Leitung war weg (zusammengebrochen). Erneute Verbindung schlug fehl mit diesen Einstellungen, also wieder TLD hinzugefügt um daraus ein FQUN zu machen, so wie es ja auch im Lancom hinterlegt ist. Verbindung wird grün ... PING ... Leitung wieder weg. Ich denke, dass der Client im MAC ein Ding weg hat und irgendeinen BUG fährt. Blöderweise kann man da ja nicht viel einstellen. Werde mal Kontakt mit Apple aufnehmen. Mir fällt sonst einfach nichts mehr ein

Grüße aus Charlottenburg

[GrandDixence]

Im MacPro_14.4.1-WellWorking.txt ist der Fehlerfall nicht ersichtlich, weil die Trace-Ausgaben zu früh abgebrochen wurden. Weder finde ich eine VPN-Debug-Trace-Ausgabe, wo der VPN-Server vom LANCOM-Router den Abbruch des VPN-Tunnelaufbaus begründet, noch sehe ich ein IKE_DELETE-Telegramm vom VPN-Client.