Bug 1476496 - PPTP VPN broken under FC26
Summary: PPTP VPN broken under FC26
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager-pptp
Version: 26
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-29 16:32 UTC by James Abbott
Modified: 2018-05-29 12:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-05-29 12:54:56 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description James Abbott 2017-07-29 16:32:27 UTC
Description of problem:
Establishing a PPTP VPN connection using the same configuration as worked under previous fedora releases fails to provide a working route to the peered network. ifconfig shows a very high number of transmitted packets on the ppp0 interface suggesting a routing loop.

Version-Release number of selected component (if applicable):
NetworkManager-pptp-1.2.4-2.fc26.x86_64
NetworkManager-pptp-gnome-1.2.4-2.fc26.x86_64
pptpd-1.4.0-11.fc26.x86_64
pptp-1.9.0-2.fc26.x86_64

How reproducible: Highly...problem occurs every time connection is attempted


Steps to Reproduce:
1. VPN Configuration (/etc/NetworkManager/system-connections/vpn):
[connection]
id=vpn
uuid=6bb72e2b-f9f4-447a-98de-454384ffa165
type=vpn
gateway-ping-timeout=21
permissions=user:MYUID:;
timestamp=1501187450

[vpn]
domain=MYDOMAIN
gateway=VPNHOST
lcp-echo-failure=5
lcp-echo-interval=30
mppe-stateful=yes
password-flags=1
refuse-chap=yes
refuse-eap=yes
refuse-mschap=yes
refuse-pap=yes
require-mppe=yes
user=MYUID
service-type=org.freedesktop.NetworkManager.pptp

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
method=auto

2. pptp conntrack iptables module is loaded:
[jamesa@wssb ~] sysctl net.netfilter.nf_conntrack_helper
net.netfilter.nf_conntrack_helper = 1

[jamesa@wssb-james ~]$ lsmod|grep pptp
nf_conntrack_pptp      16384  0
nf_conntrack_proto_gre    16384  1 nf_conntrack_pptp
nf_conntrack          131072  11 nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_conntrack_pptp,nf_conntrack_netlink,nf_conntrack_proto_gre,nf_nat_ipv6,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat

3. Connect to VPN using gnome NetworkManger applet

Actual results: Can not ping/ssh to hosts on the remote network. 
High CPU usage from pptpgw
ifconfig shows many outgoing packets on ppp0:

