[Swan] Libreswan 4.6: connection IKEv2 win10 to Linux freezes soon after Android device connects
Mirsad Goran Todorovac
mirsad.todorovac at alu.unizg.hr
Fri Jan 14 22:06:17 EET 2022
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 esp.c9e906e1 at 94.253.210.164
esp.792eba17 at 161.53.235.3 tun.0 at 94.253.210.164 tun.0 at 161.53.235.3
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 esp.cb62e254 at 95.168.121.8
esp.62b4187f at 161.53.235.3 tun.0 at 95.168.121.8 tun.0 at 161.53.235.3 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
esp.5c13a8d6 at 94.253.210.164 esp.36cacf34 at 161.53.235.3
tun.0 at 94.253.210.164 tun.0 at 161.53.235.3 Traffic: ESPin=32KB ESPout=212KB
ESPmax=0B
Here is the requested ip xfrm state:
root at 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 at 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
>>>>> 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