PPTP VPN connections stops working after period of time

pptpvpnwindows-sbswindows-sbs-2011

I have a client with an SBS 2011 server which is acting as a PPTP VPN server that is having difficulty maintaining working VPN connections to their server for remote workers.

Client machines are able to connect in to the VPN successfully and access network resources, but after a period of time the VPN appears to ignore packets coming in over the VPN. The VPN connection appears to be connected from the client end, but no access to network resources is possible, including pinging servers etc.

The amount of time before the connection stops isn't fixed. I have had connections stay functional for as long as ~40 hours, and fail after as short a time frame as ~10 minutes. I don't believe it's a connection timeout issue at the server or routers, as the failure occurs even if I repeatedly ping the server on the other end of the connection, or repeatedly request a web page over the VPN.

Wireshark

Once the VPN has failed, if I look at the network traffic on the server using Wireshark, I see the TCP port 1723 control channel is still open, and echo request/replies are happening approximately every minute.

GRE packets are being received by the server from the client, but the server does not appear to respond to them. For example, if I ping the server over the VPN, I can see the GRE encapsulated ICMP echo request arrive at the server, but no echo reply is sent.

RRAS Logging

I've turned on logging to RRAS on the SBS server. I see a few things in the logs that show that the server has deleted the route to the client, but I can't for the life of me identify why. Here is an extract from IPRouterManager.LOG:

[16724] 15:30:24: OnRouteChange: Route Deletion Notification
[16724] 15:30:24: INFO: Converted interface Luid 0x17000002000000 to Index 24. 
[16724] 15:30:24: ConvertRouteInfoToRtm:  pRouteInfo->Flags1   (0x0)  
[16724] 15:30:24: ConvertRouteInfoToRtm: Flags: pRouteInfo  (0x0),  dwRouteFlags  (0x0), pRtInfo  (0x0) 
[16772] 15:30:25: ChangeRouteWithForwarder: Deleting all routes to 10.0.0.24/255.255.255.255
[16772] 15:30:25: GetFirstRouteInfoForDestination returns with 0x0; Index = 0; Dest = 0x1800000a; nexthop = 0x58
[16772] 15:30:25: AllocateAndGetIpAddrTable returns with 0x0
[16772] 15:30:25: IsOnLinkRoute: 0
[16772] 15:30:25: DeleteIpForwardEntry returns with 0x2; Index = 0; Dest = 0x1800000a; nexthop = 0x58
[16772] 15:30:25: SetIpForwardEntry returns with 0x2

Pretty much concurrent with this, I see logs in the PPP.LOG file showing that incoming pings are being "silently discarded" at the server. The packet contents are for an ICMP echo request from the client machine at 10.0.0.24 to the server at 10.0.0.2:

[17292] 03-11 15:30:24:529: Packet received (62 bytes) for hPort 128
[15288] 03-11 15:30:24:529: >PPP packet received at 03/11/2013 05:00:24:529
[15288] 03-11 15:30:24:530: >Protocol = UNKNOWN, Type = UNKNOWN, Length = 0x3e, Id = 0x0, Port = 128
[15288] 15:30:24:530: >00 21 45 00 00 3C 04 52 00 00 80 01 22 56 0A 00 |.!E..<.R...."V..|
[15288] 15:30:24:530: >00 18 0A 00 00 02 08 00 D9 AA 00 03 73 AE 61 62 |............s.ab|
[15288] 15:30:24:530: >63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 |cdefghijklmnopqr|
[15288] 15:30:24:530: >73 74 75 76 77 61 62 63 64 65 66 67 68 69 00 00 |stuvwabcdefghi..|
[15288] 03-11 15:30:24:530:  
[15288] 03-11 15:30:24:530: Network-layer packet rcvd.
[15288] 03-11 15:30:24:530: Packet being silently discarded

Help!

I'm stuck. It looks to me like the server has decided for some reason to terminate the GRE side of the tunnel. Any advice on what else I can look at or suggestions on how to resolve this would be greatly appreciated.

Best Answer

I turns out that this was most likely an issue with Backup Exec Continuous Protection Server (BECPS) software installed on the machine.

The BECPS software creates a scheduled task "BECPS_AUTOGEN_[backup_name]" when installed. Unfortunately, when this task runs, it appears that it (inexplicably) drops all routes for the VPN interfaces, rendering them non-functional.

Uninstalling the BECPS software has been sufficient to allow VPN connections to be maintained in a functional state more or less indefinitely for now. We are running some further tests to see if we can get the software functional without the VPN side effects.