Closed tpimont closed 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.
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]:
So CHAP authentication works sometime and sometime not
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
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.
all my tests have been done with only mschap-v2 method in settings . I have not found a solution that works for now.
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.
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 ?
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
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.
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
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.
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
Actually after doing sudo modprobe l2tp_ppp
on Fedora, I'm able to make a VPN connection to Windows Server 2019.
Hi, I confirm that on Fedora when i do a sudo modprobe l2tp_ppp, vpn works . Thank you for your help
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
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 ?