howto://troubleshoot microsoft vpn connections part two-client side issues

Welcome to part two in our series on troubleshooting Microsoft VPN connections. In part one of this series, we covered the error codes that point to server side problems. And in part three, we’ll share some tales from the trenches. But here in the creamy middle, we’re going to go over the error codes that point to problems on the client’s side of things.

There are a couple of very important thing to keep in mind when dealing with client side issues. The first is that you are relying upon an end user to provide you with data. Be patient, take deep breaths, and remember the mute button on your phone.* Second, there are plenty of things on the client network that can completely bork your client’s attempts to connect to your VPN. Some of them will be within your control; most won’t.

Before a client can connect to your VPN, they need an Internet connection. There are certain aspects of that Internet connection that go past simple web surfing though. Sure, they need to be able to view websites. DON’T assume that they can without checking, but keep in mind that IPSec and PPTP VPN connections need some specific outbound holes in the firewall on the client’s network in order to work.

Surfing the web means that outbound, your clients are permitted to source TCP packets from ports >1024, and connect to destinations on TCP 80 (HTTP) and 443 (HTTPS,) both of which use IP type 6 (TCP,) and they probably also can get out using UDP 53 (DNS) over IP type 17 (UDP) unless the local access point or router is providing name resolution. Some corporate guest networks, conference room Internet access, and even hotspots open that up so customers can surf the web; but that’s it. Others may be using a transparent proxy, so your remote clients aren’t able to access web sites directly. Here’s a table that defines the minimum connectivity necessary to support VPNs from the client’s side, not including name resolution.

Outbound traffic requirements

VPN protocol

Outbound ports

Outbound IP types

NAT

PPTP

tcp src>1024, dst=1723

ip type 6 (TCP) and
47 (GRE)

Not an issue

IPSec

udp src>1024, dst=1701, possibly also
dst=500, 4500 for udp encapsulation

ip type 17 (UDP,)
50 (ESP) and 51 (AH)

BIG issue in XP and Vista (see below*). Not an issue in 7.

SSL (SSTP)

tcp src>1024, dst=443

ip type 6 (TCP)

Not an issue

Before spending a great deal of time doing much else, if your client gets a 678, make sure they actually have Internet access. Even free Wi-Fi access points in places like Starbucks, Barnes & Noble, and hotels have a captive portal that makes you check the little box agreeing to their TOS before they will permit your outbound traffic. I have seen dozens of cases where the user didn’t do that before trying to launch their VPN, and lassoed the fail whale as a result.

I like to do three things to make sure all is well on the basic Internet connection before I go any further…

Basic connectivity tests

Have them go to http://www.whattimeisit.com and read to you the time. That way, you know they have Internet, and that they are not viewing cached content.
Have them go to http://www.whatismyip.com and read to you their ip.addr. Then ask them if there is a line underneath that references a proxy, like this.

This will give you two things…their source ip.addr so you can do further testing like traceroutes or sniffing for their incoming traffic, and it will tell you if there is a proxy in play. If there is, you may not be getting this user on the VPN from their current location.
Have them ping your VPN server by name to confirm they can resolve the fqdn and get traffic to your server.

A word about PING

I know, I know, many of you are blocking all ICMP into your network, and I don’t blame you. But experience has taught me that allowing echo requests in to your web server and your VPN server greatly facilitates troubleshooting, while doing practically nothing that makes you less secure. You’ll also find that some of the more IT savvy end users will try to ping things. If they don’t get a response, they’ll open a ticket that the Internet is broken, and we can’t have that. And of course, just because they can ping it doesn’t mean they can connect to it, but by trying, you’re verifying name resolution, and you can infer that if the source network is allowing outbound ICMP, they are probably allowing other things to get out. So if they are not, you at least know now that there is a filter in the way.

Finally, make sure that the telnet client is installed on all your workstations. I don’t expect you to have every user try to telnet to 1723 on your PPTP VPN, but having the tool there leaves this option open to you in case you have a more advanced user on the phone. You might even consider having your user download portqryui (as covered here, and here) if you think they can handle it. It’s not going to solve everything, but it can verify some basic connectivity tests related to VPN…just use the networking set from the drop down box. Keep in mind that none of those tests verify GRE, AH, or ESP. They do verify the necessary TCP ports, and portqryui can check the UDP ports, so they make a good start.

