Bug 1373014 - VPN PPTP sessions no longer work under kernel 4.7.2
Summary: VPN PPTP sessions no longer work under kernel 4.7.2
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-04 19:10 UTC by Jonathan S
Modified: 2017-09-27 09:09 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-09-06 16:25:31 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1375006 None None None Never

Internal Links: 1375006

Description Jonathan S 2016-09-04 19:10:46 UTC
Description of problem:

VPN PPTP sessions set up under NetworkManager have worked fine under previous kernels. Now, under kernel 4.7.2, the connection is attempted (shows 'connecting') but never succeeds, and after 30 seconds shows as failed (presumably a timeout).

Booting with a previous kernel, (for example 4.6.7), and the connection works fine as it always has done.

This happens every time - and I have tried it on two different Fedora 24 machines with exactly the same result (always fails under 4.7.2, always works under 4.6.7).

On the Advanced options:
The PPTP session allows MSCHAP and MSCHAPv2, uses point-to-point encryption (MPPE), uses 128-bit security. All other option under 'Advanced' are unticked.
The IPv4 and IPv6 are as the default (Automatic, no DNS or routes entered).


How reproducible:


Steps to Reproduce:
1. Boot current Fedora 24 kernel of 4.7.2
2. Attempt to establish a VPN session using PPTP
3. 

Actual results:
Connection shows 'connecting' for 30 seconds then fails.

Expected results:
A successful VPN PPTP session established (as worked with all previous kernels).

Additional info:

Comment 1 Kasper Pedersen 2016-09-05 21:17:31 UTC
I ran into this issue when upgrading my router, and found what had changed. 

The quickfix there was:

sysctl net.netfilter.nf_conntrack_helper=1

see also 1369489

In net/netfilter/nf_conntrack_helper.c,
the default value of nf_ct_auto_assign_helper was changed from true to false going from 4.6 to 4.7.

It happened in commit 3bb398d925ec73e42b778cf823c8f4aecae359ea 2016-04-25,
the comment was:

"Four years ago we introduced a new sysctl knob to disable automatic
helper assignment in 72110dfaa907 ("netfilter: nf_ct_helper: disable
automatic helper assignment"). This knob kept this behaviour enabled by
default to remain conservative.

This measure was introduced to provide a secure way to configure
iptables and connection tracking helpers through explicit rules.

Give the time we have waited for this, let's turn off this by default
now, worse case users still have a chance to recover the former
behaviour by explicitly enabling this back through sysctl."


I don't have a recipe for doing this to the iptables ruleset - I don't yet have the skill.

Comment 2 Jonathan S 2016-09-05 22:37:49 UTC
Thanks Kasper, I can confirm that 

sysctl net.netfilter.nf_conntrack_helper=1

does indeed solve the issue.

I'll leave this bug open as it won't be clear to most Fedora users that they have to do this workround with the current 4.7 kernel. Like me, they'll be tearing their hair out wondering why things used to work under 4.6 but are now broken.

Hopefully, a kernel maintainer can give their opinion on this change. If it's going to remain as it is, I can't see how ordinary users are going to be able to cope with it.

Comment 3 Laura Abbott 2016-09-06 16:25:31 UTC
I understand it is frustrating. It's unfortunate we couldn't plan for this in a more controlled manner or make a better announcement. I don't think reverting back to the existing default behavior is the right option though. The commit was in rawhide and didn't find these problems so a revert would only continue to delay the inevitable. The sysctl is the best option right now until the rules can be updated to work with =0. If you have specific suggestions on how to have an intermediate step I'm open to hear them but until that happens I'm going to close this bug.

Comment 4 jimstaffer 2016-09-06 23:44:07 UTC
I'm running F23 [*], and I've also experienced this problem. The "sysctl net.netfilter.nf_conntrack_helper=1" work-around also worked for me.

But I have not yet found a way of making this change persistent. I first tried appending "net.netfilter.nf_conntrack_helper = 1" to /etc/sysctl.conf, but that didn't set it (or, perhaps it is overwritten later???) on boot.

I also tried creating a new .conf file in /etc/sysctl.d - even though /etc/sysctl.d/99-sysctl.conf is a symlink to /etc/sysctl.conf), so - as I expected - that didn't work on boot either.

