search

nm-l2tp / NetworkManager-l2tp

L2TP and L2TP/IPsec support for NetworkManager
GNU General Public License v2.0
488 stars 84 forks source link

L2TP/IPsec broken with kernel 4.14 #72

Closed OlliC closed 5 years ago

OlliC commented 6 years ago

Hi,

i have a problem with my connection to a L2TP/IPsec Microsoft server. I am using networkmanager-l2tp 1.2.8-1 installed from the AUR on Arch Linux on Gnome. The connection worked a week ago, but started to fail without changing anything on my end beyond the usual system updates. I use strongswan and from the logs it looks like the ipsec connection is established succesfully, then xl2tpd gets started and after that charon logs the following and the connection gets aborted: 

Dez 08 21:47:58 viki charon[13171]: 10[KNL] creating acquire job for policy xxx.xxx.x.xx/32[udp/l2f] === xx.xx.xxx.xxx/32[udp/l2f] with reqid {1}
Dez 08 21:47:58 viki charon[13171]: 09[CFG] trap not found, unable to acquire reqid 1

I also have a Fedora Laptop where i use networkmanager-l2tp with libreswan and there the connection still works with no problems. So i guess some Arch Linux update introduced this problem.

Does somebody has an idea what the problem could be?

dkosovic commented 6 years ago

It looks like an issue with the kernel 4.14 update :

Possible workarounds include :

OlliC commented 6 years ago

Ok so its a kernel regression which will probably get fixed very fast. Then i will probably use the LTS kernel for a while and wait until its fixed. Thanks

dkosovic commented 6 years ago

I'm reopening this issue in case others come looking. Was hoping the kernel 4.14 branch would have had a fix by now. At the time of writing, kernel 4.14.12 is still broken. Will close this issue after the kernel 4.14 branch has a fix.

This bug is a result of the following commit to linux-stable for kernel 4.14 :

That kernel 4.14 commit breaks IPsec transportation mode when a wildcard address is used on the client side as is the case with NetworkManager-l2tp. The commit was reverted in kernel-4.15-rc1 :

Unfortunately the reverted commit reintroduces a stack out-of-bounds bug. We might need to wait after kernel 4.15 is released for the kernel 4.14 branch to get a fix. More details in this netdev linux kernel mailing list thread :

mar-io commented 6 years ago

I was pulling my hair out for better part of day until I saw this thread. So thanks!

I ran into issue on Fedora 26/27. I reverted back to the 4.13.16-302 kernel and got things running for me.

OlliC commented 6 years ago

Its working again on Arch with kernel 4.14.13.

dkosovic commented 6 years ago

Indeed, the patch officially landed in kernel 4.14.13.

I'll keep this issue open for a few weeks so others can see it. Will probably add something to the known issues at some stage.

mar-io commented 6 years ago

This is also resolved with 4.14.14 kernel release on Fedora 27.

dkosovic commented 6 years ago

Later versions of kernel 4.14 now break xl2tpd because of a different bug backported from kernel 4.15, see issue #79 .

kuraga commented 5 years ago

Is that this issue?

Nov  7 11:03:48 node-calculate2 charon[14776]: 00[DMN] Starting IKE charon daemon (strongSwan 5.7.1, Linux 4.18.14-calculate, x86_64)
Nov  7 11:03:48 node-calculate2 charon[14776]: 00[KNL] unable to create IPv4 routing table rule
Nov  7 11:03:48 node-calculate2 charon[14776]: 00[KNL] unable to create IPv6 routing table rule

(StrongSwan doesn;'t work and gives after that:

Nov  7 11:03:49 node-calculate2 charon[14776]: 12[ENC] generating ID_PROT request 0 [ SA V V V V V ]
Nov  7 11:03:49 node-calculate2 charon[14776]: 12[NET] sending packet: from 192.168.1.71[500] to 62.212.72.204[500] (204 bytes)
Nov  7 11:03:53 node-calculate2 charon[14776]: 13[IKE] sending retransmit 1 of request message ID 0, seq 1
Nov  7 11:03:53 node-calculate2 charon[14776]: 13[NET] sending packet: from 192.168.1.71[500] to 62.212.72.204[500] (204 bytes)
Nov  7 11:03:59 node-calculate2 charon[14776]: 00[DMN] signal of type SIGINT received. Shutting down
Nov  7 11:03:59 node-calculate2 charon[14776]: 00[IKE] destroying IKE_SA in state CONNECTING without notification
Nov  7 11:03:59 node-calculate2 ipsec_starter[14775]: child 14776 (charon) has quit (exit code 0)

. LibreSwan works fine.)

dkosovic commented 5 years ago

I think it is an unreleated issue, the original kernel 4.14 issue mentioned here was fixed with kernel 4.14.13. It affected both strongswan and libreswan.

The second kernel 4.14 issue described here affected xl2tpd < 1.3.12.

Your issue is something different, it might be related to the following :

as it also has the suspicious looking [KNL] unable to create IPv4 routing table rule in the logs, but not sure.

Might be best to submit a new strongswan issue on :