VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Forum zum Thema allgemeinen Fragen zu VPN

Moderator: Lancom-Systems Moderatoren

Antworten
zrbRouter
Beiträge: 3
Registriert: 29 Jul 2024, 08:46

VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Beitrag von zrbRouter »

Hallo LANCOM-Gemeinde,

ich hoffe ihr könnt mir weiterhelfen. Ich möchte eine IKEv2-VPN-Verbindung von einen Strongswan Android Client
zu unseren LANCOM 1790VA aufbauen und bekomme einen INTERNAL_ADDRESS_FAILURE und folgenden Log über SSH "trace # vpn status".

Code: Alles auswählen

+Authentication successful
IKE_SA ('VPN-CLIE976F', 'ISAKMP-PEER-DEFAULT' IPSEC_IKE SPIs 0xB446233962B84B0A93A8A6C715069A96) removed from SADB
IKE_SA ('VPN-CLIE976F', 'ISAKMP-PEER-DEFAULT' IPSEC_IKE SPIs 0xB446233962B84B0A93A8A6C715069A96) entered to SADB
Request attributes:
  INTERNAL_IP4_ADDRESS()
  INTERNAL_IP6_ADDRESS()
  INTERNAL_IP4_DNS()
  INTERNAL_IP6_DNS()
-Not configured as Server () -> abort

[VPN-IKE] 2024/07/29 08:41:41,236
[ZRB-VPN-CLIE976F] Sending packet before ikev2 fragmentation:
IKE 2.0 Header:
Source/Port         : lokaleIPAdresse:4500
Destination/Port    : WAN-Adresse-Mobiltelefon:31213

[...]

Sending 1 ikev2 fragment(s) of 1364 bytes and last fragment of size 148 bytes
Payloads: IDR, CERT(X509), AUTH(DIGITAL SIGNATURE), NOTIFY(INTERNAL_ADDRESS_FAILURE)

Die Identitäten werden erfolgreich geprüft, nur bei den IP-Adressen hakt es.
Ich vermute das Problem liegt daran, dass der VPN-Server seine lokale IP-Adresse in den IKE 2.0 Header
schreibt, statt der öffentlichen. Der Server ist über eine Public DNS vpn.firma.de erreichbar.

Könnte ihr mir sagen, wie ich das konfigurieren muss, damit es funktioniert?
Vielen Dank für's Durchlesen bis hierher.

Gruß
zrbRouter


PS:
Noch als Ergänzung zuvor hatte ich client-seitg folgende Fehlermeldung:

Code: Alles auswählen

Jul 27 19:43:29 08[CFG] constraint check failed: identity 'Public-IP' (ID_IPV4_ADDR) required, not matched by 'lokaleIPAdresse' (ID_IPV4_ADDR)
Jul 27 19:43:29 08[CFG] selected peer config 'android' unacceptable: constraint checking failed
Daraufhin habe ich die lokaleIPAdresse des VPN-Servers=LANCOM-Router ergänzend zur publicDNS als subjectAltName im VPN-Serverzertifikat eingetragen.
Frühstücksdirektor
Beiträge: 184
Registriert: 08 Jul 2022, 12:53
Wohnort: Aachen

Re: VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Beitrag von Frühstücksdirektor »

Die Meldung "-Not configured as Server () -> abort" besagt, dass der LANCOM nicht als CFG-Moder Server konfiguriert ist, bzw. der Eintrag auf den der Client matcht. In der Konfiguration des LANCOMs kann man das in der IKEv2-Gegenstellen-Tabelle von "IKE-CFG-Mode" konfigurieren. Dort "IKE-CFG" auf "Server" setzen, nicht vergessen direkt darunter einen IPv4-Einwahl-Pool zu definieren, sonst klappt das auch nicht.
zrbRouter
Beiträge: 3
Registriert: 29 Jul 2024, 08:46

Re: VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Beitrag von zrbRouter »

Guten Morgen Frühstücksdirektor,

Danke für deine Antwort!

IKE-CFG: Server ist bereits eingestellt.
Eine Verbindung mittels PSK über den Android native VPN-Client ist mit dem Adresspool auch möglich.
Woran könnt es noch liegen?
android_IKE-CFG.JPG
Gruß
zrbRouter
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Frühstücksdirektor
Beiträge: 184
Registriert: 08 Jul 2022, 12:53
Wohnort: Aachen

Re: VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Beitrag von Frühstücksdirektor »

Dann scheint der Client auf den DEFAULT-EINTRAG zu matchen, der dann wohl nicht als CFG-Mode Server konfiguriert ist.
Der Name des ankommenden Clients ist "VPN-CLIE976F", Wenn du dafür keinen Eintrag hast, greift wohl der DEFAUT-Eintrag.
zrbRouter
Beiträge: 3
Registriert: 29 Jul 2024, 08:46

Re: VPN IKEv2 Strongswan Android-Client - INTERNAL_ADDRESS_FAILURE

Beitrag von zrbRouter »

Hallo nochmal Frühstücksdirektor,

vielen Dank für deine Hilfe! Das war der entscheidende Hinweis, um meinen eigenen Fehler zu entdecken.

Ich hatte im Verlaufe der Tests neue Zertifikate mit leicht veränderterm ASN.1-Distinguished Name erstellt,
die Identitäten, dann aber im LANCOM nicht aktualisiert. Der LANCOM konnte durch den Mismatch
nur auf den Default-Eintrag zurückgreifen.

Jetzt steht die Verbindung :D
Antworten