I've been fighting this for the last three days and doing extensive on-line research. I have a new Windows 2003 EE server running behind a LinkSys RV042. The goal is to PPTP into it using either/both Windows 2000 Pro or Windows XP Pro VPN from a different site's network. I've done extensive Ethereal captures on the network traffic on both ends. What I've discovered so far is...
The PPTP connects and I can successfully browse shared folders on the Win03 server. I can successfully upload large files to the Win03 server. Downloading large files fails with an inpage error. Attempting to remote desktop gives the classic "black screen" and "network broken" symptoms well described as being related to MTU packet loss.
I have performed the various registry adjustments recommended by Microsoft (and others) to reduce the MTU on both the server and clients to first 576 and then later to 512 just to create extra margin. After both adjustments, Ethereal has indicated that the MSS reported during the transactions responded appropriately to the MTU changes. Also, Ethereal finds no packets larger than the MTU. (I performed the "ping" test for MTU and discovered that the RV042 router is rejecting DF marked packets over 576 bytes in size, but will accept 576 byte packets with DF set.)
The Ethereal captures show no obvious problems with packets being sent from the clients to the server. This would agree with being able to browse the server and upload large files to the server.
Specifically concerning trying to create a remote desktop connection through an existing PPTP connection: When doing an Ethereal sniff of the TCP traffic headed into the VPN tunnel (as opposed to the traffic on the wire), there is a clear indication of the first large PPTP frame (1441 bytes) sent from the server never being acknowledge by the client. The server retries the frame a few times, then reduces the frame to 590 and tries again a few times. The client never responds and the server finally sends out the RST to which the client responds with RST.
By running a capture of the tunnel traffic at the same time as the wire traffic, I can use the timestamps to reasonably correlate which GRE/PPP wire packets contain any given tunnel packet. What I can see is that the 1441 tunnel frame is split into four "IP fragmented frames" on the wire. It happens to be the first tunnel frame that results in any wire "IP fragmented frame". The size of each of these IP fragmented wire packets is below the 512 MTU, so the size of the packets themselves does not appear to be the issue. However those packets never arrive at the client.
This is leading me to wonder whether the LinkSys RV042 router is possibly eating "IP fragmented" packets. Or possibly some other router in the path. My main interest is in the RV042 since I control it.
BTW... I can dial-out (56K modem) to AOL and come back in through the RV042 router from the outside and everything works. The router is connected to an RCA cablemodem on a Time Warner cable network. The remote desktop comes up fine. However the Ethereal capture of that conversation is dramatically different from the conversation when trying to connect from the network at the other site. I'm accepting that the dial-up nature of the AOL connection accounts for the signficant difference.
I'm wondering if anyone has any experience with the RV042 and its handling of IP fragmented packets. I'm also wondering if anyone knows of a configuration setting for Windows 2003 that will stop if from generating large frames into the tunnel that need to be fragmented on the wire to get below the MTU. I'm not finding any ways to influence the "MTU" for the traffic headed into the tunnel.
Alternately whether anyone has any ingenious methods for testing what might be happening and who might be the culprit.
Thanks!
