On 1/9/2022 8:42 PM, Paul Wouters wrote:
On Sun, 9 Jan 2022, Mirsad Goran Todorovac wrote:
That's because most likely your l2tp layer went through userland
xl2tpd.
it can be configured to use kernel l2tp.ko but that usually has
issues.
I have tried to deploy kernel mode L2TP, but I failed. What I get
from xl2tpd is:
xl2tpd has not been well maintained in the last 10 years. They have
repeatedly broken things and accepted untested patches that solve one
user's problem, without having a test suite.
I wouldn't attempt to try xl2tpd anymore. And there are no other better
l2tp daemons either - openl2tp also had issues.
I'm sorry to hear this. For correctness sake, I sort of wanted to have
this working :(
I think I could write a paper on this comparison if I manage to get
both protocols IKEv1 and IKEv2 running under same conditions?
The comparison can really just say "l2tp kernel supposedly faster but
has been abandoned and sees no real use cases anymore and does not work
out of the box".
I guess it could, as I would stress the benefits of using IKEv2 together
with the availability of kernel mode encryption (which is also the default).
I understand that there is no real interest in debugging xl2tpd as IKEv2
is now preferred.
Thank you for the clarification, so I waste no more time trying to
figure it out :)
Kind regards,
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
