Text only | Text with Images

OPNsense Forum

International Forums => German - Deutsch => Topic started by: gongoscho on April 10, 2024, 10:30:04 PM

Title: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 10, 2024, 10:30:04 PM
Hallo,

habe ein Problem mit 24.1.5_3 VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2 und Shared IP pool.
Eingerichtet nach: https://docs.opnsense.org/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.html mit abweichungen:

Pool
10.0.1.1/30

General settings
Proposals: aes256gcm16-sha512-curve448 [DH32, Modern EC]
Send cert req: [   ]
Send certificate: if asked


Children
ESP proposals aes256gcm16-curve448 [DH32, Modern EC]



Die Verbindung bleibt laut Android 13 strongswan Client bestehen,

WAN IP ersetzt
Benutzer ersetzt
stronswan Client IP = Original (Bogon / NAT?) aber nicht gleich wie im FW IPsec Log

Quote
Apr 10 21:22:00 00[DMN] +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Apr 10 21:22:00 00[DMN] Starting IKE service (strongSwan 5.9.11, Android 13 - lineage_beryllium-userdebug 13 TQ3A.230901.001 eng.root.20240202.205748 dev-keys/2024-01-05, POCO F1 - Xiaomi/beryllium/Xiaomi, Linux 4.9.337-perf-g4583022b1192, aarch64, org.strongswan.android)
Apr 10 21:22:00 00[LIB] loaded plugins: androidbridge charon android-log socket-default openssl nonce pkcs1 pem x509 xcbc kdf revocation eap-identity eap-mschapv2 eap-md5 eap-gtc eap-tls
Apr 10 21:22:00 00[JOB] spawning 16 worker threads
Apr 10 21:22:00 00[LIB] all OCSP validation disabled
Apr 10 21:22:00 00[LIB] all CRL validation disabled
Apr 10 21:22:00 05[IKE] initiating IKE_SA android[125] to fixeWANip
Apr 10 21:22:00 05[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Apr 10 21:22:00 05[NET] sending packet: from 100.76.196.82[42787] to fixeWANip[500] (948 bytes)
Apr 10 21:22:00 06[NET] received packet: from fixeWANip[500] to 100.76.196.82[42787] (38 bytes)
Apr 10 21:22:00 06[ENC] parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
Apr 10 21:22:00 06[IKE] peer didn't accept DH group ECP_256, it requested CURVE_448
Apr 10 21:22:00 06[IKE] initiating IKE_SA android[125] to fixeWANip
Apr 10 21:22:00 06[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Apr 10 21:22:00 06[NET] sending packet: from 100.76.196.82[42787] to fixeWANip[500] (940 bytes)
Apr 10 21:22:00 07[NET] received packet: from fixeWANip[500] to 100.76.196.82[42787] (264 bytes)
Apr 10 21:22:00 07[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Apr 10 21:22:00 07[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_512/CURVE_448
Apr 10 21:22:00 07[IKE] local host is behind NAT, sending keep alives
Apr 10 21:22:00 07[IKE] sending cert request for "C=AT, ST=Stadt, L=Stadt, O=Name, E=user@domain.tld, CN=IPsec CA ECC"
Apr 10 21:22:00 07[IKE] establishing CHILD_SA android{235}
Apr 10 21:22:00 07[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR ADDR6 DNS DNS6) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Apr 10 21:22:00 07[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (455 bytes)
Apr 10 21:22:00 10[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (1234 bytes)
Apr 10 21:22:00 10[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Apr 10 21:22:00 10[IKE] received end entity cert "C=AT, ST=Stadt, L=Stadt, O=Name, E=user@domain.tld, CN=fixeWANip"
Apr 10 21:22:00 10[CFG]   using certificate "C=AT, ST=Stadt, L=Stadt, O=Name, E=user@domain.tld, CN=fixeWANip"
Apr 10 21:22:00 10[CFG]   using trusted ca certificate "C=AT, ST=Stadt, L=Stadt, O=Name, E=user@domain.tld, CN=IPsec CA ECC"
Apr 10 21:22:00 10[CFG]   reached self-signed root ca with a path length of 0
Apr 10 21:22:00 10[IKE] authentication of 'fixeWANip' with ECDSA_WITH_SHA512_DER successful
Apr 10 21:22:00 10[IKE] server requested EAP_IDENTITY (id 0x00), sending 'user@domain.tld'
Apr 10 21:22:00 10[ENC] generating IKE_AUTH request 2 [ EAP/RES/ID ]
Apr 10 21:22:00 10[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (87 bytes)
Apr 10 21:22:00 11[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (97 bytes)
Apr 10 21:22:00 11[ENC] parsed IKE_AUTH response 2 [ EAP/REQ/MSCHAPV2 ]
Apr 10 21:22:00 11[IKE] server requested EAP_MSCHAPV2 authentication (id 0x4A)
Apr 10 21:22:00 11[ENC] generating IKE_AUTH request 3 [ EAP/RES/MSCHAPV2 ]
Apr 10 21:22:00 11[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (141 bytes)
Apr 10 21:22:00 12[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (134 bytes)
Apr 10 21:22:00 12[ENC] parsed IKE_AUTH response 3 [ EAP/REQ/MSCHAPV2 ]
Apr 10 21:22:00 12[IKE] EAP-MS-CHAPv2 succeeded: 'Welcome2strongSwan'
Apr 10 21:22:00 12[ENC] generating IKE_AUTH request 4 [ EAP/RES/MSCHAPV2 ]
Apr 10 21:22:00 12[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (67 bytes)
Apr 10 21:22:00 13[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (65 bytes)
Apr 10 21:22:00 13[ENC] parsed IKE_AUTH response 4 [ EAP/SUCC ]
Apr 10 21:22:00 13[IKE] EAP method EAP_MSCHAPV2 succeeded, MSK established
Apr 10 21:22:00 13[IKE] authentication of 'user@domain.tld' (myself) with EAP
Apr 10 21:22:00 13[ENC] generating IKE_AUTH request 5 [ AUTH ]
Apr 10 21:22:00 13[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (129 bytes)
Apr 10 21:22:01 14[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (277 bytes)
Apr 10 21:22:01 14[ENC] parsed IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Apr 10 21:22:01 14[IKE] authentication of 'fixeWANip' with EAP successful
Apr 10 21:22:01 14[IKE] installing DNS server 10.0.0.1
Apr 10 21:22:01 14[IKE] installing new virtual IP 10.0.1.1
Apr 10 21:22:01 14[IKE] peer supports MOBIKE
Apr 10 21:22:01 14[IKE] IKE_SA android[125] established between 100.76.196.82[user@domain.tld]...fixeWANip[fixeWANip]
Apr 10 21:22:01 14[IKE] scheduling rekeying in 35584s
Apr 10 21:22:01 14[IKE] maximum IKE_SA lifetime 37384s
Apr 10 21:22:01 14[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Apr 10 21:22:01 14[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Apr 10 21:22:01 14[IKE] CHILD_SA android{235} established with SPIs 8fc58f43_i cd9c01bb_o and TS 10.0.1.1/32 === 0.0.0.0/0
Apr 10 21:22:01 14[DMN] setting up TUN device for CHILD_SA android{235}
Apr 10 21:22:01 14[DMN] successfully created TUN device
Apr 10 21:22:31 13[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:22:31 13[ENC] parsed INFORMATIONAL request 0 [ ]
Apr 10 21:22:31 13[ENC] generating INFORMATIONAL response 0 [ ]
Apr 10 21:22:31 13[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:23:01 06[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:23:01 06[ENC] parsed INFORMATIONAL request 1 [ ]
Apr 10 21:23:01 06[ENC] generating INFORMATIONAL response 1 [ ]
Apr 10 21:23:01 06[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:23:31 07[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:23:31 07[ENC] parsed INFORMATIONAL request 2 [ ]
Apr 10 21:23:31 07[ENC] generating INFORMATIONAL response 2 [ ]
Apr 10 21:23:31 07[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:24:01 08[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:24:01 08[ENC] parsed INFORMATIONAL request 3 [ ]
Apr 10 21:24:01 08[ENC] generating INFORMATIONAL response 3 [ ]
Apr 10 21:24:01 08[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:24:32 11[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:24:32 11[ENC] parsed INFORMATIONAL request 4 [ ]
Apr 10 21:24:32 11[ENC] generating INFORMATIONAL response 4 [ ]
Apr 10 21:24:32 11[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:25:02 13[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:25:02 13[ENC] parsed INFORMATIONAL request 5 [ ]
Apr 10 21:25:02 13[ENC] generating INFORMATIONAL response 5 [ ]
Apr 10 21:25:02 13[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:25:32 14[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:25:32 14[ENC] parsed INFORMATIONAL request 6 [ ]
Apr 10 21:25:32 14[ENC] generating INFORMATIONAL response 6 [ ]
Apr 10 21:25:32 14[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:26:03 09[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:26:03 09[ENC] parsed INFORMATIONAL request 7 [ ]
Apr 10 21:26:03 09[ENC] generating INFORMATIONAL response 7 [ ]
Apr 10 21:26:03 09[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:26:34 08[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:26:34 08[ENC] parsed INFORMATIONAL request 8 [ ]
Apr 10 21:26:34 08[ENC] generating INFORMATIONAL response 8 [ ]
Apr 10 21:26:34 08[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:27:04 11[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:27:04 11[ENC] parsed INFORMATIONAL request 9 [ ]
Apr 10 21:27:04 11[ENC] generating INFORMATIONAL response 9 [ ]
Apr 10 21:27:04 11[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)
Apr 10 21:27:34 13[NET] received packet: from fixeWANip[4500] to 100.76.196.82[39416] (57 bytes)
Apr 10 21:27:34 13[ENC] parsed INFORMATIONAL request 10 [ ]
Apr 10 21:27:34 13[ENC] generating INFORMATIONAL response 10 [ ]
Apr 10 21:27:34 13[NET] sending packet: from 100.76.196.82[39416] to fixeWANip[4500] (57 bytes)


allerdings sehe ich im Log auf der FW folgende Fehler:

WAN IP ersetzt
strongswan IP ersetzt
Benutzer ersetzt

Quote from: IPsec Log
2024-04-10T21:42:54   Informational   charon   07[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T21:42:54   Informational   charon   07[KNL] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> unable to delete SAD entry with SPI d58e1c7f: No such process (3)   
2024-04-10T21:42:54   Informational   charon   07[KNL] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> unable to delete SAD entry with SPI c09ab254: No such process (3)   
2024-04-10T21:42:54   Informational   charon   07[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> giving up after 5 retransmits   
2024-04-10T21:42:14   Informational   charon   07[KNL] creating delete job for CHILD_SA ESP/0xd58e1c7f/stronswanClient   
2024-04-10T21:42:14   Informational   charon   11[KNL] creating delete job for CHILD_SA ESP/0xc09ab254/fixeWANip
....
....
2024-04-10T21:31:57   Informational   charon   15[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> sending DPD request   
2024-04-10T21:31:18   Informational   charon   05[JOB] CHILD_SA ESP/0xcd9c01bb/fixeWANip not found for rekey   
2024-04-10T21:31:13   Informational   charon   05[NET] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> sending packet: from fixeWANip[4500] to stronswanClient[48938] (277 bytes)   
2024-04-10T21:31:13   Informational   charon   05[ENC] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> generating IKE_AUTH response 5 [ AUTH CPRP(ADDR DNS) N(ESP_TFC_PAD_N) SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]   
2024-04-10T21:31:13   Notice   charon   [UPDOWN] received up-client event for reqid 1   
2024-04-10T21:31:13   Informational   charon   05[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> CHILD_SA 50d5bb11-9c85-418f-8fb3-4723cd142472{222} established with SPIs c09ab254_i d58e1c7f_o and TS 0.0.0.0/0 === 10.0.1.1/32   
2024-04-10T21:31:13   Informational   charon   05[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ   
2024-04-10T21:31:13   Informational   charon   05[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> maximum IKE_SA lifetime 2437s   
2024-04-10T21:31:13   Informational   charon   05[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> scheduling rekeying in 2197s   
2024-04-10T21:31:13   Informational   charon   05[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> IKE_SA b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3[252] established between fixeWANip[fixeWANip]...stronswanClient[user@domain.tld]   
2024-04-10T21:31:13   Informational   charon   05[IKE] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> assigning virtual IP 10.0.1.1 to peer 'user@domain.tld'   
2024-04-10T21:31:13   Informational   charon   05[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|252> reassigning offline lease to 'user@domain.tld'
....
....
....
2024-04-10T16:05:06   Informational   charon   13[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|241> reassigning offline lease to 'user@domain.tld'   
2024-04-10T16:05:06   Informational   charon   02[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|239> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T15:55:45   Informational   charon   05[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|239> reassigning offline lease to 'user@domain.tld'   
2024-04-10T15:55:44   Informational   charon   05[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|237> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T15:46:37   Informational   charon   10[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|237> reassigning offline lease to 'user@domain.tld'   
2024-04-10T15:46:37   Informational   charon   10[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|235> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T15:37:18   Informational   charon   12[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|235> reassigning offline lease to 'user@domain.tld'   
2024-04-10T15:37:18   Informational   charon   12[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|233> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T15:28:04   Informational   charon   11[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|233> reassigning offline lease to 'user@domain.tld'   
2024-04-10T15:28:04   Informational   charon   15[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|231> lease 10.0.1.1 by 'user@domain.tld' went offline   
2024-04-10T15:18:39   Informational   charon   13[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|231> reassigning offline lease to 'user@domain.tld'   
2024-04-10T15:18:39   Informational   charon   13[CFG] <b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3|229> lease 10.0.1.1 by 'user@domain.tld' went offline   

Ich freue mich über jede Hilfe.

grEEtZ,
gongoscho
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 11, 2024, 08:51:59 AM
Welche Auswirkungen auf die Verbindung haben die Fehler? Gibt es Verbindungsunterbrechungen, Paketloss, hohe Pingzeiten etc, oder läuft es einfach und die Fehler sind transient?
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 11, 2024, 11:06:21 AM
Ja, laut Client bin ich immer verbunden, aber nach einer Zeit funktioniert die VPN-Verbindung nicht mehr.
Muss die aktuelle Verbindung neu verbinden bzw. VPN aus- / ein- schalten.
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 11, 2024, 11:08:47 AM
Kannst du mal deine swanctl.conf teilen? Ich will sehen wie die Konfiguration genau aussieht, dann kann ich sie nachstellen.

/usr/local/etc/swanctl/swanctl.conf
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 11, 2024, 01:24:50 PM
Ja klar, kein Thema

WAN IP ersetzt
Benutzer ersetzt
Code Select
# This file is automatically generated. Do not edit
connections {
    b67d9c3f-7a90-4c7b-9066-b8d3979b2ea3 {
        proposals = aes256gcm16-sha512-x448
        unique = no
        aggressive = no
        version = 2
        mobike = yes
        encap = no
        rekey_time = 2400
        dpd_delay = 30
        pools = pool-roadwarrior-ipv4
        send_certreq = no
        send_cert = ifasked
        keyingtries = 0
        local-dbce23c1-b493-410d-b77d-6ba8a78cd10d {
            round = 0
            auth = pubkey
            id = fixeWANip
            certs = 66034635e0793.crt
        }
        remote-829cf7fd-dea2-43ac-bf37-74dbd1cf0628 {
            round = 0
            auth = eap-mschapv2
            eap_id = %any
        }
        children {
            50d5bb11-9c85-418f-8fb3-4723cd142472 {
                esp_proposals = aes256gcm16-x448
                sha256_96 = no
                start_action = trap
                close_action = none
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 0.0.0.0/0
                rekey_time = 600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 50d5bb11-9c85-418f-8fb3-4723cd142472
            }
        }
    }
}
pools {
    pool-roadwarrior-ipv4 {
        addrs = 10.0.1.1/30
        dns = 10.0.0.1
    }
}
secrets {
    eap-04e3f318-ddcd-4336-a662-3e2341bd913f {
        id-0 = user@domain.tld
        secret = ***
    }
    eap-cfed74c7-7b04-4e65-a77c-67406002b6ae {
        id-0 = user@domain.tld
        secret = ***
    }
}
# Include config snippets
include conf.d/*.conf


Was mir sofort aufgefallen ist, dass die Verschlüsselung nicht mit der in der UI übereinstimmt!
GUI: Curve448, swanctl.conf: x448

Seltsam...

Android Client v2.4.2
https://f-droid.org/de/packages/org.strongswan.android/

Auch mit 2.5.1 von https://strongswan.org/download.html (https://strongswan.org/download.html) probiert.
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 11, 2024, 02:13:25 PM
Mir fällt auf, das encap = no ist.

UDP Encapsulation muss auf android verwendet werden.

Zusätzlich hilft es das hier zu setzen:
```
        local_port = 4500
        remote_port = 4500
```

Der Pool sollte bei 0 gestartet werden.

10.0.1.1/30 ist vom CIDR her falsch.
Entweder: 10.0.1.0/30 oder das nächste 10.0.1.4/30

Ansonsten, das Zertifikat auf die IP Adresse zu setzen, das hab ich in der Anleitung auch anders geschrieben, da steht es soll ein FQDN sein. Aber da der Verbindungsaufbau geht, scheint die Methode auch gültig zu sein. Ist halt weniger flexibel wenn man das ausrollt und sich mal die IP ändert.
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 11, 2024, 02:57:40 PM
Oh man, UDP Encapsulation ist ein Fehler von mir!
Habe es ohne mal probiert, weil in der Anleitung ist es aktiv. Sorry!  ::)

Danke für den Tipp mal mit den fixen UDP 4500 Port.

In der SAD stand zwar immer, esp-udp und im Android-Log auch immer 4500,
aber in den States am WAN sah ich auch 500 immer...

10.0.1.1 vertipper von mir  :o und über geblieben von meinen Test mit nur einem Client: 10.0.1.1/32

Danke!
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 11, 2024, 11:51:16 PM
Also ganz kurios. Es hat sich mit UDP 4500 verschlimmert.
Habe auch probiert am Android Client NAT-T Keepalive Interval von 45 auf 20 zu setzen.

Habe jetzt eine neue IPsec Connection mit Curve25519 erstellt, Local addresses: fixeWANip gesetzt, ohne force UDP Encapsulation und die Verbindung ist jetzt stabil. Wird automatisch auf UDP 4500 aufgebaut, ohne was zu erzwingen.

Sehe keine Fehler mehr wie:

WAN IP ersetzt
Benutzer ersetzt
Kennwörter ersetzt
Code Select
# This file is automatically generated. Do not edit
connections {
    5464e5a3-4a97-451f-b78f-8d18855e6188 {
        proposals = aes256gcm16-sha512-x25519
        unique = no
        aggressive = no
        version = 2
        mobike = yes
        local_addrs = fixeWANip
        encap = no
        rekey_time = 2400
        dpd_delay = 30
        pools = pool-roadwarrior-ipv4
        send_certreq = no
        send_cert = ifasked
        keyingtries = 0
        local-a1c07747-3e5b-4f13-8dda-b205da094557 {
            round = 0
            auth = pubkey
            id = fixeWANip
            certs = 66034635e0793.crt
        }
        remote-012c3dbd-2dde-4720-9c6c-eb3f7bcf8368 {
            round = 0
            auth = eap-mschapv2
            eap_id = %any
        }
        children {
            2a98dee1-e9d4-4383-864c-f6a13058bdd6 {
                esp_proposals = aes256gcm16-x25519
                sha256_96 = no
                start_action = trap
                close_action = none
                dpd_action = clear
                mode = tunnel
                policies = yes
                local_ts = 0.0.0.0/0
                rekey_time = 600
                updown = /usr/local/opnsense/scripts/ipsec/updown_event.py --connection_child 2a98dee1-e9d4-4383-864c-f6a13058bdd6
            }
        }
    }
}
pools {
    pool-roadwarrior-ipv4 {
        addrs = 10.0.1.0/30
        dns = 10.0.0.1
    }
}
secrets {
    eap-04e3f318-ddcd-4336-a662-3e2341bd913f {
        id-0 = user@domain.tld
        secret = ***
    }
    eap-cfed74c7-7b04-4e65-a77c-67406002b6ae {
        id-0 = user@domain.tld
        secret = ***
    }
}
# Include config snippets
include conf.d/*.conf


Spannend dass hier wieder x25519 steht, und nicht Curve25519...


Allerdings habe ich ein seltsames Phänomen. Habe ja 2 Clients mit 10.0.1.0/30
Wenn 10.0.1.1 online ist, funktioniert alles, wenn zusätzlich 10.0.1.2 online ist können nicht mehr interne DNS-Einräge von 10.0.1.2 aufgelöst werden.

Meldet sich der betroffene Client an, wenn der andere nicht online ist, funktioniert alles.
Es liegt also nicht am Client.

Für das IPsec habe ich zum testen als FW Regel: from any to any.

Wegen dem FQDN, ich habe eine fixe IPv4 Adresse

Log

WAN IP ersetzt
strongswan IP ersetzt

Code Select
2024-04-11T23:53:06 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> CHILD_SA closed
2024-04-11T23:53:06 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received DELETE for ESP CHILD_SA with SPI 92faf950
2024-04-11T23:53:06 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> parsed INFORMATIONAL response 11 [ D ]
2024-04-11T23:53:06 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received packet: from stronswanClient [48476] to fixeWANip[4500] (69 bytes)
2024-04-11T23:53:05 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending packet: from fixeWANip[4500] to stronswanClient [48476] (69 bytes)
2024-04-11T23:53:05 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> generating INFORMATIONAL request 11 [ D ]
2024-04-11T23:53:05 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending DELETE for ESP CHILD_SA with SPI cd2ed3b8
2024-04-11T23:53:05 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> closing CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{4} with SPIs cd2ed3b8_i (48177 bytes) 92faf950_o (0 bytes) and TS 0.0.0.0/0 === 10.0.1.2/32
2024-04-11T23:53:05 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> outbound CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{6} established with SPIs c6efcc69_i 5f937ac8_o and TS 0.0.0.0/0 === 10.0.1.2/32
2024-04-11T23:53:05 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> inbound CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{6} established with SPIs c6efcc69_i 5f937ac8_o and TS 0.0.0.0/0 === 10.0.1.2/32
2024-04-11T23:53:05 Informational charon 04[CFG] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> selected proposal: ESP:AES_GCM_16_256/CURVE_25519/NO_EXT_SEQ
2024-04-11T23:53:05 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> parsed CREATE_CHILD_SA response 10 [ SA No KE TSi TSr ]
2024-04-11T23:53:05 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received packet: from stronswanClient [48476] to fixeWANip[4500] (225 bytes)
2024-04-11T23:53:05 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending packet: from fixeWANip[4500] to stronswanClient [48476] (245 bytes)
2024-04-11T23:53:05 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> generating CREATE_CHILD_SA request 10 [ N(REKEY_SA) N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2024-04-11T23:53:05 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> establishing CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{6} reqid 2
2024-04-11T23:53:05 Informational charon 04[KNL] creating rekey job for CHILD_SA ESP/0xcd2ed3b8/fixeWANip
2024-04-11T23:52:49 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> parsed INFORMATIONAL response 9 [ ]
2024-04-11T23:52:49 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received packet: from stronswanClient [48476] to fixeWANip[4500] (57 bytes)
2024-04-11T23:52:49 Informational charon 04[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending packet: from fixeWANip[4500] to stronswanClient [48476] (57 bytes)
2024-04-11T23:52:49 Informational charon 04[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> generating INFORMATIONAL request 9 [ ]
2024-04-11T23:52:49 Informational charon 04[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending DPD request
2024-04-11T23:52:38 Informational charon 01[KNL] creating rekey job for CHILD_SA ESP/0xcbaa7fd0/fixeWANip
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> CHILD_SA closed
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> received DELETE for ESP CHILD_SA with SPI 340d0612
2024-04-11T23:52:37 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> parsed INFORMATIONAL response 1 [ D ]
2024-04-11T23:52:37 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> received packet: from stronswanClient [6029] to fixeWANip[4500] (69 bytes)
2024-04-11T23:52:37 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> sending packet: from fixeWANip[4500] to stronswanClient [6029] (69 bytes)
2024-04-11T23:52:37 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> generating INFORMATIONAL request 1 [ D ]
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> sending DELETE for ESP CHILD_SA with SPI cbaa7fd0
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> closing CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{3} with SPIs cbaa7fd0_i (258522 bytes) 340d0612_o (0 bytes) and TS 0.0.0.0/0 === 10.0.1.1/32
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> outbound CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{5} established with SPIs c4f18030_i 5f3243a5_o and TS 0.0.0.0/0 === 10.0.1.1/32
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> inbound CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{5} established with SPIs c4f18030_i 5f3243a5_o and TS 0.0.0.0/0 === 10.0.1.1/32
2024-04-11T23:52:37 Informational charon 01[CFG] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> selected proposal: ESP:AES_GCM_16_256/CURVE_25519/NO_EXT_SEQ
2024-04-11T23:52:37 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> parsed CREATE_CHILD_SA response 0 [ SA No KE TSi TSr ]
2024-04-11T23:52:37 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> received packet: from stronswanClient [6029] to fixeWANip[4500] (225 bytes)
2024-04-11T23:52:37 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> sending packet: from fixeWANip[4500] to stronswanClient [6029] (245 bytes)
2024-04-11T23:52:37 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
2024-04-11T23:52:37 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|6> establishing CHILD_SA 2a98dee1-e9d4-4383-864c-f6a13058bdd6{5} reqid 1
2024-04-11T23:52:37 Informational charon 01[KNL] creating rekey job for CHILD_SA ESP/0x340d0612/stronswanClient
2024-04-11T23:52:19 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> parsed INFORMATIONAL response 8 [ ]
2024-04-11T23:52:19 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received packet: from stronswanClient [48476] to fixeWANip[4500] (57 bytes)
2024-04-11T23:52:18 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending packet: from fixeWANip[4500] to stronswanClient [48476] (57 bytes)
2024-04-11T23:52:18 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> generating INFORMATIONAL request 8 [ ]
2024-04-11T23:52:18 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending DPD request
2024-04-11T23:51:25 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> parsed INFORMATIONAL response 7 [ ]
2024-04-11T23:51:25 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> received packet: from stronswanClient [48476] to fixeWANip[4500] (57 bytes)
2024-04-11T23:51:25 Informational charon 01[NET] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending packet: from fixeWANip[4500] to stronswanClient [48476] (57 bytes)
2024-04-11T23:51:25 Informational charon 01[ENC] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> generating INFORMATIONAL request 7 [ ]
2024-04-11T23:51:25 Informational charon 01[IKE] <5464e5a3-4a97-451f-b78f-8d18855e6188|8> sending DPD request


Clone ich die IPsec ECC Curve25519 Connection, und ändere nur auf Curve448 habe ich sofort die aufgelisteten Fehler.
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 12, 2024, 08:11:25 AM
Ich weiß leider nicht woran es liegt. Ich benutze die Einstellungen aus der Anleitung produktiv bei Kunden. Ich hätte sehr schnell viele Anrufe wenn die so Probleme hätten.

Vielleicht liegt es an den Proposals in der Cipher Suite. Die vorgeschlagenen in der Anleitung sind eigentlich gerade die Safe Defaults die man verwenden kann. Das hackt einem keiner mal eben so aus der Hüfte.

Vielleicht macht ein Pool mit /30 irgendwelche Probleme beim Routing wenn ihn mehrere Clients verwenden. Verwende mal einen /24 Pool.
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 12, 2024, 08:46:32 AM
ja ich finde Curve448 bzw. Curve25519 einfach zu sexy,
und will die unbedingt verwenden    ::) ;D

Ich taste mich heran  ;D 10.0.1.0/29, also mit 6 Hosts, 10.0.1.1 bis: 10.0.1.6
funktioniert es jetzt ohne Probleme (inkl. interner DNS-Einträge / Outbound) mit 2 Clients und Curve25519.

Interessant ist, dass es ein Problem mit /30 gibt, mit Legacy < 23.1 hatte ich auch /30 und hätte das mit dem internen DNS nicht bemerkt.

Danke!
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 12, 2024, 09:05:01 AM
Ja das ist sehr interessant.

Wenn es reproduzierbar ist, das /30 Probleme macht und es ab /29 immer funktioniert, kannst du in github gerne einen Pull Request bei der Anleitung machen mit einem kleinen

.. Attention::

https://github.com/opnsense/docs
https://github.com/opnsense/docs/blob/master/source/manual/how-tos/ipsec-swanctl-rw-ikev2-eap-mschapv2.rst
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: gongoscho on April 13, 2024, 11:18:33 AM
Danke, es wäre mir eine Ehre. :-)

Werde es aber vorher noch zu 100% verifizieren,
und eine zweite FW aufsetzen mit Standardeinstellungen + IPsec.

Was ist besser?

oder


grEEtZ
Title: Re: 24.1, Problem mit VPN: IPsec: Connections - Roadwarriors IKEv2 EAP-MSCHAPv2
Post by: Monviech (Cedrik) on April 13, 2024, 11:22:18 AM
Um so Sachen zu testen mach ich meistens eine neue saubere VM.
Text only | Text with Images