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:
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.
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.
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.
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.
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. :-)
Thank you Jonathan S! That also worked for my F23 boxen.
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
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?