1783VAW, VPN IKEV2 und Android 12

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

Hi,

auch wenn es hier schon einige Anleitungen gibt - ich bekomme es nicht wirklich hin - vielleicht kann mir ja einer von euch weiterhelfen

Lancom 1783VAW, 10.50.1050RU9 - Android Phone (Android 12, Update vom 05.11.22 drauf)

Installiert: strongswan VPN ( Stand von heute)

Lancom:
lancom_VPN.jpg
strongswan:
IKEv2 EAP

Benutzername: phone
PW: Passwort

Log strongswan:
Dec 20 11:42:31 09[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CPRQ(ADDR ADDR6 DNS DNS6) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Dec 20 11:42:31 09[NET] sending packet: from x.x.x.x[37934] to x.x.x.x[4500] (432 bytes)
Dec 20 11:42:31 05[NET] received packet: from x.x.x.x[4500] to x.x.x.x[37934] (80 bytes)
Dec 20 11:42:31 05[ENC] parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
Dec 20 11:42:31 05[IKE] received AUTHENTICATION_FAILED notify error

Trace Lancom:
[VPN-Debug] 2022/12/20 13:39:00,873 Devicetime: 2022/12/20 13:39:00,691
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 2970 bytes
Gateways: x.x.x.x:4500<--x.x.x.x:4500
SPIs: 0x9A244967D1FA69B95D996612F0ABE3A2, Message-ID 1
Payloads: IDI, NOTIFY(INITIAL_CONTACT), CERTREQ, CP(REQUEST), NOTIFY(ESP_TFC_PADDING_NOT_SUPPORTED), SA, TSI, TSR, NOTIFY(MOBIKE_SUPPORTED), NOTIFY(NO_ADDITIONAL_ADDRESSES), NOTIFY(EAP_ONLY_AUTHENTICATION), NOTIFY(MESSAGE_ID_SYNC_SUPPORTED)
+IKE_SA found and assigned
+Exchange created (flags: 0x00000054)
(IKEv2-Exchange 'DEFAULT', 'ISAKMP-PEER-DEFAULT' 0x9A244967D1FA69B95D996612F0ABE3A200000001, P2, RESPONDER): Setting Negotiation SA
Referencing (CHILD_SA, 0x9A244967D1FA69B95D996612F0ABE3A20000000100, responder): use_count 3

[VPN-Status] 2022/12/20 13:39:00,873 Devicetime: 2022/12/20 13:39:00,691
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 2970 bytes
Gateways: x.x.x.x:4500<--x.x.x.x:4500
SPIs: 0x9A244967D1FA69B95D996612F0ABE3A2, Message-ID 1
CHILD_SA ('', '' ) entered to SADB
Updating remote port to 15623
Received 6 notifications:
+INITIAL_CONTACT (STATUS)
+ESP_TFC_PADDING_NOT_SUPPORTED (STATUS)
+MOBIKE_SUPPORTED (STATUS)
+NO_ADDITIONAL_ADDRESSES (STATUS)
+EAP_ONLY_AUTHENTICATION (STATUS)
+MESSAGE_ID_SYNC_SUPPORTED (STATUS)
+EAP-Authentication detected
EAP-License missing (see /Status/Software-Info/EAP-License)

[VPN-IKE] 2022/12/20 13:39:00,873 Devicetime: 2022/12/20 13:39:00,692
[DEFAULT] Sending packet before encryption:
IKE 2.0 Header:
Source/Port : x.x.x.x:4500
Destination/Port : x.x.x.x:15623
Routing-tag : 0
Com-channel : 0
| Initiator cookie : 9A 24 49 67 D1 FA 69 B9
| Responder cookie : 5D 99 66 12 F0 AB E3 A2
| Next Payload : ENCR
| Version : 2.0
| Exchange type : IKE_AUTH
| Flags : 0x20 Response
| Msg-ID : 1
| Length : 80 Bytes
ENCR Payload
| Next Payload : NOTIFY
| CRITICAL : NO
| Reserved : 0x00
| Length : 52 Bytes
| IV : 05 BE A8 7C E5 4D D2 4E 46 06 44 F5 0B 94 BC 10
| ICV : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
NOTIFY Payload
| Next Payload : NONE
| CRITICAL : NO
| Reserved : 0x00
| Length : 8 Bytes
| Protocol ID : IPSEC_IKE
| SPI size : 0
| Message type : AUTHENTICATION_FAILED
Rest : 00 00 00 00 00 00 00 07


strongswan Support sagt, es liegt möglicherweise an der Art der Authentisierung, der Router erwartet ggfs. etwas anderes als EAP ?

Ich habe auch schon versuchsweise "entfernte Authentifizierung" auf EAP umgestellt - auch kein Erfolg ?!?

weiß hier irgendjemand woran das liegen könnte ?
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von Dr.Einstein »

Lancom selbst kann kein IKEv2 EAP. Lancom kann IKEv2 PSK und IKEv2 Cert.

https://www.lancom-systems.de/docs/LCOS ... orial.html
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

OK - und wie kann ich das dann realisieren - möglichst OHNE Zertifikate ? (kann den Zertifikatsserver nicht aktivieren im Lancom) - da fehlt anscheinend die VPN25-Option

Gibt es eine Möglichkeit strongswan mit PSK zu realisieren ?

Oder irgendeine Möglichkeit eine Anbindung mit PSK an den Lancom zu realisieren ?
mh1
Beiträge: 47
Registriert: 24 Feb 2022, 11:17

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von mh1 »

protec hat geschrieben: 20 Dez 2022, 14:19 Gibt es eine Möglichkeit strongswan mit PSK zu realisieren ?
Der Android Client von Strongswan unterstützt kein PSK.
protec hat geschrieben: 20 Dez 2022, 14:19 Oder irgendeine Möglichkeit eine Anbindung mit PSK an den Lancom zu realisieren ?
Strongswan auf einem anderen Betriebssystem?
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

hilft mir leider nicht wirklich - ich möchte das Mobiltelefon mit Andoid 12 mit dem Firmennetz verbinden um Exchange Active Sync machen zu können (halt nur über VPN)

OK - d.h. für den Lancom 1783 brauche ich mind. die VPN-25 Option um die Zertifizierungsstelle zu aktivieren oder ?

Dann könnte ich auch Zertifikate ausstellen und die Anbindung über Zertifikate realisieren ?
mh1
Beiträge: 47
Registriert: 24 Feb 2022, 11:17

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von mh1 »

protec hat geschrieben: 21 Dez 2022, 12:56 OK - d.h. für den Lancom 1783 brauche ich mind. die VPN-25 Option um die Zertifizierungsstelle zu aktivieren oder ?
Genau. Wenn du die CA im Lancom benutzen willst, brauchst du die kostenpflichtige VPN Option.
protec hat geschrieben: 21 Dez 2022, 12:56 Dann könnte ich auch Zertifikate ausstellen und die Anbindung über Zertifikate realisieren ?
Wenn es dir in erster Linie nur um das Zertifikate Ausstellen geht, könntest du dir die VPN-Option aber auch sparen und dir eine eigene CA basteln (z.b. mit OpenSSL) und diese Zertifikate dann in den Lancom importieren.

Manche benutzen auch das Programm XCA. Und die meisten Firmen haben ja sowieso irgendwo einen Windows Server, der eine Zertifizierungsstelle mitbringt....
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

eigene CA haben wir schon auch in der Windowsumgebung - allerdings habe ich jetzt (bekommen wir als Partner vergünstigt) die VPN-25 Lizenz beantragt.
Insofern möchte ich das dann schon gerne über den Lancom machen - ich habe schon gesehen, dass es hier einige Anleitungen gibt. Ich versuche es dann mal mit den vorhandenen Anleitungen, sobald wir die Lizenz freigeschaltet haben, lasse aber den Thread hier mal noch solange offen.

Einstweilen schon mal vielen Dank !
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

so - bin ein bisschen weiter gekommen - VPN-25 Option ist auf dem Router aktiviert,
Zertifikate sind lt. Anleitung unter https://uwe-kernchen.de/phpmyfaq/index. ... &artlang=de eingerichtet und installiert-
VPN-Verbindung ist eingerichtet (ebenfalls lt. der Anleitung) https://uwe-kernchen.de/phpmyfaq/index. ... on_id=1398

Trace sagt folgendes:
[VPN-Status] 2023/01/02 16:40:12,543 Devicetime: 2023/01/02 16:40:12,127
Peer DEFAULT: Received an IKE_SA_INIT-REQUEST of 716 bytes
Gateways: xx.xx.xx.xx:500<--xx.xx.xx.xx:41192
SPIs: 0x943738F6571575D50000000000000000, Message-ID 0
Peer identified: DEFAULT
IKE_SA ('', '' IPSEC_IKE SPIs 0x943738F6571575D5D3C55B3540147BEB) entered to SADB
Received 5 notifications:
+NAT_DETECTION_SOURCE_IP(0xCD212FC8589E03018BCA08573D039DFE8D33AF43) (STATUS)
+NAT_DETECTION_DESTINATION_IP(0xC5A88E6950406171A8C77DDA93F5EB1C30C7F332) (STATUS)
+IKEV2_FRAGMENTATION_SUPPORTED (STATUS)
+SIGNATURE_HASH_ALGORITHMS(0x0002000300040005) (STATUS)
+REDIRECT_SUPPORTED (STATUS)
Peer (initiator) is behind a NAT
NAT-T enabled => switching on port 4500
We (responder) are not behind a NAT. NAT-T is already enabled
+IKE-SA:
IKE-Proposal-1 (26 transforms)
ENCR : AES-CBC-128 AES-CBC-192 AES-CBC-256 3DES
PRF : PRF-HMAC-SHA-256 PRF-HMAC-SHA-384 PRF-HMAC-SHA-512 PRF-AES128-XCBC PRF-HMAC-SHA1
INTEG: HMAC-SHA-256 HMAC-SHA-384 HMAC-SHA-512 HMAC-SHA1 AES-XCBC-96
DH : 19 20 21 28 29 30 31 15 16 17 18 14
IKE-Proposal-2 (27 transforms)
ENCR : AES-GCM-16-128 AES-GCM-16-192 AES-GCM-16-256 ENCR-CHACHA20-POLY1305 AES-GCM-12 AES-GCM-12 AES-GCM-12 AES-GCM-8 AES-GCM-8 AES-GCM-8
PRF : PRF-HMAC-SHA-256 PRF-HMAC-SHA-384 PRF-HMAC-SHA-512 PRF-AES128-XCBC PRF-HMAC-SHA1
DH : 19 20 21 28 29 30 31 15 16 17 18 14
-Agreed on DH-Group 16 but received KE-DH-Group 19 => responding with INVALID_KE_PAYLOAD(16)


Lanmonitor sagt folgendes
Kein übereinstimmendes Proposal gefunden (Passiver Verbindungsaufbau, IKE) [0x2203]

kann mir hier einer von euch weiterhelfen ?
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von Dr.Einstein »

Eigentlich müsste der Debug danach weitergehen. Der Lancom möchte die DH Gruppe 16 nutzen, was der Client auch laut Auflistung unterstützt

Code: Alles auswählen

DH : 19 20 21 28 29 30 31 15 16 17 18 14
Das mitgelieferte Schlüsselpäarchen ist aber in der DH-Gruppe 19 geliefert, was auch Sinn ergibt, da der Client die DH-Gruppe 19 bevorzugt. Der Lancom antwortet daraufhin mit einem INVALID_KE_PAYLOAD (16 => ich will DH-16 haben).

Der Client solle danach noch einmal die Nachricht schicken, dieses Mal mit dem Schlüsselpäarchen DH-19. Wenn der Client darauf nicht reagiert, könntest du das Problem evtl umschiffen, indem du im Lancom Router unter den Default-Verschlüsselungen DH-19 mit anhakst.

https://www.rfc-editor.org/rfc/rfc5996

Code: Alles auswählen

 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
   the SA offers MUST include the Diffie-Hellman group of the KEi.  The
   Diffie-Hellman group of the KEi MUST be an element of the group the
   initiator expects the responder to accept (additional Diffie-Hellman
   groups can be proposed).  If the responder selects a proposal using a
   different Diffie-Hellman group (other than NONE), the responder MUST
   reject the request and indicate its preferred Diffie-Hellman group in
   the INVALID_KE_PAYLOAD Notify payload.  There are two octets of data
   associated with this notification: the accepted Diffie-Hellman group
   number in big endian order.  In the case of such a rejection, the
   CREATE_CHILD_SA exchange fails, and the initiator will probably retry
   the exchange with a Diffie-Hellman proposal and KEi in the group that
   the responder gave in the INVALID_KE_PAYLOAD Notify payload.
Hinweis, nächstes Mal bitte den Debug mit trace # vpn-debug und trace # vpn-ike ergänzen.
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

Hi Einstein - vielen Dank für deine Antwort - anbei der komplette Trace:

[VPN-IKE] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,007
[VPN_PHONE_XX] Sending packet after encryption:
IKE 2.0 Header:
Source/Port : xx.xx.xx.xx:4500
Destination/Port : xx.xx.xx.xx:39217
Routing-tag : 0
Com-channel : 0
| Initiator cookie : 94 37 38 F6 57 15 75 D5
| Responder cookie : 91 0D AD 41 38 AB C7 B4
| Next Payload : ENCR
| Version : 2.0
| Exchange type : IKE_AUTH
| Flags : 0x20 Response
| Msg-ID : 1
| Length : 80 Bytes
ENCR Payload
| Next Payload : NOTIFY
| CRITICAL : NO
| Reserved : 0x00
| Length : 52 Bytes
| IV : E7 8F 6D A2 74 84 90 03 68 E8 AF 70 26 37 58 E0
| Encrypted Data : 01 E5 5E 62 BA A1 86 02 C4 AE EC 9C 64 D5 73 E0
| ICV : 0A 8E FA D9 E8 C0 07 EB 38 7B 3B AC C1 00 71 1D

[VPN-Debug] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,008
Peer VPN_PHONE_XX: Constructing an IKE_AUTH-RESPONSE for send
Message encrypted successfully
Message authenticated successfully
Non-ESP-Marker Prepended
+(request, response) pair inserted into retransmission map
Sending an IKE_AUTH-RESPONSE of 80 bytes (responder encrypted)
Gateways: xx.xx.xx.xx:4500-->xx.xx.xx.xx:39217, tag 0 (UDP)
SPIs: 0x943738F6571575D5910DAD4138ABC7B4, Message-ID 1
Payloads: ENCR

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,008
Peer VPN_PHONE_XX: Constructing an IKE_AUTH-RESPONSE for send
NOTIFY(NO_PROPOSAL_CHOSEN)
IKE_SA ('VPN_PHONE_XX', 'ISAKMP-PEER-VPN_PHONE_XX' IPSEC_IKE SPIs 0x943738F6571575D5910DAD4138ABC7B4) removed from SADB
Sending an IKE_AUTH-RESPONSE of 80 bytes (responder encrypted)
Gateways: xx.xx.xx.xx:4500-->xx.xx.xx.xx:39217, tag 0 (UDP)
SPIs: 0x943738F6571575D5910DAD4138ABC7B4, Message-ID 1

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,008
IKE log: 164013.008737 Default IKE-DISCONNECT-RESPONSE: comchannel 33 set for peer VPN_PHONE_XX on message free

[VPN-Debug] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,009
LCVPEI: IKE-R-No-proposal-matched
DISCONNECT-RESPONSE sent for handle 33
IKE-TRANSPORT freed

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,009
CHILD_SA ('', '' ) removed from SADB
CHILD_SA ('', '' ) freed
IKE_SA ('VPN_PHONE_XX', 'ISAKMP-PEER-VPN_PHONE_XX' IPSEC_IKE SPIs 0x943738F6571575D5910DAD4138ABC7B4) freed

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,009
DISCONNECT-RESPONSE sent for handle 33

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,009
VPN: policy manager error indication: VPN_PHONE_XX (xx.xx.xx.xx), cause: 8707

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,009
VPN: WAN state changed to WanCalled for VPN_PHONE_XX (xx.xx.xx.xx) IKEv2, called by: 01ea4958

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,018
VPN: Error: IKE-R-No-proposal-matched (0x2203) for VPN_PHONE_XX (xx.xx.xx.xx) IKEv2

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,018
VPN: VPN_PHONE_XX (xx.xx.xx.xx) disconnected

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,020
vpn-maps[33], remote: VPN_PHONE_XX, idle, dns-name, static-name

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,028
VPN: installing ruleset for VPN_PHONE_XX (0.0.0.0) IKEv2

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,028
VPN: WAN state changed to WanDisconnect for VPN_PHONE_XX (0.0.0.0) IKEv2, called by: 01ea4958

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,029
Config parser: Start

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,030
Config parser: Finish
Wall clock time: 0 ms
CPU time: 0 ms

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,030
VPN: WAN state changed to WanIdle for VPN_PHONE_XX (0.0.0.0) IKEv2, called by: 01ea4958

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,030
vpn-maps[33], remote: VPN_PHONE_XX, idle, dns-name, static-name

[VPN-Status] 2023/01/02 16:40:13,438 Devicetime: 2023/01/02 16:40:13,031
VPN_PHONE_XX (ikev2): Remote gateway has changed from xx.xx.xx.xx to 0.0.0.0 -> tearing down

er findet anscheinend kein passendes Proposal ??

Ich wüsste aber nicht was er da erwartet - ich habe es - wie in der Anleitung - in StrongSwan beim Server mit der IP und beim Client mit DNS (CN=,...) eingetragen.
Lancom_Config.jpg
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von Dr.Einstein »

Der Trace ist wieder nur gekürzt, damit lässt sich leider nichts anfangen. Und ergänze mal bitte DH-19.

Code: Alles auswählen

VPN / IKEv2 / Verschlüsselungen / Default
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

DH19 ergänzt

Trace (diesmal hoffentlich komplett) angehängt, da zu viele Zeichen
LANCOM_VPN_TRACE.txt
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von Dr.Einstein »

protec hat geschrieben: 03 Jan 2023, 12:13 DH19 ergänzt
Kann nicht sein,

Code: Alles auswählen

  +Config   DH    transform(s): 16 14
Laut Debug
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von GrandDixence »

Code: Alles auswählen

[VPN-Debug] 2023/01/03 12:01:29,015  Devicetime: 2023/01/03 12:01:30,878
Peer DEFAULT [responder]: Received an IKE_AUTH-REQUEST of 1711 bytes
Gateways: xx.xx.xx.xx:4500<--xx.xx.xx.xx:4500
SPIs: 0x57599C390F1583A0C373396C876FBC27, Message-ID 1
Payloads: IDI, CERT(X509), NOTIFY(INITIAL_CONTACT), IDR, AUTH(DIGITAL SIGNATURE), CP(REQUEST), NOTIFY(ESP_TFC_PADDING_NOT_SUPPORTED), SA, TSI, TSR, NOTIFY(MOBIKE_SUPPORTED), NOTIFY(NO_ADDITIONAL_ADDRESSES), NOTIFY(EAP_ONLY_AUTHENTICATION), NOTIFY(MESSAGE_ID_SYNC_SUPPORTED)
+IKE_SA found and assigned
+Exchange created (flags: 0x00000054)
(IKEv2-Exchange 'DEFAULT', 'ISAKMP-PEER-DEFAULT' 0x57599C390F1583A0C373396C876FBC2700000001, P2, RESPONDER): Setting Negotiation SA
  Referencing (CHILD_SA, 0x57599C390F1583A0C373396C876FBC270000000100, responder): use_count 3
Looking for payload IDI (35)...Found 1 payload.
  +Received-ID CN=CLIENT,O=LANCOM,C=DE:DER_ASN1_DN matches the Expected-ID CN=CLIENT,O=LANCOM,C=DE:DER_ASN1_DN
  +Config   ENCR  transform(s): AES-GCM-16-256 AES-CBC-256
  +Received ENCR  transform(s): AES-CBC-256
  +Best intersection: AES-CBC-256
  +Config   PRF   transform(s): PRF-HMAC-SHA-256
  +Received PRF   transform(s): PRF-HMAC-SHA-256
  +Best intersection: PRF-HMAC-SHA-256
  +Config   INTEG transform(s): HMAC-SHA-256
  +Received INTEG transform(s): HMAC-SHA-256
  +Best intersection: HMAC-SHA-256
  +Config   DH    transform(s): 28 19 14
  +Received DH    transform(s): 16
  -No intersection
In den IKE_SA-Telegramme wird die Verschlüsselung für den Steuerkanal (IKE) ausgehandelt.
In den IKE_AUTH-Telegrammen wird die Verschlüsselung für den Datenkanal (IPSEC/ESP => CHILD_SA) ausgehandelt.

Es gibt keine Übereinstimmung bei der Aushandlung der Verschlüsselung des Datenkanals. Initiator des VPN-Tunnels (Android) wünscht DH-Gruppe 16 im IKE_SA_INIT-Telegramm. Der Responder (LANCOM) wurde auf die Unterstützung von DH-Gruppe 14, 19 und 28 im Datenkanal konfiguriert. Somit wird korrekterweise der Aufbau des VPN-Tunnels abgebrochen.

Beim Einsatz von IKEv2 ist zwingend dieser Umstand zu beachten:
There is one important aspect that affects IKEv2. The keys for the CHILD_SA that is implicitly created with the IKE_AUTH exchange will always be derived from the IKE key exchange even if PFS is configured. So if the peers disagree on whether to use PFS or not (or on the DH groups) it will not be known until the CHILD_SA is first rekeyed with a CREATE_CHILD_SA exchange (and fails). This is also the reason why you won’t see a DH group in the status output of the daemon until the SA is first rekeyed.
Quelle: https://docs.strongswan.org/docs/5.9/co ... eying.html

Deshalb empfehle ich immer, mit einer sehr kurzen Schlüsselmateriallebensdauer < 10 Minuten das Rekeying vom Steuerkanal (IKE) UND vom Datenkanal (IPSEC/ESP => CHILD_SA) zu testen!

Ich empfehle den Einsatz von RSASSA-PSS mit AES-GCM in Kombination mit CURVE25519. Siehe dazu:
fragen-zum-thema-vpn-f14/ikev2-verbindu ... 19717.html
protec
Beiträge: 18
Registriert: 03 Sep 2009, 14:58

Re: 1783VAW, VPN IKEV2 und Android 12

Beitrag von protec »

Merci für den Beitrag - ich bin ein bisschen weiter - ich habe jetzt bei der Verschlüsselung 16 und 19 angehakt:

Code: Alles auswählen

  +Config   DH    transform(s): 28 16 19 14
  +Received DH    transform(s): 16
damit komme ich jetzt weiter, bekomme jetzt aber folgenden Fehler (LAN-Monitor)

IKE Schlüssel stimmen nicht überein (Passiver Verbindungsaufbau, IKE) [0x220A]

wie im Erstpost geschrieben habe ich das streng nach der Anleitung gemacht - d.h. im Server steht IPv4 und die öffentliche IP des Routers, im Client ASN.1 - so ist das dann auch im StrongSwan eingetragen

der aktuelle Trace sieht wie folgt aus:
lancom_trace.txt
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Antworten