On 02.03.2017 09:29, Thomas Haller wrote: > On Thu, 2017-03-02 at 06:26 +0100, poma wrote: >> On 01.03.2017 18:14, poma wrote: >>> On 01.03.2017 17:11, Thomas Haller wrote: >>>> On Wed, 2017-03-01 at 08:07 +0100, poma wrote: >>>>> From 28b7713cda1deba1b54bd9e52b0d62716e356b66 Mon Sep 17 >>>>> 00:00:00 >>>>> 2001 >>>>> From: poma <[email protected]> >>>>> Date: Wed, 1 Mar 2017 07:05:40 +0100 >>>>> Subject: [PATCH] nm-pptp-service: Grant proto GRE by firewalld. >>>>> >>>>> With recent kernels, the Poptop - The PPTP Server for Linux >>>>> (pptpd) >>>>> requires >>>>> explicit load of nf_conntrack_pptp kernel module to achieve the >>>>> operating state of the service itself. >>>>> However this is not the case with the PPTP Client (pptp) on a >>>>> Linux >>>>> based platform. >>>>> What is needed is to apply directly, rule within the firewalld, >>>>> to >>>>> grant proto gre, >>>>> to achieve the operating state of the client itself. >>>>> >>>>> Ref. >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1187328 >>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1214643 >>>> >>>> Hi poma, >>>> >>>> the patch does two things. I think there should be two patches >>>> for it. >>>> >>>> 1) drop loading the kernel module "nf_conntrack_pptp". The patch >>>> basically reverts >>>> https://git.gnome.org/browse/network-manager-pptp/commit/?id=695d >>>> 4f2f3d1003e18be6f97bbb103e44f75d3c2b >>>> but it's not explained why that is correct beyond "this is not >>>> the case >>>> with...". It should be explained better whats wrong with 695d4f2f >>>> and how that affects the two bugs that were closed by it. Will >>>> the issue >>>> reapar, or was there a different issue in the first place? >>>> >>> >>> Here, just for you, once again ;) >>> >>> by By Ryan Roth >>> 6/07/2005 >>> "Troubleshooting 'GRE: Protocol not available' errors" >>> http://poptop.sourceforge.net/dox/gre-protocol-unavailable.phtml >>> #1. Client firewall: >>> "Make sure your client is not running a software firewall. If it is >>> make sure port 1723 and protocol 47 are allowed." >>> >>> Port 1723 is not a problem, but proto GRE is, meaning, >>> to achieve the operating state of the client itself, >>> "protocol 47 must be allowed" i.e. "grant proto gre". >>> >>>> 2) call to firewallcmd. firewalld is commonly only available on >>>> Fedora/RHEL, thus patch would cause a warning on Debian >>>> systems... >>>> You would at least need to check whether such a binary file >>>> exists and >>>> only call it if necessary. >>>> >>> >>> I am a user of the Fedora - a Linux based operating system. >>> "Choose Freedom. Choose Fedora." >>> >>> >> >> >> = Brief analysis and diagnosis, >> Point-to-Point Tunneling Protocol (PPTP) Client >> >> Commands and outputs speak for themselves. >> >> $ uname -r >> 4.10.1-1.fc24.x86_64 >> >> $ cat /sys/module/nf_conntrack/parameters/nf_conntrack_helper >> N >> >> $ dmesg -t | grep conntrack >> nf_conntrack version 0.5.0 (16384 buckets, 65536 max) >> >> $ lsmod | grep gre >> >> $ firewall-cmd --version >> 0.4.4.3 >> >> $ firewall-cmd --get-automatic-helpers >> system >> >> $ firewall-cmd --direct --get-all-rules >> >> $ rpm -q --changelog NetworkManager-pptp | head -2 >> * Thu Mar 02 2017 poma <[email protected]> - 1.2.4-3 >> - nm-pptp-service: rm modprobe >> >> $ nmcli --version >> nmcli tool, version 1.7.1-0.9.20170224git9138967.fc24 >> >> $ nmcli connection up pptp ifname enp2s5 >> Error: Connection activation failed: the VPN service stopped >> unexpectedly. >> >> $ dmesg -t | grep conntrack >> nf_conntrack version 0.5.0 (16384 buckets, 65536 max) >> conntrack: generic helper won't handle protocol 47. Please consider >> loading the specific helper module. >> >> $ su >> Password: >> # journalctl -b -u NetworkManager -o cat | grep LCP >> LCP: timeout sending Config-Requests >> LCP: timeout sending Config-Requests >> >> # modprobe -v nf_conntrack_pptp >> insmod /lib/modules/4.10.1- >> 1.fc24.x86_64/kernel/net/netfilter/nf_conntrack_proto_gre.ko.xz >> insmod /lib/modules/4.10.1- >> 1.fc24.x86_64/kernel/net/netfilter/nf_conntrack_pptp.ko.xz >> >> # lsmod | grep pptp >> nf_conntrack_pptp 16384 0 >> nf_conntrack_proto_gre 16384 1 nf_conntrack_pptp >> nf_conntrack 131072 8 >> nf_conntrack_ipv6,nf_conntrack_ipv4,nf_conntrack_pptp,nf_conntrack_pr >> oto_gre,nf_nat_ipv6,xt_conntrack,nf_nat_ipv4,nf_nat >> >> # exit >> exit >> >> $ nmcli connection up pptp ifname enp2s5 >> Error: Connection activation failed: the VPN service stopped >> unexpectedly. >> >> $ dmesg -t | grep conntrack >> nf_conntrack version 0.5.0 (16384 buckets, 65536 max) >> conntrack: generic helper won't handle protocol 47. Please consider >> loading the specific helper module. >> nf_conntrack: default automatic helper assignment has been turned off >> for security reasons and CT-based firewall rule not found. Use the >> iptables CT target to attach helpers instead. >> >> $ su >> Password: >> # modprobe -vr nf_conntrack_pptp >> rmmod nf_conntrack_pptp >> rmmod nf_conntrack_proto_gre >> >> # lsmod | grep pptp >> >> # exit >> exit >> >> $ firewall-cmd --direct --add-rule ipv4 filter INPUT 0 -p gre -j >> ACCEPT >> success >> >> $ firewall-cmd --direct --get-all-rules >> ipv4 filter INPUT 0 -p gre -j ACCEPT >> >> $ nmcli connection up pptp ifname enp2s5 >> VPN connection successfully activated (D-Bus active path: >> /org/freedesktop/NetworkManager/ActiveConnection/4) >> >> >> For additional questions, developers Eric Leblond and Pablo Neira >> Ayuso, can be contacted at: >> The netfilter user mailinglist >> http://www.netfilter.org/mailinglists.html#ml-user > > Hi poma, > > > This answers the questions only in part. > > > question 1 was: why is it correct to remove the loading of > nf_conntrack_pptp. You showed that it works *for you* to do > so, but bugs > https://bugzilla.redhat.com/show_bug.cgi?id=1206276 > https://bugzilla.redhat.com/show_bug.cgi?id=1187328 > indicate that is is (was?) required on some systems. Why is the outcome > of those bugs no longer valid and loading of the module is no longer > desired? >
I see that Lubo followed respective upstream thread: "conntrack GRE behaves differently in 3.17 / 3.18" https://marc.info/?l=netfilter&m=143014290727488 Maybe he can help clarify, when you do not want to discuss with upstreamers. But be aware, there is a clear difference in the behavior of pptpd and pptp. We are talking here about pptp i.e. PPTP Client which gets no help from nf_conntrack helpers. As opposed to pptp, pptpd i.e. Poptop - The PPTP Server for Linux does not encounter this problem, i.e. it gets help from nf_conntrack helpers. If Lubo cannot help clarify, perhaps Pablo can. If Pablo cannot help clarify, then let's drop this fix. > > question 2 was: the code needs fixing on systems that don't use > firewalld. I didn't question that this is required on your setup or on > Fedora. I simple hack may be as simple as adding: > > if (g_file_test ("/bin/firewall-cmd", G_FILE_TEST_IS_EXECUTABLE) { > if (!g_spawn_sync (NULL, firewalld_grant_proto_gre, NULL,.... > .... > } > > Is it not better to ask via D-BUS, whether the firewall is active, and if so, whether the rule already applies. And then apply the rule if it is not already, also via D-BUS. I leave it to you to code it, you're the expert, right. > And finally, lets split the patch in two. Where each part better > describes what the patch does (and more importantly: why). > > > Thanks, and sorry for being a pain :) > Thomas > "That which does not kill us makes us stronger." F.N. _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
