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