search

nm-l2tp / NetworkManager-l2tp

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

Windows Server L2TP compatibility issue with Fedora not Ubuntu #117

Closed tpimont closed 4 years ago

tpimont commented 4 years ago

Hi,

I setup a L2TP IPSEC connection to a windows server with certificates. with the last version 1.8.0 on ubuntu 18.04 connection is OK . I use same parameters on Fedora but on Fedora 31 or 32 the connection fail with this in logs :

pppd[4513]: Plugin /usr/lib64/pppd/2.4.7/nm-l2tp-pppd-plugin.so loaded. pppd[4513]: pppd 2.4.7 started by root, uid 0 pppd[4513]: Using interface ppp0 pppd[4513]: Connect: ppp0 <--> /dev/pts/1 NetworkManager[934]: [1578919319.3271] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/9) NetworkManager[4511]: xl2tpd[4511]: control_finish: Connection closed to X.X.X.144, serial 1 () pppd[4513]: Terminating on signal 15 pppd[4513]: Modem hangup pppd[4513]: Connection terminated. NetworkManager[4511]: xl2tpd[4511]: death_handler: Fatal signal 15 received charon[4474]: 14[KNL] interface ppp0 deleted NetworkManager[934]: [1578919319.3408] vpn-connection[0x559d3a83c2e0,ad5560a9-b9f9-44a9-a07f-3a4aa7d14351,"VPN 1",0]: VP> NetworkManager[934]: [1578919319.3409] vpn-connection[0x559d3a83c2e0,ad5560a9-b9f9-44a9-a07f-3a4aa7d14351,"VPN 1",0]: VP> NetworkManager[4518]: Stopping strongSwan IPsec...

Any idea ?

dkosovic commented 4 years ago

As it looks like something is going wrong with pppd, have a look at the "Increase Debugging Output" section in the README.md file. The increased pppd debugging output will be in the journalctl output.

Hopefully the increased debugging output might give us an idea as to what is going wrong.

tpimont commented 4 years ago

it works 1 time on 10 try, when it works the log is like this

janv. 14 07:15:14 localhost.localdomain pppd[5118]: Plugin /usr/lib64/pppd/2.4.7/nm-l2tp-pppd-plugin.so loaded. janv. 14 07:15:14 localhost.localdomain pppd[5118]: pppd 2.4.7 started by root, uid 0 janv. 14 07:15:14 localhost.localdomain pppd[5118]: Using interface ppp0 janv. 14 07:15:14 localhost.localdomain pppd[5118]: Connect: ppp0 <--> /dev/pts/1 janv. 14 07:15:14 localhost.localdomain NetworkManager[937]: [1579004114.8937] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/6) janv. 14 07:15:17 localhost.localdomain pppd[5118]: CHAP authentication succeeded janv. 14 07:15:19 localhost.localdomain charon[5064]: 15[KNL] 10.32.1.78 appeared on ppp0 janv. 14 07:15:19 localhost.localdomain charon[5064]: 05[KNL] 10.32.1.78 disappeared from ppp0 janv. 14 07:15:19 localhost.localdomain charon[5064]: 09[KNL] 10.32.1.78 appeared on ppp0 janv. 14 07:15:19 localhost.localdomain charon[5064]: 10[KNL] interface ppp0 activated janv. 14 07:15:19 localhost.localdomain pppd[5118]: local IP address 10.32.1.78 janv. 14 07:15:19 localhost.localdomain pppd[5118]: remote IP address 10.32.1.1

So CHAP authentication works sometime and sometime not

tpimont commented 4 years ago

For the CHAP authentication to work
First stop xl2tpd service. Then try a connection failed. Try another connection OK. All other connection failed until you stop xl2tpd another time

dkosovic commented 4 years ago

It might not be the original CHAP, MS-CHAPv2 is typically the one that produces the "CHAP authentication succeeded" pppd output. In the PPP settings dialog box, you could try disabling all the authentication methods other than MSCHAPv2. Some VPN servers claim they support more than MS-CHAPv2 but haven't been configured properly for the other authentication methods.

Fedora's default is for the system xl2tpd service to be disabled and stopped, while Ubuntu has it enabled and running. NetworkManager-l2tp starts its own instance of xl2tpd and will kill its own instance when the connection goes down or hasn't been established. See "Issue with not stopping system xl2tpd service" in the README.md file. I would recommend sticking to the Fedora default of having the system xl2tpd service disabled, otherwise an ephemeral port (i.e. random high port) will be used as mentioned in the README.md file.

I've noticed there are a lot of VPN servers and/or firewalls out there that will unfortunately block a L2TP client if it is using an ephemeral port on the client side, yet will accept a L2TP connection that is not encapsulated in IPsec, which for most cases they shouldn't be allowing. Not implying both are related, just that both are common.