*NAT is evil

You know, you’re right, I have mentioned that once or twice in the past. Don’t get me wrong…conservation of the IPv4 address space is a very good thing, and I am all for using RFC1918 addresses internally, and for using a global NAT for internal clients accessing the Internet, but at the same time, you have to acknowledge that this can bork more than a couple of things. When we use the Microsoft implementation of the IPSec protocol, we’ll find ourselves in a mixed bag of issues depending upon whether we have NAT on the client but not the server, NAT on the server but not the client, no NAT, or NAT on both. It is easy enough for Windows 7 to just deal with automagically, but if we have an XP or Vista client, the fix requires a registry hack and a reboot. See this earlier post for the magick incantation AssumeUDPEncapsulationContextOnSendRule.

Error codes that point to client side issues

And now, without further ado, here are the error codes that point to client side problems.

Error code

Description

Possible explanation

628/629

The port was disconnected (by the remote machine.)

Typically, this is because outbound TCP 1723 is permitted by the client network, but GRE is not. The client starts to make the VPN connection on 1723, outbound GRE is dropped silently, and the server disconnects the client’s TCP session when the LCP negotiation times out. Requires local LAN support to confirm, and to open IP type 47 outbound.

633

The modem (or other connecting device) is already in use or is not configured properly.

You will see this message if you already have one VPN connection active, and try to start another. Ensure that another VPN connection is not already established, and verify network connectivity.

678

There is no answer.

Commonly encountered in hotels and hotspots when a user tries to make a VPN connection but hasn’t agreed to the portal TOS yet, or when only HTTP and HTTPS traffic is allowed out. First, verify user can access websites on the Internet. Then ping the VPN FQDN. Telnet to the VPN FQDN on 1723 or use portqryui to verify connectivity.

692

Hardware failure in port or attached device.

TCP 1723 is blocked, and the firewall sends back a RST/ACK. Consult local network support or switch to SSTP/SSL VPN if available.

711

RasMan initialization failure.

Check for third party software such as IDS/IPS, Norton Internet Security, MacAfee, etc. killing the connection and not notifying the user.

721

Remote PPP peer is not responding.

Check client location firewall…connection was made on TCP 1723 but PPP could not negotiate LCP. Outbound GRE is either dropped silently, or is permitted but the responses are being blocked.

722

The PPP packet is invalid.

Consult network support at client’s location. Fixup PPTP may be enabled on router and killing connections by borking data.

739

The remote server cannot use the Windows NT encrypted password.

Configure client to use MS-CHAPv2 (uncheck SPAP, PAP)

741

The local computer does not support encryption.

Check the client configuration for incorrect settings.

768

The connection attempt failed because of a failure to encrypt data.

Data encryption is required; check settings of manually configured client.

785-793, 798

Various L2TP errors including Smart Cards.

Check client configuration. IPSec encapsulated within UDP requires proper encapsulation setting (remember to reboot if changed.)

800

Generic error.

This is the client’s way of saying “Dude, WTH?” when something fails but the operating system cannot determine what. Check for third party software that could interfere with connection attempts.

806

A connection between your computer and the VPN server has been started, but the VPN connection cannot be completed.

The most common cause is a firewall or IPS closing the GRE connection mid-way through negotiation. Check with local LAN support, especially if they are using an IPS, or Checkpoint firewall with smartdefense enabled.

807

The network connection between your computer and the VPN server was interrupted

Your client got a RST ACK when it tried to connect. Check to see if the firewall is blocking outbound VPN connections.

809

The network connection between your computer and the VPN server could not be established because the remote server is not responding…

Assuming you didn’t just crash the VPN server, nothing is allowed outbound. Contact local network support for the client’s location.

868

The remote connection was not made because the name of the remote access server did not resolve.

Check your DNS. If it is correct, then there is something wrong on the client’s network.

So between the table above and the information in part one of this post, you should have the information at hand to troubleshoot almost any problem with Microsoft PPTP and IPSec VPN connections. Finally, I have to share this little nugget. I can’t tell you how many times troubleshooting issues (VPN or otherwise) for clients has felt like this. Or course, without them, there wouldn’t be a need for us, so *remember your mute button!

Did you find this post helpful? Have any follow-up questions, horror stories, tips & tricks, or other goodies to share? Why not leave a comment and spread the love.