Bug 1373689 - PPTP broken after kernel update
Summary: PPTP broken after kernel update
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: pptp
Version: 24
Hardware: i686
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Jaroslav Škarvada
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-07 00:35 UTC by D. E. Evans
Modified: 2016-12-03 10:56 UTC (History)
6 users (show)

Fixed In Version: pptp-1.8.0-9.fc24 pptp-1.8.0-9.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-11-30 05:28:31 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Linux Kernel 152101 None None None Never
Red Hat Bugzilla 1369489 None None None Never
Red Hat Bugzilla 1375006 None None None Never

Internal Links: 1369489 1375006

Description D. E. Evans 2016-09-07 00:35:58 UTC
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.

Comment 1 D. E. Evans 2016-09-09 18:32:37 UTC
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.

Comment 2 Yiannis Liverezas 2016-09-11 06:44:25 UTC
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.

Comment 3 Yiannis Liverezas 2016-09-17 18:04:42 UTC
Problem continues to exist with kernel 4.7.3 (x86_64).

Comment 4 jiannis 2016-09-27 22:27:14 UTC
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

Comment 5 Jaroslav Škarvada 2016-09-29 08:38:03 UTC
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

Comment 6 Jaroslav Škarvada 2016-09-29 08:44:22 UTC
And probably other dupes: bug 1369489, bug 1375006.

Comment 7 Yiannis Liverezas 2016-09-29 20:28:39 UTC
Confirmed, this solves the problem (kernel 4.7.4-200).

Comment 8 Jaroslav Škarvada 2016-09-30 09:50:50 UTC
(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.

Comment 9 D. E. Evans 2016-09-30 21:59:22 UTC
> 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!

Comment 10 Yiannis Liverezas 2016-10-03 07:49:02 UTC
(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

Comment 11 Jaroslav Škarvada 2016-10-03 09:25:14 UTC
(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.

Comment 12 Nemanja Milosevic 2016-11-19 22:12:10 UTC
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

Comment 13 Jaroslav Škarvada 2016-11-21 13:58:05 UTC
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.

Comment 14 Nemanja Milosevic 2016-11-21 14:53:04 UTC
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

Comment 15 Fedora Update System 2016-11-21 16:53:19 UTC
pptp-1.8.0-9.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-500dfc46f1

Comment 16 Fedora Update System 2016-11-21 16:55:58 UTC
pptp-1.8.0-9.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bdea79a0fb

Comment 17 Fedora Update System 2016-11-23 20:31:49 UTC
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

Comment 18 Fedora Update System 2016-11-23 23:06:41 UTC
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

Comment 19 Fedora Update System 2016-11-30 05:28:31 UTC
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.

Comment 20 Christian Stadelmann 2016-12-01 12:30:24 UTC
This update caused a regression. See bug #1400041 for details.

Comment 21 Jaroslav Škarvada 2016-12-02 15:14:38 UTC
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?

Comment 22 Fedora Update System 2016-12-03 10:56:46 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.