[Swan] USE_DH2 Re: 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 23:26:04 EET 2022
On 1/14/2022 9:59 PM, Paul Wouters wrote:
> On Fri, 14 Jan 2022, Mirsad Goran Todorovac wrote:
>
>>> 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).
>>
>> Experiment proves otherwise. I have made two parallel compiles,
>> USE_DH2=true and USE_DH2=false. Then `make install; ipsec restart`
>> from each directory, each time attempting to connect L2TP with PSK
>> from Android 11 native client. The result is interesting:
>> USE_DH2=false version could not connect, and the othe one could.
>>
>> Proof of the concept is in the logs (as the proverb sayeth "if the
>> goat is lying, the horn isnt" :)
>>
>> [1] https://domac.alu.hr/mtodorov/l2tp-20220114-dh2=true-01.log
>> (connected)
>
> Jan 14 21:26:14.344385: | af+type: AF+OAKLEY_GROUP_DESCRIPTION
> (0x8004)
> Jan 14 21:26:14.344392: | length/value: 2 (00 02)
> Jan 14 21:26:14.344401: | [2 is OAKLEY_GROUP_MODP1024]
> Jan 14 21:26:14.344409: | OAKLEY proposal verified unconditionally; no
> alg_info to check against
> Jan 14 21:26:14.344417: | Oakley Transform 1 accepted
>
> You accepted modp1024/dh2, but:
>
> v3.19 (January 15, 2017)
> [...]
> * pluto: drop modp1024 (DH2) from IKEv1 "ike=" default list [Andrew]
>
> So you must have had an ike= line in your config. If you do, then indeed
> it would work, but the unmodified config would also fail to load the
> connection if it tried to add dh2 to its valid options.
>
>> [2] https://domac.alu.hr/mtodorov/l2tp-20220114-nodh2-01.log
>> (unsuccessful)
>
> Jan 14 21:22:05.126170: | ******parse ISAKMP Oakley attribute:
> Jan 14 21:22:05.126178: | af+type: AF+OAKLEY_GROUP_DESCRIPTION
> (0x8004)
> Jan 14 21:22:05.126201: | length/value: 2 (00 02)
> Jan 14 21:22:05.126211: | [2 is OAKLEY_GROUP_MODP1024]
> Jan 14 21:22:05.126225: "L2TP-PSK-NAT"[1] 94.253.210.164 #2:
> OAKLEY_GROUP 2 not supported. Attribute OAKLEY_GROUP_DESCRIPTION
>
> Your connection however loaded, so it must NOT have specified dh2 in
> ike= or it would have failed to load, and with no L2TP-PSK-NAT
> connection loaded would get a different error (NO_PROPOSAL_CHOSEN)
I did not get that exactly. Despite my learning curve getting better, I
am only succeeded L2TP w libreswan on 2021-11-24. These were interesting
60 days, but I am not familiar with libreswan internals.
Apparently, I do not change default ike= and esp= with L2TP, and my
compilation was default parms + USE_DH2:
conn L2TP-PSK-NAT
rightsubnet=vhost:%priv
also=L2TP-PSK-common
conn L2TP-PSK-noNAT
rightsubnet=vhost:%no
also=L2TP-PSK-common
conn L2TP-PSK-common
# Use a Preshared Key. Disable Perfect Forward Secrecy.
authby=secret
pfs=no
auto=add
keyingtries=3
# we cannot rekey for %any, let client rekey
rekey=no
# Apple iOS doesn't send delete notify so we need dead peer
detection
# to detect vanishing clients
dpddelay=10
dpdtimeout=30
dpdaction=clear
# Set ikelifetime and keylife to same defaults windows has
ikelifetime=8h
keylife=1h
ikev2=never
# l2tp-over-ipsec is transport mode
type=tunnel
#
# left will be filled in automatically with the local address
of the default-route interface (as determined at IPsec startup time).
left=%defaultroute
#
# For updated Windows 2000/XP clients,
# to support old clients as well, use leftprotoport=17/%any
leftprotoport=17/1701
#
# The remote user.
#
right=%any
# Using the magic port of "%any" means "any one single port".
This is
# a work around required for Apple OSX clients that use a randomly
# high port.
rightprotoport=17/%any
Mirsad
--
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