A user located on the other side of the planet has troubles connecting to our PPTP VPN. The VPN is a regular windows server 2003 VPN and works fine for most users from the US, but for this specific person, it doesn't connect at all.
The login window hangs on "verifying username/password" and dies after ~30 seconds.
I took a network trace on the server side, and this is what I see. 10.250.10.10 is the internal IP of the server, 121.X.X.255 is the public IP of the user.
Apparently there is no new network equipment on the user side, and definitely nothing has changed on the server side.
Any idea on how to diagnose this ?
Best Answer
NAT = Network Address Translator (device) or Network Address Translation (concept) depending on context.
PAT = Port Address Translator (device) or Port Address Translation (concept) depending on context
This problem is very common when either end (client or server) is behind a NAT/PAT boundary that does not support the PPTP+GRE protocol -- or does not support it well.
In the realm of PPTP, TCP/1723 is a simple control channel whose sole purpose is to bring up a Microsoft specific secondary GRE (IP/47) tunnel. This GRE tunnel contains encapsulated PPP frames and is used for negotiating authentication, encryption, and passing actual data.
Not all NATs (firewalls, routers, appliances) support passing the secondary GRE tunnel to clients/servers. The PPTP VPN client will appear to connect, get to a "Verifying Username and Password" message and hang there. The "Verifying Username and Password" stage requires the GRE tunnel to be functional.
Some NATs/PATs may support a single PPTP+GRE for a single user behind the NAT/PAT, but a second PPTP+GRE from either the same user or a different user behind the NAT/PAT can fail. I have seen many kinds of spectacular failures with PPTP+GRE through NAT/PAT with both consumer, business, and enterprise grade NATs/PATs
In your specific case -- if other users can connect to your RRAS fine using PPTP+GRE, but this single user cannot -- it is likely the NAT/PAT boundary on that user's network.
Be prepared to spend a lot of time diagnosing this problem if this particular user has substandard Internet and edge hardware -- especially if it is from a provider performing Carrier Grade NAT (CGN).
If you can gain access to the user's PC and run Wireshark on their PC while trying to connect and look for GRE datagrams both to and from the RRAS server. If the GRE tunnel is failing you will likely see a GRE datagram destined for the RRAS server public IP, but not see a return GRE datagram from the RRAS server public IP.
If this is the case the concern is upstream from the PC. Look at all upstream NATs/PATs to ensure they support PPTP+GRE fixup/passthrough/inspection or whatever that vendor calls it. Know that some vendors, despite "support" for PPTP+GRE, only support it in limited manners -- as described earlier. Cisco ASA's and PIX's have had rather excellent support for PPTP+GRE fixup/inspection for quite a while -- usually not enabled by default.
Running PPTP, L2TP, and IPsec VPN's through NAT/PAT are all rather problematic unless care is taken to overcome the NAT/PAT. About the only VPN tech that can penetrate NAT/PAT rather easily is SSL/TLS based VPN's -- in my experience.