I also tried creating a conf files in /usr/lib/sysctl.d (01-me.conf and 99-me.conf) - same result.

Both "systemctl restart systemd-sysctl.service" and "sysctl --system" set it non-persistently:

[root@yosj ~]# sysctl  --system
* Applying /usr/lib/sysctl.d/00-system.conf ...
* Applying /usr/lib/sysctl.d/10-default-yama-scope.conf ...
kernel.yama.ptrace_scope = 0
* Applying /usr/lib/sysctl.d/50-coredump.conf ...
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e
* Applying /usr/lib/sysctl.d/50-default.conf ...
kernel.sysrq = 16
kernel.core_uses_pid = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.promote_secondaries = 1
net.ipv4.conf.all.promote_secondaries = 1
net.core.default_qdisc = fq_codel
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
* Applying /etc/sysctl.d/50-libreswan.conf ...
net.ipv6.conf.default.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_redirects = 0
* Applying /usr/lib/sysctl.d/97-kde-baloo-filewatch-inotify.conf ...
fs.inotify.max_user_watches = 524288
* Applying /etc/sysctl.d/99-sysctl.conf ...
net.netfilter.nf_conntrack_helper = 1
* Applying /etc/sysctl.conf ...
net.netfilter.nf_conntrack_helper = 1

So, what would be considered best practice for setting this persistently?


[*] I have too many of them to update every 6 months, so I skip every other release.

Comment 5 Jonathan S 2016-09-18 19:45:14 UTC
For jimstaffer and anyone else trying to make net.netfilter.nf_conntrack_helper=1 persistent, I've finally worked it out.
You have to persuade systemd to apply the setting *after* the nf_conntrack module has been loaded. Unless you do, you'll see something like:
--
systemd-sysctl[188]: Couldn't write '1' to 'net/netfilter/nf_conntrack_helper', ignoring: No such file or directory
---
in your journal, since /proc/sys/net/netfilter/nf_conntrack_helper doesn't exist until the conntrack module is loaded, which you'll find *later* in the journal.

The answer lies in the systemd/sysctl.d manual:
https://www.freedesktop.org/software/systemd/man/sysctl.d.html

I used Method Two (Example 3). I created file /etc/modules-load.d/nf_conntrack.conf and put in the  content:
nf_conntrack_ipv4
nf_conntrack_ipv6
and created file /etc/sysctl.d/98-nf_conntrack.conf (98 is random, just nf_conntrack.conf worked but this directory seems to want numbers, presumably for priority - I just care that it works!). The content of this file is of course:
net.netfilter.nf_conntrack_helper = 1
(I guess the spaces aren't important either way, but have not tried without.)

Reboot and run sysctl net.netfilter.nf_conntrack_helper and it should be 1. :-)

Comment 6 jimstaffer 2016-09-18 23:22:51 UTC
Thank you Jonathan S! That also worked for my F23 boxen.

Comment 7 Marcos Garcia 2016-09-26 17:22:20 UTC
Confirmed in F24. I also thought that the kernel removed support for MSCHAPv2, but somehow the sysctl trick solved the issue
sysctl net.netfilter.nf_conntrack_helper=1

Comment 8 Cameron 2017-09-27 09:09:45 UTC
So if this is marked as "Closed Not a Bug" can a real solution or explanation be provided for the average user?

For the last year I have been logging into a windows machine to use my VPN because it just stopped working in Linux one day and back then there was no answer to why or how to fix it... Until I found this bandaid fix.

This issue still occurs but there is no solution beyond this temporary fix of 

net.netfilter.nf_conntrack_helper = 1

I get that a default changed in the kernel but without giving your average user the reasons or a simpler way of resolving this it is still very much broken.

Is the problem a poorly configured VPN endpoint or have things changed locally to be so strict that the average user can't use a VPN easily anymore?


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