tpimont commented 4 years ago

all my tests have been done with only mschap-v2 method in settings . I have not found a solution that works for now.

dkosovic commented 4 years ago

If the system xl2tpd service isn't running, the only other thing I could think of is the kernel. Some kernel updates in the past have broken xl2tpd (note: xl2tpd is was starts the pppd process).

Last night I installed Fedora 31 in a VM and did a sudo dnf update to get the latest packages and haven't been able to reproduce the issue. So it might not be an issue with the latest kernel, but no harm in trying an older kernel.

tpimont commented 4 years ago

It's like when you untick all ppp authentication except mschap-v2 , ppp continue to use CHAP . can you add a option to refuse-chap in the PPP settings ?

tpimont commented 4 years ago

In the Windows server log with Fedora client i have this event : Remoteaccess eventid 20262 Cannot reconize initial frame line has been disconnect. Error description is : Check the credentials of the remote access client . Login and password are good there is something wrong with ppp authentication in Fedora but i dont no what is wrong

dkosovic commented 4 years ago

It you enable debugging mode as described in the README.md file, the run-time generated /var/run/nm-l2tp-UUID/ppp-options file won't get deleted. (note: replace UUID with the actual UUID used in the filename). Can you confirm if an authentication type is disabled in the PPP settings dialog box, then you see the corresponding refuse- option in the generated ppp-options file like it should be?

You can see the refuse- authentication options that are handled in the following section of the source code:

The Fedora pppd package has lots Fedora patches :

ppp also uses PPP kernel modules.

So although the ppp version number is the same as on Ubuntu, perhaps some patch only applied on Fedora is the problem or a kernel module in a later kernel might have broken something.

tpimont commented 4 years ago

content of the file ppp-options: debug ipparam nm-l2tp-service-xxxxxxxxxxx nodetach usepeerdns no ipdefault nodefaultroute noauth refuse-eap refuse-pap refuse-chap refuse-mschap lcp-echo-failure 5 lcp-echo interval 30 plugin /var/lib64/pppd/2.4.7/nm-l2tp-pppd-plugin.so mru 1400 mtu 1400

dkosovic commented 4 years ago

I setup RRAS on Windows Server 2019 and was able to reproduce the issue with Fedora 31.

I see the following error in the xl2tpd logs:

xl2tpd[2727]: L2TP kernel support not detected (try modprobing l2tp_ppp and pppol2tp)

then trying to do what it suggests:

$ sudo modprobe l2tp_ppp

$ sudo modprobe pppol2tp
modprobe: FATAL: Module pppol2tp not found in directory /lib/modules/5.4.8-200.fc31.x86_64

Not sure why the pppol2tp kernel module is missing.

So I'm guessing the VPN is working for you on Ubuntu as you are using Linux kernel PPP over L2TP instead of the userspace fallback implementation that you are using on Fedora with xl2tpd.

It is interesting how it breaks with Win2019, but not other VPN servers.

tpimont commented 4 years ago

Glad to see that you can reproduce the issue, thanks for your help. i'm searching if i can find a solution with the module on Fedora

dkosovic commented 4 years ago

Actually after doing sudo modprobe l2tp_ppp on Fedora, I'm able to make a VPN connection to Windows Server 2019.

tpimont commented 4 years ago

Hi, I confirm that on Fedora when i do a sudo modprobe l2tp_ppp, vpn works . Thank you for your help

dkosovic commented 4 years ago

The following is an extract from "Enhanced security of auto-loading kernel modules in RHEL 8 " web page (which requires a login to view) :

To enhance Red Hat Enterprise Linux against possible future security vulnerabilities in lesser-known components which system administrators typically do not protect against, a set of kernel modules have been moved to the kernel-modules-extra package so they are not installed by default, and blacklisted by default so those components cannot be loaded by non-root users.

When a system requires use of one of these kernel modules, the system administrator must install the kernel-modules-extra package and explicitly remove the module blacklist.

Although the above was for RHEL8, it is also applicable to Fedora >= 31. The /etc/modprobe.d/l2tp_netlink-blacklist.conf file contains:

# Remove the blacklist by adding a comment # at the start of the line.
blacklist l2tp_netlink

The /etc/modprobe.d/l2tp_ppp-blacklist.conf file contains :

# Remove the blacklist by adding a comment # at the start of the line.
blacklist l2tp_ppp

To remove the blacklist of the L2TP modules by adding a # comment to the blacklist lines can be achieved with:

sudo sed -e '/blacklist l2tp_netlink/s/^b/#b/g' -i /etc/modprobe.d/l2tp_netlink-blacklist.conf
sudo sed -e '/blacklist l2tp_ppp/s/^b/#b/g' -i /etc/modprobe.d/l2tp_ppp-blacklist.conf