[Info] FritzBox VPN: IKEv2 (ab 7.50)

Killom

Neuer User
Mitglied seit
8 Feb 2020
Beiträge
19
Punkte für Reaktionen
0
Punkte
1
Wie es scheint, hat AVM einen kompletten IKEv2 Stack ins FritzOS implementiert, diesen dann aber über die ar7cfg soweit beschnitten, dass man faktisch nur eine clientseitige Verbindung hierüber aufbauen kann und kein Site2Site.

Ich hatte mir über Ostern die Binaries der 7.50 mal etwas genauer mit Ghidra angeschaut. Für mich sah es so aus, als wäre die libikev2.so eine vollständig implementierte IKEv2 Library:

libikev2.so:
C-ähnlich:
Funktion: ikev2_dh_group2str kennt folgende DH Gruppen:
    TID_DHG_NONE
    TID_DHG_1
    TID_DHG_2
    TID_DHG_5
    TID_DHG_14
    TID_DHG_15
    TID_DHG_16
    TID_DHG_17
    TID_DHG_18

Funktion: ikev2_transform_id_value2str kennt folgende Werte:

Case1: (TT_ENCR)
    TID_ENCR_DES_IV64
    TID_ENCR_DES
    TID_ENCR_3DES
    TID_ENCR_RC5
    TID_ENCR_IDEA
    TID_ENCR_CAST
    TID_ENCR_BLOWFISH
    TID_ENCR_3IDEA
    TID_ENCR_DES_IV32
    TID_ENCR_NULL
    TID_ENCR_AES_CBC
    TID_ENCR_AES_CTR

Case2: (TT_PRF)
    TID_PRF_HMAC_MD5
    TID_PRF_HMAC_SHA1
    TID_PRF_HMAC_TIGER
    TID_PRF_AES128_XCBC
    TID_PRF_HMAC_SHA2_256
    TID_PRF_HMAC_SHA2_384
    TID_PRF_HMAC_SHA2_512

Case3: (TT_INTEG)
    TID_AUTH_HMAC_MD5_96
    TID_AUTH_HMAC_SHA1_96
    TID_AUTH_HMAC_DES_MAC
    TID_AUTH_KPDK_MD5
    TID_AUTH_AES_XCBC_96
    TID_AUTH_HMAC_SHA2_256
    TID_AUTH_HMAC_SHA2_384
    TID_AUTH_HMAC_SHA2_512

Case4: (TT_DH)
    TID_DHG_1 768-bit MODP Group
    TID_DHG_2 1024-bit MODP Group
    TID_DHG_5 1536-bit MODP Group
    TID_DHG_14 2048-bit MODP Group
    TID_DHG_15 3072-bit MODP Group
    TID_DHG_16 4096-bit MODP Group
    TID_DHG_17 6144-bit MODP Group
    TID_DHG_18 8192-bit MODP Group

Case5: (TT_ESN)
    TID_ESN_NO_EXT_SEQ_NUMBERS
    TID_ESN_EXT_SEQ_NUMBERS

Scheinbar teilen sich IKEv1 und IKEv2 "irgendwie" die Proposals und Strategien, da in der libikev2.so über die Funktion CFG_load ebenfalls die ipsec.cfg geladen wird. Ansonsten greift die Lib selber auf keine weiteren .cfg Dateien direkt zu. Die Auswertung der eigentlichen VPN Verbindungen und das Laden der vpn.cfg geschieht über eine noch nicht näher identifizierte Subroutine der ar7cfg binary. Das waren soweit die Erkenntnisse, die ich über Ostern sammeln konnte.

Heute habe ich dann mal Versucht, via klassischen trial-and-error eine Site2Site Verbindung aufzubauen. Im wesentlichen kann man hierfür den Parameter 'use_ikev2 = yes;' setzen. Der Parameter 'conn_type = conntype_lan;' sowie die übliche Konfiguration, wie sie auch für eine Site2Site unter IKEv1 notwendig wäre. Zu beachten ist hierbei, dass AVM zur Identifizierung der Verbindungspartner unter IKEv2 nur die Verwendung der key_id (sowie dem PSK) vorgesehen hat. FQDN und der ganze Rest fällt hier also flach.

Endergebnis des Ganzen ist, dass eine Site2Site mMn. funktionieren könnte, würde uns AVM hier nicht den dicken Stinkefinger zeigen:

ikev2.log:
2023-05-02 15:27:04 ikev2:< add(cname=R-IKEv2-Test,localip=77.x.x.184, remoteip=255.255.255.255, p1ss=LT8h/all/all/all, p2ss=LT8h/esp-all-all/ah-none/comp-all/no-pfs p1mode=4 flags=0x448011 tunnel no_xauth cfgmode)
[...]
2023-05-02 15:31:00 ikev2:<<<< rcv ip:77.x.x.97 port:500 nat_t:0 exch_type:IKE_SA_INIT ispi:D3E149618BC59BA6 rspi:0000000000000000
2023-05-02 15:31:00 ikev2:ikev2_udpserver_dgramrcv peer found: UNKNOWN -> look up for xctx
2023-05-02 15:31:00 ikev2:ikev2_udpserver_dgramrcv peer ist bekannt, aber kein passender ctx vorhanden
2023-05-02 15:31:00 ikev2:ikev2_udpserver_dgramrcv create new ctx for IKE_SA_INIT
2023-05-02 15:31:00 ikev2:ikev2_udpserver_dgramrcv failed
2023-05-02 15:31:00 ikev2:ikev2_udpserver_dgramrcv failed

IPSec Assocs
R-IKEv2-Test: 77.x.x.184:0.0.0.0 255.255.255.255:0.0.0.0 0 SAs valid enabled dynlocalip
permit ip any host 192.168.1.0
Forbidden Clients: 192.168.189.0/24

Im Prinzip wird 'conn_type = conntype_lan;' nicht richtig ausgewertet (vermutlich da nur 'conn_type = conntype_user;' als valide Option in dem Fall vorgesehen wurde)

'remotehostname' sowie 'remoteip' werden geflissentlich ignoriert oder überschrieben (siehe remoteip in ikev2.log) obwohl die konfigurierten VPN Optionen korrekt ausgelesen wurden:

Configured VPN connections:
Code:
  +--------------+--------------+--------------------+----------+------------------+
  | Name         | Remote IP    | Remote Virtual IP  | Local IP | Local Virtual IP |
  |              |              | (Benutzer-Einwahl) |          | (Firmen-VPN)     |
  +--------------+--------------+--------------------+----------+------------------+
  | R-IKEv2-Test | 77.x.x.97    | 0.0.0.0            | 0.0.0.0  | 0.0.0.0          |
  +--------------+--------------+--------------------+----------+------------------+

Soweit meine 5 Cent zu diesem Thema. Gibt es andere, konträre Erkenntnisse? Dinge die ich übersehen habe oder sonstige Anmerkungen?
 
IKEv2 nur in Verbindung mit Android.
iOS und Site-to-Site davon ausgenommen. Hatte ich über YouTube angefragt und wurde Seitens AVM bestätigt, obwohl man zuvor groß von der IKEv2 Unterstützung geschwärmt hatte!
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.