Description of problem: VPN connection over PPTP broken after kernel update to 4.7.2 from 4.6.7. Booting back to 4.6.7 kernel works as work around. nf_conntrack_pptp and nf_nat_pptp are running in both cases after boot. This is command-line only environment. NetworkManager is running. NetworkManager-pptp package is not installed.
It seems my x86_64 Fedora laptop has the same problem, connecting as a client, (instead of connecting through the iptables configuration of the other system from either Windows or Fedora). Booting back to the 4.6.7 kernel fixes it, too. PPTP and 4.7.2 are not getting a long.
I confirm the pptp connection problem on x86_64 with 4.7.2 kernel. Trying to connect with pptp through NetworkManager fails after upgrade to 4.7.2. NetworkManager-pptp-gnome is installed. Going back to 4.6.6 works.
Problem continues to exist with kernel 4.7.3 (x86_64).
i have the same problem with 3.7.x kernels journalctl shows Sep 27 23:22:21 chaos.net NetworkManager[1314]: <info> [1475014941.5848] vpn-connection[0x55ed74e361d0,9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber",0]: Started the VPN service, PID 2732 Sep 27 23:22:21 chaos.net NetworkManager[1314]: <info> [1475014941.5933] vpn-connection[0x55ed74e361d0,9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber",0]: Saw the service appear; activating connection Sep 27 23:22:25 chaos.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-hostnamed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 27 23:22:27 chaos.net audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-localed comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' Sep 27 23:22:31 chaos.net NetworkManager[1314]: <info> [1475014951.5814] keyfile: update /etc/NetworkManager/system-connections/Vaber (9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber") Sep 27 23:22:31 chaos.net NetworkManager[1314]: <info> [1475014951.5930] vpn-connection[0x55ed74e361d0,9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber",0]: VPN connection: (ConnectInteractive) reply received Sep 27 23:22:33 chaos.net NetworkManager[1314]: ** Message: pppd started with pid 2758 Sep 27 23:22:33 chaos.net NetworkManager[1314]: <info> [1475014953.6962] vpn-connection[0x55ed74e361d0,9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber",0]: VPN plugin: state changed: starting (3) Sep 27 23:22:33 chaos.net pppd[2758]: Plugin /usr/lib64/pppd/2.4.7/nm-pptp-pppd-plugin.so loaded. Sep 27 23:22:33 chaos.net NetworkManager[1314]: Plugin /usr/lib64/pppd/2.4.7/nm-pptp-pppd-plugin.so loaded. Sep 27 23:22:33 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (plugin_init): initializing Sep 27 23:22:33 chaos.net realmd[1940]: quitting realmd service after timeout Sep 27 23:22:33 chaos.net realmd[1940]: stopping service Sep 27 23:22:34 chaos.net kernel: PPP generic driver version 2.4.2 Sep 27 23:22:34 chaos.net pppd[2758]: pppd 2.4.7 started by root, uid 0 Sep 27 23:22:34 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 3 / phase 'serial connection' Sep 27 23:22:35 chaos.net pptp[2766]: nm-pptp-service-2732 log[main:pptp.c:333]: The synchronous pptp option is NOT activated Sep 27 23:22:35 chaos.net pppd[2758]: Using interface ppp0 Sep 27 23:22:35 chaos.net NetworkManager[1314]: Using interface ppp0 Sep 27 23:22:35 chaos.net NetworkManager[1314]: Connect: ppp0 <--> /dev/pts/1 Sep 27 23:22:35 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 5 / phase 'establish' Sep 27 23:22:35 chaos.net pppd[2758]: Connect: ppp0 <--> /dev/pts/1 Sep 27 23:22:35 chaos.net NetworkManager[1314]: <info> [1475014955.8752] manager: (ppp0): new Generic device (/org/freedesktop/NetworkManager/Devices/6) Sep 27 23:22:35 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 1 'Start-Control-Connection-Request' Sep 27 23:22:35 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_disp:pptp_ctrl.c:758]: Received Start Control Connection Reply Sep 27 23:22:35 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_disp:pptp_ctrl.c:792]: Client connection established. Sep 27 23:22:36 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 7 'Outgoing-Call-Request' Sep 27 23:22:36 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_disp:pptp_ctrl.c:877]: Received Outgoing Call Reply. Sep 27 23:22:36 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_disp:pptp_ctrl.c:916]: Outgoing call established (call ID 0, peer's call ID 59005). Sep 27 23:23:06 chaos.net pppd[2758]: LCP: timeout sending Config-Requests Sep 27 23:23:06 chaos.net pppd[2758]: Connection terminated. Sep 27 23:23:06 chaos.net NetworkManager[1314]: LCP: timeout sending Config-Requests Sep 27 23:23:06 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 11 / phase 'disconnect' Sep 27 23:23:06 chaos.net NetworkManager[1314]: Connection terminated. Sep 27 23:23:06 chaos.net NetworkManager[1314]: ** Message: Terminated ppp daemon with PID 2758. Sep 27 23:23:06 chaos.net NetworkManager[1314]: <error> [1475014986.9075] platform-linux: do-change-link[7]: failure changing link: failure 19 (No such device) Sep 27 23:23:06 chaos.net NetworkManager[1314]: <warn> [1475014986.9076] device (ppp0): failed to disable userspace IPv6LL address handling Sep 27 23:23:06 chaos.net pppd[2758]: Terminating on signal 15 Sep 27 23:23:06 chaos.net org.gnome.Shell.desktop[1593]: Gjs-Message: JS LOG: Removing a network device that was not added Sep 27 23:23:06 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (nm_phasechange): status 1 / phase 'dead' Sep 27 23:23:06 chaos.net NetworkManager[1314]: Terminating on signal 15 Sep 27 23:23:06 chaos.net NetworkManager[1314]: Modem hangup Sep 27 23:23:06 chaos.net NetworkManager[1314]: ** Message: nm-pptp-ppp-plugin: (nm_exit_notify): cleaning up Sep 27 23:23:06 chaos.net org.gnome.Shell.desktop[2172]: Gjs-Message: JS LOG: Removing a network device that was not added Sep 27 23:23:06 chaos.net NetworkManager[1314]: <info> [1475014986.9124] vpn-connection[0x55ed74e361d0,9f6b2596-11f1-419d-a84c-9c4d78e1504f,"Vaber",0]: VPN service disappeared Sep 27 23:23:06 chaos.net pppd[2758]: Modem hangup Sep 27 23:23:06 chaos.net pppd[2758]: Exit. Sep 27 23:23:06 chaos.net pptp[2778]: nm-pptp-service-2732 log[callmgr_main:pptp_callmgr.c:245]: Closing connection (unhandled) Sep 27 23:23:06 chaos.net pptp[2778]: nm-pptp-service-2732 log[ctrlp_rep:pptp_ctrl.c:258]: Sent control packet type is 12 'Call-Clear-Request' Sep 27 23:23:06 chaos.net pptp[2778]: nm-pptp-service-2732 log[call_callback:pptp_callmgr.c:84]: Closing connection (call state) works perfect with kernel-4.6.5-300.fc24.x86_64
Hmm, it seems it's working for me (cmdline without NetworkManager, kernel-4.7.4). But maybe your problem is related to the: https://bugzilla.kernel.org/show_bug.cgi?id=152101 Please try: # sysctl net.netfilter.nf_conntrack_helper=1
And probably other dupes: bug 1369489, bug 1375006.
Confirmed, this solves the problem (kernel 4.7.4-200).
(In reply to Yiannis Liverezas from comment #7) > Confirmed, this solves the problem (kernel 4.7.4-200). Thanks for info. I think there is nothing to fix in pptp, the firewall needs to be correctly setup. But we could add note to the README or somewhere.
> Please try: > # sysctl net.netfilter.nf_conntrack_helper=1 Under 4.6.7, this is the default. When I reboot into a 4.7 kernel, it is set to 0. Setting it back to 1 solves the problem for me. Thank you!
(In reply to Jaroslav Škarvada from comment #8) > (In reply to Yiannis Liverezas from comment #7) > > Confirmed, this solves the problem (kernel 4.7.4-200). > Please see my comments inline > Thanks for info. > > I think there is nothing to fix in pptp, So it seems. Nothing to do here. > the firewall needs to be correctly > setup. But we could add note to the README or somewhere. Which README? At first glance, I don't think pptp's README is the appropriate place. The firewall configuration documentation maybe is more suitable. I don't know what this setting affects exactly (other services, security issues etc), but if there is a good reason for the default to be changed to 0, then for desktop users, a workaround/different setting should be handled under the hood by NetworkManager or whatever appropriate component. Trying to see this from a simple desktop user's perspective, all that is required is to setup the connection in network manager (settings) and expect things to work. Btw, better late than never, thank you for providing the solution to the problem. Just my .02
(In reply to Yiannis Liverezas from comment #10) > I don't know what this setting affects exactly (other services, security > issues etc), but if there is a good reason for the default to be changed to > 0, then for desktop users, a workaround/different setting should be handled > under the hood by NetworkManager or whatever appropriate component. Trying > to see this from a simple desktop user's perspective, all that is required > is to setup the connection in network manager (settings) and expect things > to work. > Yes, AFAIK the upstream configuration change is to improve security and the related information has bee around for a long time. In the short the connection tracking helpers could be exploited to bypass firewalls, so it's much better if the admin enables only those she/he really needs. Unfortunately this change broke many things, there is Fedora kernel bug 1369489 asking for the downstream revert. But personally I think that better solution is to fix/workaround the problem in the affected components. Regarding NetworkManager there is bug 1375006.
Can reproduce this on F24 (4.8.4-200.fc24.x86_64) After applying sudo sysctl net.netfilter.nf_conntrack_helper=1 connection works fine. Is this intended? Kind regards, Nemanja
It's due to upstream kernel change not to automatically attach conntrack helpers. Conntrack helpers could be abused for e.g. firewall bypass, by disabling their autoloading, user is responsible to manually load only what she/he needs - this can improve security. I think we can do what we have already have done in pptpd - explictly load nf_conntrack_pptp module.
Just wanted to check. I will try loading the module and see if it works that way, but the provided workaround is also ok. Thank you for the quick reply. Kind regards, Nemanja
pptp-1.8.0-9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-500dfc46f1
pptp-1.8.0-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdea79a0fb
pptp-1.8.0-9.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdea79a0fb
pptp-1.8.0-9.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-500dfc46f1
pptp-1.8.0-9.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
This update caused a regression. See bug #1400041 for details.
Reverting this patch because it's against upstream opinion. Reply from upstream: nf_conntrack_pptp is not needed by pptp. nf_conntrack_pptp is for systems that route pptp. nf_conntrack_pptp has a side-effect of ICMP unreachable suppression. Some people try nf_conntrack_pptp to fix interoperability problems between systems; yet they are not routing pptp. It hides the problem, and doesn't fix it. It works by side-effect. Once a problem is identified, we can design a better solution. I've not seen a good description of the problem, but if it has to do with zero call id, we have a new patch in 1.9.0 which may also fix the problem. Can you please work with people who use nf_conntrack_pptp to find out what the problem is, instead of accepting a side-effect solution?
pptp-1.8.0-9.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.