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



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]