<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>P.P.S.</p>
<p>I apologize for the table was garbled by Thunderbird, so I will
repost it as a snip:</p>
<p><img src="cid:part1.TDEB4uqG.uQBwD09c@alu.hr" alt=""></p>
<p>Sorry for the inconvenience.</p>
<p>Kind regards,<br>
Mirsad Todorovac<br>
</p>
<div class="moz-cite-prefix">On 1/14/2022 9:21 AM, Mirsad Goran
Todorovac wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e3f73e40-1006-e326-4cd8-24acb25f3928@alu.hr">P.S.
<br>
<br>
I am testing the stuff more thoroughly for interoperability. :-)
<br>
<br>
Apparently, it works like this compatibility matrix:
<br>
<br>
L2TP win 10 L2TP Android IKEv2 win10
IKEv2 Android multiple multiple
<br>
connect connect connect
connect L2TP IKEv2
<br>
<br>
4.5 USE_DH2=true + + + +
+ -
<br>
4.5 USE_DH2=false not tested
<br>
4.6 USE_DH2=true + + + +
+ -
<br>
4.6 USE_DH2=false + - + +
+ -
<br>
<br>
Android includes testing both on Samsung Galaxy A22 5G phone and
Tab S6 Lite tablet.
<br>
<br>
Apparently, concurrent 4.5 USE_DH2=true or IKEv2 doesn't work
either, so I may have to revert the settings from our accountant
to L2TP connection, despite being slower, for it seems awkward
that I might preempt his accounting session while testing the
stuff.
<br>
<br>
It seemed that I have a bit rushed things with the upgrade to
IKEv2, thinking that it will be safe just as L2TP setup?
<br>
Is there something I'm doing wrong in the ikev2.conf below, or is
it a bug in libreswan? It seems unlikely that such behavior was
left unnoticed until now, but at least it appears that it is not a
regression in 4.6 compared to 4.5. :-/
<br>
<br>
I hope this helps, and I am hoping there is a workaround or fix.
<br>
(I am currently testing concurrent L2TP from 3 devices for several
hours ...).
<br>
<br>
Kind regards,
<br>
Mirsad Todorovac
<br>
<br>
On 1/14/2022 7:08 AM, Mirsad Goran Todorovac wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
I can confirm that the IKEv2 connection was alive for the entire
night of testing:
<br>
<br>
000 #80: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in
27522s; newest; idle;
<br>
000 #81: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS
in 6s; EXPIRE in 28536s; newest; eroute owner; IKE SA #80; idle;
<br>
000 #81: "MYCONN-ikev2-cp"[2] 94.253.210.164
<a class="moz-txt-link-abbreviated" href="mailto:esp.a8ff51a4@94.253.210.164">esp.a8ff51a4@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:esp.303eb9bd@161.53.235.3">esp.303eb9bd@161.53.235.3</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@94.253.210.164">tun.0@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:tun.0@161.53.235.3">tun.0@161.53.235.3</a> Traffic: ESPin=1MB
ESPout=41MB ESPmax=0B
<br>
<br>
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:
<br>
<br>
000 #80: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in
27299s; idle;
<br>
000 #81: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); EXPIRE in
28313s; IKE SA #80; idle;
<br>
000 #81: "MYCONN-ikev2-cp"[2] 94.253.210.164
<a class="moz-txt-link-abbreviated" href="mailto:esp.a8ff51a4@94.253.210.164">esp.a8ff51a4@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:esp.303eb9bd@161.53.235.3">esp.303eb9bd@161.53.235.3</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@94.253.210.164">tun.0@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:tun.0@161.53.235.3">tun.0@161.53.235.3</a> Traffic: ESPin=2MB
ESPout=105MB ESPmax=0B
<br>
000 #83: "MYCONN-ikev2-cp"[2] 94.253.210.164:46855
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in
28745s; newest; idle;
<br>
000 #84: "MYCONN-ikev2-cp"[2] 94.253.210.164:46855
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS
in 5s; EXPIRE in 28745s; newest; eroute owner; IKE SA #83; idle;
<br>
000 #84: "MYCONN-ikev2-cp"[2] 94.253.210.164
<a class="moz-txt-link-abbreviated" href="mailto:esp.cf38d849@94.253.210.164">esp.cf38d849@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:esp.476cc068@161.53.235.3">esp.476cc068@161.53.235.3</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@94.253.210.164">tun.0@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:tun.0@161.53.235.3">tun.0@161.53.235.3</a> Traffic: ESPin=145KB
ESPout=10MB ESPmax=0B
<br>
<br>
Now I tested ping 8.8.8.8 and it is also down, while
whatismyipaddress.com shows that the Android tablet is
connected. :-/
<br>
<br>
The session log is here (only the interesting event, not the
entire night of testing):
<a class="moz-txt-link-freetext" href="https://domac.alu.hr/mtodorov/ikev2-20220113-03.log">https://domac.alu.hr/mtodorov/ikev2-20220113-03.log</a>
<br>
<br>
After I reconnected Windows 10, the Android device appears
kicked out ...
<br>
<br>
But it isn't shown in `ipsec showstates`, as it still believes
it has connection on both devices:
<br>
<br>
000 #83: "MYCONN-ikev2-cp"[2] 94.253.210.164:46855
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in
28290s; idle;
<br>
000 #84: "MYCONN-ikev2-cp"[2] 94.253.210.164:46855
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); EXPIRE in
28290s; IKE SA #83; idle;
<br>
000 #84: "MYCONN-ikev2-cp"[2] 94.253.210.164
<a class="moz-txt-link-abbreviated" href="mailto:esp.cf38d849@94.253.210.164">esp.cf38d849@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:esp.476cc068@161.53.235.3">esp.476cc068@161.53.235.3</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@94.253.210.164">tun.0@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:tun.0@161.53.235.3">tun.0@161.53.235.3</a> Traffic: ESPin=864KB
ESPout=12MB ESPmax=0B
<br>
000 #86: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); EXPIRE in
28667s; newest; idle;
<br>
000 #87: "MYCONN-ikev2-cp"[2] 94.253.210.164:4500
STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS
in 17s; EXPIRE in 28667s; newest; eroute owner; IKE SA #86;
idle;
<br>
000 #87: "MYCONN-ikev2-cp"[2] 94.253.210.164
<a class="moz-txt-link-abbreviated" href="mailto:esp.2dcf960@94.253.210.164">esp.2dcf960@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:esp.ea55d21d@161.53.235.3">esp.ea55d21d@161.53.235.3</a>
<a class="moz-txt-link-abbreviated" href="mailto:tun.0@94.253.210.164">tun.0@94.253.210.164</a> <a class="moz-txt-link-abbreviated" href="mailto:tun.0@161.53.235.3">tun.0@161.53.235.3</a> Traffic: ESPin=2MB
ESPout=9MB ESPmax=0B
<br>
<br>
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?
<br>
<br>
I hope any of this helps.
<br>
<br>
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.
<br>
<br>
Kind regards,
<br>
Mirsad Todorovac
<br>
<br>
On 1/13/2022 11:36 PM, Mirsad Goran Todorovac wrote:
<br>
<blockquote type="cite">Hello,
<br>
<br>
I tried to summarize in the title, and so far I have been able
to associate the teardown of Windows 10 data stream with a
simultaneous IKEv2 connection that came during the test signal
(live TV stream) from an Android tablet on our test Linux
server.
<br>
<br>
The Windows laptop had no realtime stream and neither DNS
resolution. I did not check ping, but I suspect it wouldn't
pass either by the symptoms.
<br>
<br>
This time I compiled without the USE_DH2=true and used it with
ms-dh-downgrade=true.
<br>
<br>
conn MYCONN-ikev2-cp
<br>
# The server's actual IP goes here - not elastic IPs
<br>
left=161.53.235.3
<br>
leftcert=vpn.alu.hr
<br>
<a class="moz-txt-link-abbreviated" href="mailto:leftid=@vpn.alu.hr">leftid=@vpn.alu.hr</a>
<br>
leftsendcert=always
<br>
leftsubnet=0.0.0.0/0
<br>
leftrsasigkey=%cert
<br>
# Clients
<br>
right=%any
<br>
# your addresspool to use - you might need NAT rules
if providing full internet to clients
<br>
rightaddresspool=192.168.101.10-192.168.101.253
<br>
# optional rightid with restrictions
<br>
rightid="O=ALU-UNIZG,CN=win7client.alu.hr"
<br>
rightca=%same
<br>
rightrsasigkey=%cert
<br>
#
<br>
# connection configuration
<br>
# DNS servers for clients to use
<br>
modecfgdns=8.8.8.8,192.168.100.1
<br>
# Versions up to 3.22 used modecfgdns1 and modecfgdns2
<br>
#modecfgdns1=8.8.8.8
<br>
#modecfgdns2=193.110.157.123
<br>
narrowing=yes
<br>
# recommended dpd/liveness to cleanup vanished clients
<br>
dpddelay=30
<br>
dpdtimeout=120
<br>
dpdaction=clear
<br>
auto=add
<br>
ikev2=insist
<br>
rekey=no
<br>
esp=aes_gcm256,aes_gcm128,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1
<br>
#
esp=aes_gcm256-null,aes_gcm128-null,aes256-sha2_512,aes128-sha2_512,aes256-sha1,aes128-sha1,aes_gcm256-null;modp1024<br>
# ikev2 fragmentation support requires libreswan 3.14
or newer
<br>
fragmentation=yes
<br>
# optional PAM username verification (eg to implement
bandwidth quota
<br>
# pam-authorize=yes
<br>
ms-dh-downgrade=yes
<br>
authby=rsa-sha1
<br>
<br>
Both the `ipsec showstates` and Windows 10 did not reflect
that the data stream was interrupted, and eithe had Android.
<br>
<br>
Here is the session log 1 and log2.
<br>
The interesting part is probably close to the end of both
logs.
<br>
<br>
[1] <a class="moz-txt-link-freetext" href="https://domac.alu.hr/mtodorov/ikev2-20220113-01.log">https://domac.alu.hr/mtodorov/ikev2-20220113-01.log</a>
<br>
[2] <a class="moz-txt-link-freetext" href="https://domac.alu.hr/mtodorov/ikev2-20220113-02.log">https://domac.alu.hr/mtodorov/ikev2-20220113-02.log</a>
<br>
<br>
I will supply more information as I am testing. I wonder if
this is related to removal of USE_DH2=true from the
compilation or will the connection be stable unless there is
an interference from another (Android) client. The Android had
also lost connectivity, though the wizard said "Connected".
<br>
<br>
Hope this helps. I would have to revert to 4.5 and
USE_DH2=true and I don't think it would be prudent to move it
to the production VPN until we resolve such issues :-/
<br>
<br>
The accountant guy would think I'm incompetent if his VPN
connection breaks in the middle of accounting salaries :-(
<br>
<br>
Any idea?
<br>
<br>
Kind regards,
<br>
Mirsad
<br>
<br>
-- <br>
Mirsad Goran Todorovac
<br>
CARNet sistem inženjer
<br>
Grafički fakultet | Akademija likovnih umjetnosti
<br>
Sveučilište u Zagrebu
<br>
</blockquote>
<br>
-- <br>
Mirsad Goran Todorovac
<br>
CARNet sistem inženjer
<br>
Grafički fakultet | Akademija likovnih umjetnosti
<br>
Sveučilište u Zagrebu
<br>
</blockquote>
<br>
</blockquote>
<pre class="moz-signature" cols="72">--
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</pre>
</body>
</html>