pptp/pptpconfig misbehavior in F7 (and sometimes FC6)

A few months back, I decided the time had finally arrived to to entirely expunge Microsoft from my own computers. I upgraded FC4 - which I had only toyed with a bit - to FC6 on my vintage 1998 PC. I need to remotely support some Windows 2000 servers, so I installed rdesktop, pptp and pptpconfig. All of these worked exceedingly well.

I setup a VPN tunnel to the a Windows 2003 server at the office, configured a static route, sparked up rdesktop, and it was pretty much follow-my-nose. I didn't even RTFM.

When F7 was generally released, I thought this would be a great time to bung it on the Dell Inspiron 500m laptop (the plan was to get wireless going too - but that's another saga), set up pptp (et al) and rdesktop, then I'd be entirely free of XP - at least at home!

That's where my problems started. For some reason, I cannot make pptp/pptpconfig work on F7. On possible explanation is that it seems to be screwing up the route entries.

Notes:
1. I have "NOZEROCONF=yes" in my /etc/sysconfig/network file.
2. I have obfuscated the IP address, domain name and username of the VPN target server.

Here's what my route table looks like (on both FC6 and F7) before I create the VPN tunnel:

$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

.... and here's what it looks like on F7 after I create the VPN tunnel (with the static route - 10.12.31.0/24 in pptpconfig):

$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.X.Y.Z 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
202.X.Y.Z 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 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Note that the static route is missing, but there is a erroneous duplicate destination for the VPN server!!! Actually, the resulting route table looks the same whether I specify a static route in pptpconfig or not. This is what route -n shows, even though the pptpconfig debug output (see bottom) shows that it is setting up the routes correctly - it is not!

This is what it looks like on the (working) vintage FC6 PC:

$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.X.Y.Z 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.12.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0

Just to make it even more interesting...

A. This misbehavior happens only _nearly_ every time, but not every time on the laptop. I have seen it work a few times!

B. I have even seen pptp fail - once - on the old (FC6) PC. It might have happened more than once, but only once since I knew what to look for. Generally, it's extremely reliable.

C. After having spent quite a few hours on F7 (selected because of the "rock solid wireless"), I decided to just install FC6 on the laptop - because I "knew" that worked! Guess what - same result as F7 on the laptop. Bizarre, eh?!? (BTW, eth0 _is_ working reliably!)

D. Simply deleting the offending route and adding the correct one does not seem to fix the problem. This is very strange.

OK, I admit it, I was a bit smug. I was going around telling all my tech buddies that I was using LINUX nearly exclusively. Then this happened. Any idea what's causing pptp/pptpconfig to do this?

Thanks, Jim

====================================================================
Here is the (suitably obscured) pptpconfig debug output:
====================================================================
pptpconfig: debug information dump begins
WARNING: security sensitive information follows
pptpconfig 1.12 2006/08/21 06:19:12
# pptp --version
pptp version 1.7.1
# pppd --version
pppd version 2.4.4
# uname -a
Linux lapdancer 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12 15:37:31 EDT 2007 i686 i686 i386 GNU/Linux
# modinfo ppp_mppe || modinfo ppp_mppe_mppc
filename: /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/net/ppp_mppe.ko
version: 1.0.2
alias: ppp-compress-18
license: Dual BSD/GPL
description: Point-to-Point Protocol Microsoft Point-to-Point Encryption support
author: Frank Cusack <fcusack@xxxxxxxxxxx>
srcversion: 39166EF06A40CF00F255FC5
depends: ppp_generic
vermagic: 2.6.21-1.3228.fc7 SMP mod_unload 686 4KSTACKS
# grep mppe /proc/modules
ppp_mppe 10693 0 - Live 0xe0d6b000
ppp_generic 30421 2 ppp_mppe,ppp_async, Live 0xe0d70000
Array
(
[name] => VPN_NDGW
[server] => <OBFUSCATED>
[domain] =>
[username] => <OBFUSCATED>
[password] => (hidden by pptpconfig)
[pppd-options] =>
[pptp-options] =>
[resolv] =>
[dns-options] =>
[routing] => routing_client_to_lan
[usepeerdns] => 1
[require-mppe] => 1
[nomppe-40] =>
[nomppe-128] =>
[refuse-eap] => 1
[mppe-stateful] =>
[autostart] => 1
[iconify] =>
[persist] => 1
[debug] => 1
[client-to-lan] => a:1:{s:13:"10.12.31.0/24";s:0:"";}
)
# route -n (before pppd)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
pptpconfig: debug information dump ends, starting pppd
pppd options in effect:
debug # (from /etc/ppp/peers/VPN_NDGW)
updetach # (from command line)
persist # (from /etc/ppp/peers/VPN_NDGW)
logfd 1 # (from command line)
linkname VPN_NDGW # (from /etc/ppp/peers/VPN_NDGW)
dump # (from /etc/ppp/peers/VPN_NDGW)
noauth # (from /etc/ppp/options.pptp)
refuse-chap # (from /etc/ppp/options.pptp)
refuse-mschap # (from /etc/ppp/options.pptp)
refuse-eap # (from /etc/ppp/options.pptp)
name <OBFUSCATED> # (from /etc/ppp/peers/VPN_NDGW)
remotename VPN_NDGW # (from /etc/ppp/peers/VPN_NDGW)
# (from /etc/ppp/options.pptp)
pty pptp <OBFUSCATED> --nolaunchpppd # (from /etc/ppp/peers/VPN_NDGW)
ipparam VPN_NDGW # (from /etc/ppp/peers/VPN_NDGW)
usepeerdns # (from /etc/ppp/peers/VPN_NDGW)
nobsdcomp # (from /etc/ppp/options.pptp)
nodeflate # (from /etc/ppp/options.pptp)
require-mppe # (from /etc/ppp/peers/VPN_NDGW)
using channel 4
Using interface ppp0
pptpconfig: monitoring interface ppp0
Connect: ppp0 <--> /dev/pts/2
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x946bdb07> <pcomp> <accomp>]
sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x946bdb07> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xb29286f5> <pcomp> <accomp>]
rcvd [CHAP Challenge id=0x1 <ef396fa74a24d10c8168c5d7c5fbd361>, name = "gefw001by"]
sent [CHAP Response id=0x1 <d4345a6b3173a93fb4d13b9883cf4e2e00000000000000002766ed0c7fcd720d15d082ab09330badae2e4d6844b1ecb000>, name = "<OBFUSCATED>"]
rcvd [CHAP Success id=0x1 "S=A447AF6094F955198DF17614CC6C1DCB053C0D37"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
rcvd [IPCP ConfReq id=0x1 <addr 202.X.Y.Z> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP TermAck id=0x1]
rcvd [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <mppe +H +M +S +L -D +C> <bsd v1 15>]
sent [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
rcvd [CCP ConfNak id=0x1 <mppe +H -M +S -L -D -C>]
sent [CCP ConfReq id=0x2 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x2 <mppe +H +M +S +L -D +C>]
sent [CCP ConfNak id=0x2 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x2 <mppe +H -M +S -L -D -C>]
rcvd [CCP ConfReq id=0x3 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x3 <mppe +H -M +S -L -D -C>]
MPPE 128-bit stateless compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 192.168.3.50>]
sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 192.168.3.50>]
rcvd [IPCP ConfAck id=0x3 <compress VJ 0f 01> <addr 192.168.3.50>]
rcvd [IPCP ConfReq id=0x1 <addr 202.X.Y.Z> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
sent [IPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [IPCP ConfReq id=0x2 <addr 202.X.Y.Z> <compress VJ 0f 01>]
sent [IPCP ConfAck id=0x2 <addr 202.X.Y.Z> <compress VJ 0f 01>]
local IP address 192.168.3.50
remote IP address 202.X.Y.Z
# route -n (after pppd exit)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.X.Y.Z 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 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
pptpconfig: pppd process exit status 0 (started)
ip route replace 202.X.Y.Z via 192.168.0.1 dev eth0 src 192.168.0.101
ip route add '10.12.31.0/24' dev 'ppp0'
pptpconfig: routes added to remote networks
pptpconfig: usepeerdns was set, but /{var/run,etc}/ppp/resolv.conf was not readable
pptpconfig: connected
# route -n (after completion)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
202.X.Y.Z 192.168.0.1 255.255.255.255 UGH 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
10.12.31.0 0.0.0.0 255.255.255.0 U 0 0 0 ppp0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0
========================================================================
.

Relevant Pages

  • Re: The PPP negotiation failed, coz serial loopback was detected
    ... DNS servers and a default route using the modem/router as the gateway. ... be even sending so much as a carriage return to the peer, ... PPP to set up the addressing and routing on your machine. ... The variables are set automagically by pppd without any user intervention. ...
    (alt.os.linux)
  • Re: The PPP negotiation failed, coz serial loopback was detected
    ... The "thing" that requires you to not have such a route is pppd itself, ... This is representative of a correct routing table. ... sending the packets to the gateway at 192.168.195.11. ...
    (alt.os.linux)
  • RE: Fax routing
    ... I understand you could not route your ... Open Server Management ... E-mail incoming routing method" ...
    (microsoft.public.windows.server.sbs)
  • Problems with PPTP and remote Windows VPN Server.
    ... I have a Internet connection with a cable modem, ... In the list we can see the output of pptpconfig in debug mode and the data ... pppd version 2.4.1 ... Kernel IP routing table ...
    (comp.os.linux.networking)
  • Routing in the network :-)
    ... Itojun and I had played off and on ... routing information. ... So AT&T gives me the default route to IP-A1 ... up to FreeBSD.net and AT&T's network went down.. ...
    (freebsd-arch)