Random disconnects when using Windows 7 PPTP VPN client

Hi,

I've had an odd issue with Windows 7's PPTP client connecting to a
PoPToP, and wanted to share this with the list in case anyone else
experiences the same issue.

Basically, there appears to be a bug in Windows 7 RTM's PPTP client
that causes it to send spurious ICMP protocol unreachable messages
when the PPTP client is under load.  In particular, I've found Skype
to trigger this frequently, but it can happen at any time.  The
symptoms are that the PPTP client connects OK and passes data
normally, but after some time, the Windows VPN client disconnects.  On
the PoPToP side, you see simultaneously the well-known 'Protocol not
available' error, usually indicating that the PoPToP server received
an ICMP 'Protocol unreachable' (ICMP Type 3 Code 2) message, and duly
collapsed the GRE tunnel:

pptpd[18194]: GRE: read(fd=7,buffer=6095a0,len=8260) from network
failed: status = -1 error = Protocol not available

Once I broke out Wireshark and started watching the traffic in detail,
I soon found spurious ICMP Protocol Unreachable messages being sent by
the Windows clients:

359062 1237.481525 172.x.x.x 82.y.y.y ICMP Destination unreachable
(Protocol unreachable)

Where the 172.x.x.x address is the Windows 7 client machine, and the
82.y.y.y address is the external address of the PPTP server.  The
Windows client returns the contents of the most recent GRE packet in
the ICMP payload.  Note that the 172.x.x.x address is an RFC1918
private address in this case, but the issue also occurs where the
client has a public IP.

I've worked around this by blocking all ICMP Protocol Unreachable
messages on the PPTP server's firewall, which seems to do the trick.
I use Shorewall for firewalling, and I found I needed to add the
following to /etc/shorewall/rules:

SECTION ESTABLISHED
DROP:debug      any     any     ICMP    protocol-unreachable

SECTION RELATED
DROP:debug      any     any     ICMP    protocol-unreachable

(you can remove the :debug if you're using Shorewall but don't want
debug messages in syslog about these packets)

Once the protocol unreachable message is blocked, the PPTP server no
longer collapses the GRE tunnel.  Instead, a few GRE packets are lost,
but the connection recovers without any indication on the client side.

It also then became obvious why this might have been missed during
testing of Windows 7 - the default Windows Firewall settings on
Windows Servers (and many other VPN devices) block more or less all
ICMP messages by default, which hides the problem.  My hunch is that
the PPTP client was never tested with ICMP messages allowed, and so
the bug was missed.

There is also a hotfix for Win7 slated for SP1 that addresses a race
condition in the Windows VPN system, which may be related.  The
specific description of the fix only talks about L2TP VPNs, but
judging by some of the comments on Microsoft TechNet it seems to solve
a lot of other issues with Win7's VPN client, and the fix appears to
be generic for all of the protocols the Win7 VPN client supports.  I
haven't yet had a chance to test it, so it might not do anything for
this issue.  However you can still block the Protocol Unreachable
messages as above, if necessary.
http://support.microsoft.com/kb/980399/en-us

Hope that helps somebody :-)

Cheers,
James

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Poptop-server mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/poptop-server