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

Mirsad Goran Todorovac mirsad.todorovac at alu.hr
Fri Jan 14 18:30:25 EET 2022


Hi, Paul!

Yes, it seems that I have been naively using the same client cert for 
all connecting devices, interpreting literally what is given on 
libreswan Wiki: 
https://libreswan.org/wiki/VPN_server_for_remote_clients_using_IKEv2#Example_certificate_generation_with_certutil

1. I have overlooked the comment ("#") sign before rightid parameter in 
ikev2.conf
2. I was lazy enough to think that I will get away with the same single 
certificate for all clients, as took literally the generic name 
win7client.example.org ... OMG.

I have just tested the minimum setup with two devices and two different 
certificates, and it appears to work :-)

There should be a note about this requirement on the Wiki for us 
one-track-minds ;-)

Thank you very much. You have saved the day before the weekend :-)

Kind regards,
Mirsad

P.S.

Here is the request ip xfrm state; ip xfrm policy; but I think it is 
obsoleted now: 
https://domac.alu.hr/mtodorov/ikev2-20220114-xfrm-state+policy-01.log

On 1/14/2022 4:21 PM, Paul Wouters wrote:
> 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

-- 
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355



More information about the Swan mailing list