Bug 1476496 - PPTP VPN broken under FC26
PPTP VPN broken under FC26
Status: NEW
Product: Fedora
Classification: Fedora
Component: NetworkManager-pptp (Show other bugs)
26
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Lubomir Rintel
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-29 12:32 EDT by James Abbott
Modified: 2017-07-29 12:32 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Abbott 2017-07-29 12:32:27 EDT
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.

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