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.
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.
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.
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
I am also having this problem.
does not work vpn pptp in fedora 27. I have the same problem
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)
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.
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.