Linux pptp client stops working after several hours
        Posted  
        
            by Aron Rotteveel
        on Server Fault
        
        See other posts from Server Fault
        
            or by Aron Rotteveel
        
        
        
        Published on 2010-03-11T09:16:16Z
        Indexed on 
            2010/03/15
            9:40 UTC
        
        
        Read the original article
        Hit count: 713
        
Here's the situation:
Setup:
- 1 Windows Server 2008 machine acting as a Domain Controller and RRAS server
 - 1 CentOS machine in a datacentre located elsewhere
 - PPTP client running on CentOS machine, connected to the DC via
 
When I connect to the DC, everything is working fine. I have set up a static IP for the dialup connection in my RRAS server so that the CentOS machine is automatically assigned the IP 192.168.1.240.
Inside the VPN, it is not possible to access this machine on the local IP-address. Perfect. However, after several hours, it simply seems to stop working (IE: I cannot ping to or from this machine on the local network).
The strange thing is, however:
- The DC shows the VPN client as still being connected
 - The CentOS machine shows the network interface as being up
 - There are no entries in my 
/var/log/messagesthat indicate a problem 
Output from ifconfig:
ppp0      Link encap:Point-to-Point Protocol
          inet addr:192.168.1.240  P-t-P:192.168.1.160  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          RX packets:43 errors:0 dropped:0 overruns:0 frame:0
          TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3
          RX bytes:4511 (4.4 KiB)  TX bytes:15071 (14.7 KiB)
Output from route -n:
192.168.1.160   0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 ppp0
I have the following in my ip-up.local:
route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0
The situation can be easily fixed by issueing a killall pppd and re-connecting. However, I obviously do not want to do this every X-hours or so.
I have tried running pppd with both the debug as the kdebug flag but cannot find the cause of this problem.
Currently, my ppp0 network interface seems to be running and the last log lines mentioning it are:
Feb 19 14:10:40 graviton pppd[10934]: local  IP address 192.168.1.240
Feb 19 14:10:40 graviton pppd[10934]: remote IP address 192.168.1.160
Feb 19 14:10:40 graviton pppd[10934]: Script /etc/ppp/ip-up started (pid 10952)
Feb 19 14:10:40 graviton pppd[10934]: Script /etc/ppp/ip-up finished (pid 10952), status = 0x0
Feb 19 14:11:27 graviton pptp[10935]: anon log[decaps_gre:pptp_gre.c:414]: buffering packet 190 (expecting 189, lost or reordered)
Feb 19 14:11:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Feb 19 14:11:37 graviton pptp[10942]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Feb 19 14:12:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Request received.
Feb 19 14:12:37 graviton pptp[10942]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 6 'Echo-Reply'
Feb 19 14:12:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:13:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:14:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:15:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:16:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:19:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:677]: Echo Reply received.
Feb 19 14:19:37 graviton pptp[10942]: anon log[logecho:pptp_ctrl.c:679]: no more Echo Reply/Request packets will be reported.
I have enabled the persist option. The network interface is still running, but it is still impossible to send data through the VPN. 
Any help is appreciated.
© Server Fault or respective owner