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