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
[email protected]
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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