ppp0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1400
        inet VPNHOST  netmask 255.255.255.255  destination PEERADDR
        ppp  txqueuelen 3  (Point-to-Point Protocol)
        RX packets 7  bytes 106 (106.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8195364  bytes 4868391452 (4.5 GiB)
        TX errors 11  dropped 0 overruns 0  carrier 0  collisions 0

VPN connection is dropped after around two minutes

Expected results: Hosts on remote network are routable via the ppp0 interface. VPN connection remains established.

Additional info:
Network routes do not appear to correctly configured. In the following examples, VPNHOST is the IP address of the host to which the connection is established. PEERADDRESS is the address of the destination from 'ifconfig ppp0' (see example 'ifconfig ppp0' output above)

After enabling the PPTP VPN, the routing table looks like:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlp2s0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlp2s0
192.168.0.1     0.0.0.0         255.255.255.255 UH        0 0          0 wlp2s0
PEERADDRESS     0.0.0.0         255.255.255.255 UH        0 0          0 ppp0

The routing table from a CentOS7 VM running on the same host with a working PPTP connection looks like:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 enp0s3
VPNHOST         0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 enp0s3
192.168.122.0   0.0.0.0         255.255.255.0   U         0 0          0 virbr0
PEERADDRESS     192.168.0.1     255.255.255.255 UGH       0 0          0 enp0s3 

I've manually updated the routing table after establising a VPN connection to mirror the table from the working VM:

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         0.0.0.0         0.0.0.0         U         0 0          0 ppp0
0.0.0.0         192.168.0.1     0.0.0.0         UG        0 0          0 wlp2s0
VPNHOST         0.0.0.0         255.255.255.255 UH        0 0          0 ppp0
172.17.0.0      0.0.0.0         255.255.0.0     U         0 0          0 docker0
192.168.0.0     0.0.0.0         255.255.255.0   U         0 0          0 wlp2s0
PEERADDRESS     192.168.0.1     255.255.255.255 UGH       0 0          0 wlp2s0

With these changes in place, even though the routing table now looks equivalent to that which works on CentOS7, it is still not possible to connect to hosts on the remote network. The ppp0 interface no longer shows the high rate of transmitted packets however, and the connection remains stable even though the connection is not functional.

Comment 1 Hedayat Vatankhah 2017-10-09 07:27:38 UTC
Can be duplicate of: #1375006
Try this: sysctl net.netfilter.nf_conntrack_helper=1

If it solved the issue, it is duplicate of that bug.

Comment 2 penguin01210 2017-10-17 23:04:34 UTC
I am also experiencing this issue. I have tried running sysctl net.netfilter.nf_conntrack_helper=1, but it did not help.

I am seeing high CPU usage of the pptpgw process. Connections are sometimes established, but end up in timeouts. 

I have tried applying the netfilter module for ip_conntrack_proto_gre and  ip_conntrack_pptp with no success.

Comment 3 penguin01210 2017-11-24 00:03:01 UTC
This seems to be an issue with pppd and/or iproute2, an error is raised "Error: either "to" is duplicate, or "uid" is a garbage." during initialisation. The problem has been solved on Arch Linux with an upgrade of the pptpclient package. 
See here:
https://bbs.archlinux.org/viewtopic.php?pid=1705884#p1705884

Comment 4 Seth Bowen 2018-03-06 16:09:09 UTC
I am also having this problem.

Comment 5 Humbert Gonzalez 2018-03-07 02:32:21 UTC
does not work vpn pptp in fedora 27. I have the same problem

Comment 6 Max de Bayser 2018-04-19 01:41:14 UTC
I had this problem too. I've tested this patch here (https://sourceforge.net/p/pptpclient/git/ci/7d9a428a0744b3053767dc2d239f305c86f1fcee/) and I confirm that it solves this problem in my case. 



Here is a patch for the SRPM spec file:

```
diff -Naur a/pptp.spec b/pptp.spec
--- a/pptp.spec	2018-04-18 22:31:20.186337173 -0300
+++ b/pptp.spec	2018-04-18 22:31:28.720323336 -0300
@@ -1,12 +1,13 @@
 Name:		pptp
 Version:	1.9.0
-Release:	2%{?dist}
+Release:	3%{?dist}
 Summary:	Point-to-Point Tunneling Protocol (PPTP) Client
 Group:		Applications/Internet
 License:	GPLv2+
 URL:		http://pptpclient.sourceforge.net/
 Source0:	http://downloads.sf.net/pptpclient/pptp-%{version}.tar.gz
 Source1:	pptp-tmpfs.conf
+Patch0:         pptp_route.patch
 BuildRoot:	%{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
 BuildRequires:	/usr/bin/pod2man
 BuildRequires:	perl-generators
@@ -29,6 +30,7 @@
 
 %prep
 %setup -q
+%patch0 -p1
 
 # Pacify rpmlint
 perl -pi -e 's/install -o root -m 555 pptp/install -m 755 pptp/;' Makefile

```


And here is the pptp_route.patch:
```
--- a/routing.c
+++ b/routing.c
@@ -112,13 +112,21 @@
 #endif /* Solaris */ 
 #if defined(__linux)
   char buf[256];
+  char tbuf[256];
+  const char *uid;
   FILE *p;
 
   snprintf(buf, 255, "%s route get %s", IP_BINARY, ip);
   p = popen(buf, "r");
   fgets(buf, 255, p);
   /* TODO: check for failure of fgets */
-  route = strdup(buf);
+  uid = strstr(buf, " uid");
+  if (uid) {
+    snprintf(tbuf, uid - buf + 1, "%s", buf);
+    route = strdup(tbuf);
+  } else {
+    route = strdup(buf);
+  }
   pclose(p);
   /* TODO: check for failure of command */
 #endif /* __linux__ */

```


Additionally, to make it work I also had to adjust my iptables settings. Otherwise I would get a "LCP: timeout sending Config-Requests":


firewall-cmd --direct --add-rule ipv4 filter OUTPUT 1 --source 0.0.0.0/0.0.0.0 --destination 0.0.0.0/0.0.0.0 --jump ACCEPT --protocol gre --out-interface wlp4s0
firewall-cmd --direct --add-rule ipv4 filter INPUT 1 --source 0.0.0.0/0.0.0.0 --destination 0.0.0.0/0.0.0.0 --jump ACCEPT --protocol gre --in-interface wlp4s0

To make it permanent just add --permanent (both versions of the command need to be run)

Comment 7 Fedora End Of Life 2018-05-03 08:37:56 UTC
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 8 Fedora End Of Life 2018-05-29 12:54:56 UTC
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26
is no longer maintained, which means that it will not receive any
further security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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