[Swan] Libreswan 4.6: connection IKEv2 win10 to Linux freezes soon after Android device connects

Paul Wouters paul at nohats.ca
Fri Jan 14 17:21:34 EET 2022


On Fri, 14 Jan 2022, Mirsad Goran Todorovac wrote:

> Subject: Re: [Swan] Libreswan 4.6: connection IKEv2 win10 to Linux freezes
>     soon after Android device connects

Are you using the same single certificate or ID/PSK ? In that case the
second connection would replace the first one.

>>  Less than 10 seconds from initiating IKEv2 connection from the Android
>>  tablet (Samsung Galaxy Tab S6 Lite), the connection was severed. But both
>>  ends still think it is connected:

It might be useful to see "ip xfrm state" and "ip xfrm policy" just
after this has happened. Then we can see if there is truly one set of
IPsec kernel state, 2 sets, or a buggy 1.5 set or something ?

>>  The session log is here (only the interesting event, not the entire night
>>  of testing): https://domac.alu.hr/mtodorov/ikev2-20220113-03.log
>>
>>  After I reconnected Windows 10, the Android device appears kicked out ...

This log only shows the windows connect, not the android one before. So
I cannot see if they use the same cert/ID ?

Jan 14 06:57:13.958547: "MYCONN-ikev2-cp"[2] 94.253.210.164 #83: sent IKE_SA_INIT reply {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_512 group=MODP2048}
Jan 14 06:57:14.150677: "MYCONN-ikev2-cp"[2] 94.253.210.164 #83: processing decrypted IKE_AUTH request: SK{IDi,CERT,CERTREQ,AUTH,CP,SA,TSi,TSr,N,N,N,N}
Jan 14 06:57:14.154771: "MYCONN-ikev2-cp"[2] 94.253.210.164 #83: ignoring CERTREQ payload that is not ASN1
Jan 14 06:57:14.156179: "MYCONN-ikev2-cp"[2] 94.253.210.164 #83: established IKE SA; authenticated using RSA with SHA1 and peer certificate 'CN=win7client.alu.hr, O=ALU-UNIZG' issued by CA 'CN=ALU-UNIZG CA, O=ALU-UNIZG'
Jan 14 06:57:14.176596: "MYCONN-ikev2-cp"[2] 94.253.210.164 #84: proposal 1:ESP=AES_GCM_C_256-DISABLED SPI=cf38d849 chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_256;ENCR=AES_GCM_C_128;ESN=DISABLED[first-match] 2:ESP:ENCR=AES_CBC_256;ENCR=AES_CBC_128;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_384_192;INTEG=HMAC_SHA2_256_128;INTEG=HMAC_SHA1_96;ESN=DISABLED
Jan 14 06:57:14.178323: "MYCONN-ikev2-cp"[2] 94.253.210.164 #84: established Child SA using #83; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.101.10-192.168.101.10:0-65535 0] {ESPinUDP=>0xcf38d849 <0x476cc068 xfrm=AES_GCM_16_256-NONE NATD=94.253.210.164:46855 DPD=active}

The CERTREQ is a little odd but apparently harmless. Did you get a
different IP on the android before, or did you also hand out
192.168.101.10 there?

>>  On average, we will have only one user on the VPN for the most times, but
>>  two accountants could accidentally kick out each other, couldn't they?

Two different connections, even from the same network, should not kick
each other out with IKEv2. It does happen for IKEv1 L2TP based connections
using IPsec transport mode behind the same NAT router, but IKEv2 uses tunnel
mode as your log line above shows as well.

>>  BTW, Android L2TP connection tested with 4.5 USE_DH2=true did not connect
>>  from Android, while it did from Windows 10. I would like to have them all
>>  running stable and symmetrically.

whether you compile USE_DH2 in or not should not make a difference,
unless you are changing the ike= or esp=/phase2alg= line to include
modp1024 (which you shouldn't).

>>>  conn MYCONN-ikev2-cp
>>>          # The server's actual IP goes here - not elastic IPs
>>>          left=161.53.235.3
>>>          leftcert=vpn.alu.hr
>>>          leftid=@vpn.alu.hr
>>>          leftsendcert=always
>>>          leftsubnet=0.0.0.0/0
>>>          leftrsasigkey=%cert
>>>          # Clients
>>>          right=%any
>>>          # your addresspool to use - you might need NAT rules if providing
>>>  full internet to clients
>>>          rightaddresspool=192.168.101.10-192.168.101.253
>>>          # optional rightid with restrictions
>>>          rightid="O=ALU-UNIZG,CN=win7client.alu.hr"

Wait, you cannot specify a rightid to be one client ? That would mean
you are using the same certificate on both clients. In that case,
libreswan assumes it is the same client reconnecting again and per
default it does not allow a client to be connected multiple times at
once.

You should leave out rightid=

Paul


More information about the Swan mailing list