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. is the internal IP of the server, 121.X.X.255 is the public IP of the user.

PPTP connection fail handshare

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 ?

  • I've run into similar issues; and usually it ends up being a firewall or other piece of hardware that is somewhere up stream. In my circumstance, it was a older linux box acting as a "router" at the service provider. It took us months to figure it out; and in the end the only thing we could do was change providers. Oct 11, 2011 at 17:23
  • yeah, I'm kind of afraid of that, considering the user is in the Philippines. The connection is already rather slow, and I have no idea how the infrastructure is maintained passed the home router. Oct 11, 2011 at 18:00
  • In a lot of countries where they like to be able to filter and control what their people have access to, I would expect to see this kind of thing. I know there are other countries who actively try to prevent the use of VPN's (the people can use VPN's to bypass the government's restrictions on content). One thing you might want to consider is upgrading to a hardware or software VPN package that supports SSL VPN's; it's probably going to be a lot easier to manage for far-away clients like that. Oct 11, 2011 at 18:03

2 Answers 2


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.

  • Very nice answer ! Thanks for taking the time to write it. The client is working remotely from the Philippines and I do not control the network equipments there, probably some random home wifi router. But I will try to obtain a network trace from the client's computer as well. This is going to be fun to diagnose.... might be easier to switch to vpn-ssl right away. Oct 12, 2011 at 16:00

I don't see an ACK from the client to the server's SYN-ACK. Here's a snippet of a Microsoft Network Monitor capture from my workstation to an internal RRAS server. You can clearly see the TCP three way handshake occurring before any PPTP negotiation takes place. If the client ACK to the server's SYN-ACK isn't taking place then I'd say that's where the problem is.

enter image description here


Using Wireshark on the server this time, I see the same thing as you when looking at the conversation flow. There is a slight difference as evidenced in the below screen shot. There are 3 Set-Link-Info control messages in my capture as opposed to the 1 in your capture. My guess is that the server and client are failing to negotiate the connection parameters. Beyond that I have no clue. Sorry I couldn't be of more help.

enter image description here

  • The TCP stack on the server would refuse to pass the connection in ESTABLISHED state if the ACK from the client wasn't received. In this particular case, the 3 packet contain both the ACK to finish the handshake, and the first PPTP data. It's pretty common in TCP connections to have the 3rd packet of the handshake carry data as well. Oct 12, 2011 at 2:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .