Could be related: http://forums.openl2tp.org/viewtopic.php?f=4&t=8&sid=8ec681ed31504c48dfffda5c9595acb9

Not sure if it is related to the bug mentioned on forums.openl2tp.org, as in that case the following route is manually added after the L2TP connection is established:

    route add remote-eth-ip dev ppp0

which isn't required and is in addition to the automatically created L2TP Point-to-Point route.

I'll try and give you some instructions later today on how to test with xl2tpd which doesn't use kernel L2TP module and see if you are still able to reproduce issue.

The L2TP kernel module has be associated with freezes like with the following bug:
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807010

Could you try uninstalling the system xl2tpd, then do a local build and install of a vanilla xl2tpd to /usr/local/ by doing the following:

----

sudo dnf install libpcap-devel

sudo rpm -e --nodeps xl2tpd

wget https://github.com/xelerance/xl2tpd/archive/v1.3.8/xl2tpd-1.3.8.tar.gz
tar xvzf xl2tpd-1.3.8.tar.gz
cd xl2tpd-1.3.8
make
sudo make install

----

Then try doing a NetworkManager-l2tp connection. I suspect you'll have the same issue as the system xl2tpd as it is still using the pppol2tp kernel module. The vanilla xl2tpd won't have the kernel SAref support patch from the Fedora xl2tpd source RPM..

If it doesn't work, disable the use of the pppol2tp kernel module by editing the xl2tpd-1.3.8 source's Makefile by commenting out the line that contains:

   OSFLAGS+= -DUSE_KERNEL

then rebuild and reinstall xl2tpd with:


----

make clean
make
sudo make install


----

Then try redoing a NetworkManager-l2tp connection and see how you go.


You can always reinstall the system xl2tpd with :
   sudo dnf install xl2tpd

I tried compiling xl2tpd-1.3.8 and system still hanged. Recompiled version without USE_KERNEL does not freeze the system. (Although I was unable to access resources in the target network and modify routing table for ppp0 — but this might be a different issue and/or me being wrong in my attempts to change routes. On windows it works, though).

With NetworkManager-l2tp, the routes for dev ppp0 will look something like :

$ ip route
default dev ppp0 proto static scope link metric 50 
123.54.76.8 dev ppp0  proto kernel  scope link  src 192.168.67.165  metric 50
...


The default route listed above will force all traffic over the VPN connection. It can be disabled in the VPN connection's IPv4 Settings by clicking Routes and ticking "Ignore automatically obtained routes".

If you add any new routes, use 123.54.76.8 (but your equivalent) as the gateway and don't use dev ppp0, e.g :

   sudo ip route add {remote-net} via 123.54.76.8 metric 60

where {remote-net} is whatever remote network is you want to reach. You can also set the routes in the IPv4 Settings instead of the command-line.

There are default routes just as you described. traceroute shows * * * for all hops, and I can't ping the gateway (123.54.76.8). My IP on ppp0 is being assigned correctly, though.

Since this bug is likely not related to the NetworkManager-l2tp component (NM L2TP integration), should I close it and reopen it for other component? If so, could you please suggest where this bug goes — kernel or xl2tpd?

I would re-assign the bug to kernel to see what kernel guys think about the issue.

I have found this reports that might be related:
https://bugzilla.kernel.org/show_bug.cgi?id=83661
https://bbs.archlinux.org/viewtopic.php?id=212648

Vlad, sorry for not responding last month, I was already on holiday leave with your last two messages and then lost track of them when I got back.

I agree with Blueowl, but would probably recommend lodging a new bug with kernel component and refer back to this one. Maybe have "pppol2tp kernel module completely freezes system" for the bug title. But I have no strong feelings in any case.

Regarding the routing issue, could be firewalld related, ESP packets might not be allowed through, etc.

Thank you for answer, I'll open a new bug.