Hello again,
1. FYI, I can confirm that my Android 11 Samsung Galaxy A22 5G & Tab S6
Lite devices connected successfully over IKEv2, together with Win10
laptop, all at the same time (two over the same NAT and one over 4G ISP).
2. I would like to test the interoperability of ECDSA certs with IKEv2,
Win 10, Android and maybe even iOS devices when I get some for testing
... also a Linux desktop client comes to mind ... but I miss the
reference material and Google is not revealing much ...
Thank for the help with certs. :-)
Kind regards,
Mirsad
Command output: ipsec showstates
Every 1.0s: ipsec showstates domac: Fri Jan 14 20:48:31 2022
000 #11: "MYCONN-ikev2-cp"[9] 94.253.210.164:48431
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in 26274s;
newest; idle;
000 #12: "MYCONN-ikev2-cp"[9] 94.253.210.164:48431
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS in 24s;
EXPIRE in 26274s; newest; eroute owner; IKE SA #11; idle;
000 #12: "MYCONN-ikev2-cp"[9] 94.253.210.164 [email protected]
[email protected] [email protected] [email protected]
Traffic: ESPin=5MB ESPout=7MB ESPmax=0B
000 #16: "MYCONN-ikev2-cp"[13] 95.168.121.8:10515
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in 28693s;
newest; idle;
000 #17: "MYCONN-ikev2-cp"[13] 95.168.121.8:10515
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS in 13s;
EXPIRE in 28693s; newest; eroute owner; IKE SA #16; idle;
000 #17: "MYCONN-ikev2-cp"[13] 95.168.121.8 [email protected]
[email protected] [email protected] [email protected] Traffic:
ESPin=130KB ESPout=114KB ESPmax=0B
000 #18: "MYCONN-ikev2-cp"[14] 94.253.210.164:4500
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in 28774s;
newest; idle;
000 #19: "MYCONN-ikev2-cp"[14] 94.253.210.164:4500
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS in 4s;
EXPIRE in 28774s; newest; eroute owner; IKE SA #18; idle;
000 #19: "MYCONN-ikev2-cp"[14] 94.253.210.164
[email protected] [email protected]
[email protected] [email protected] Traffic: ESPin=32KB ESPout=212KB
ESPmax=0B
Here is the requested ip xfrm state:
root@domac:~# ip xfrm state
src 94.253.210.164 dst 161.53.235.3
proto esp spi 0x36cacf34 reqid 16457 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha1) 0x35a2f61689251af851fd7d84d718eef34b8aaf65 96
enc cbc(aes)
0x80a8c387a21e62723a5d4c439b3650679cd345b59025d982842842892a403b98
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x2c3, oseq-hi 0x0, oseq 0x0
replay_window 128, bitmap-length 4
ffffffff ffffffff ffffffff ffffffff
src 161.53.235.3 dst 94.253.210.164
proto esp spi 0x5c13a8d6 reqid 16457 mode tunnel
replay-window 0 flag af-unspec
auth-trunc hmac(sha1) 0x15e970d4399c87a75a7a67fd608ce7a97b1cb9c9 96
enc cbc(aes)
0xaa30d8c7c1a5c47713a1e52e4037b4b62490986b1174e24062cf5a27e979b5f3
encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x2f8
replay_window 128, bitmap-length 4
00000000 00000000 00000000 00000000
src 95.168.121.8 dst 161.53.235.3
proto esp spi 0x62b4187f reqid 16453 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0xe623603bff4f28862c581e45e8f50d6613839afc2b69e121048c6cff5d835715c9f579e8
128
encap type espinudp sport 10515 dport 4500 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x4ca, oseq-hi 0x0, oseq 0x0
replay_window 128, bitmap-length 4
ffffffff ffffffff ffffffff ffffffff
src 161.53.235.3 dst 95.168.121.8
proto esp spi 0xcb62e254 reqid 16453 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0x48cecea37cd4b5be49d7bd4e2e9e3dc269eb97eb3b61020b3c1f5094eaed65cbf58217fc
128
encap type espinudp sport 4500 dport 10515 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x47a
replay_window 128, bitmap-length 4
00000000 00000000 00000000 00000000
src 94.253.210.164 dst 161.53.235.3
proto esp spi 0x792eba17 reqid 16437 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0x8c010ba482454b9ccc37ebb6518bc057418fe46f6fdd53382675916dccb67323ac01e0e2
128
encap type espinudp sport 48431 dport 4500 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x48ac, oseq-hi 0x0, oseq 0x0
replay_window 128, bitmap-length 4
ffffffff ffffffff ffffffff ffffffff
src 161.53.235.3 dst 94.253.210.164
proto esp spi 0xc9e906e1 reqid 16437 mode tunnel
replay-window 0 flag af-unspec
aead rfc4106(gcm(aes))
0xf7f336578771e8355fb07a30163847a66b4c808422257d4ec7a9d3f68649c74ec6eebf54
128
encap type espinudp sport 4500 dport 48431 addr 0.0.0.0
anti-replay esn context:
seq-hi 0x0, seq 0x0, oseq-hi 0x0, oseq 0x4a4e
replay_window 128, bitmap-length 4
00000000 00000000 00000000 00000000
root@domac:~#
I still can't interpret what is "transport" in `ip xfrm policy` when I
have 3 IKEv2 tunnel conns?
Kind regards,
Mirsad
On 1/14/2022 5:30 PM, Mirsad Goran Todorovac wrote:
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
