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:
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:
IPSec Assocs
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:
Soweit meine 5 Cent zu diesem Thema. Gibt es andere, konträre Erkenntnisse? Dinge die ich übersehen habe oder sonstige Anmerkungen?
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 ispi3E149618BC59BA6 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?