Re: [PATCH] nm-pptp-service: Grant proto GRE by firewalld

[poma <pomidorabelisima gmail com>]

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 <poma gmail com>
> > > > > 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 <poma gmail com> - 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.