Fix the four biggest problems with VPN connections

Takeaway: When they work, VPNs are great. When they don't, you can go crazy trying to figure out what's wrong. Here are four of the biggest trouble areas with VPN connections and how you can fix them.

VPNs have gone from obscurity to being a common method of linking private networks together across the Internet. Although VPNs initially became popular because they free companies from the expense of connecting networks with dedicated leased lines, part of the reason that VPNs have become so accepted is that they tend to be very reliable. Even so, VPN connections do occasionally experience problems. Here are several techniques you can use to troubleshoot VPN connections.

What’s the problem?
There are four types of problems that tend to occur with VPN connections. These include:

1.The VPN connection being rejected.
2.The acceptance of an unauthorized connection.
3.The inability to reach locations that lie beyond the VPN server.
4.The inability to establish a tunnel.


The VPN connection is rejected
Having a VPN client’s connection rejected is perhaps the most common VPN problem. Part of the reason this problem is so common is that there are a lot of issues that can cause a connection to be rejected. If your VPN server is rejecting client connections, the first thing you need to do is to check to make sure the Routing And Remote Access service is running. You can check this by opening the server’s Control Panel and clicking on the Administrative Tools icon, followed by the Services icon.

Once you've verified that the necessary services are running, try pinging the VPN server by IP address from the VPN client. You should ping by IP address initially so that you can verify that basic TCP/IP connectivity exists. If the ping is successful, then ping the server again, but this time ping by the server’s fully qualified domain name (FQDN) rather than by its address. If this ping fails where the IP address ping succeeded, you have a DNS problem, because the client is unable to resolve the server’s name to an IP address.

Check on the authentication process
Once you've established that there is a valid TCP/IP connection between the VPN client and server, and that name resolution is working correctly, the next thing to check is the authentication process. As you may know, there are a lot of different authentication methods available to a VPN connection. Both the VPN client and the VPN server must have at least one authentication method in common.

You can check to see which authentication methods the VPN server is configured to use by entering the MMC command at the Run prompt. When you do, Windows will open an empty Microsoft Management Console session. Now, select the Add / Remove Snap In command from the Console menu. When you see the Add / Remove Snap In properties sheet, click the Add button on the Standalone tab. This will reveal a list of the available snap-ins. Select Routing And Remote Access from the list and click the Add button, followed by the Close and OK buttons.

Now, the Routing And Remote Access snap-in should be added to the console. Right-click on the listing for your VPN server and select the Properties command from the resulting shortcut menu. This will display the server’s properties sheet. Select the Security tab and click the Authentication Methods button. This will cause Windows to display a dialog box with all of the available authentication methods. You can enable or disable authentication methods by selecting or deselecting the appropriate check boxes.

The method for checking the authentication method on the client end varies depending on the client’s operating system. For a Windows XP system, right-click on the VPN connection and select the Properties command from the resulting shortcut menu. This will reveal the connection’s properties sheet. Now, select the properties sheet’s Security tab, select the Advanced radio button, and click the Settings button to reveal the available authentication methods.

I usually prefer to use Windows Authentication in VPN environments, but RADIUS is also a popular choice. If you are using RADIUS Authentication, you must verify that the client supports RADIUS and that the VPN server has no trouble communicating with the RADIUS server.

More things to check
If the authentication methods appear to be set correctly, the next step is to check the technique by which the client is trying to connect to the VPN server. If the client is dialing in to the server, rather than connecting through the Internet, it could be that the remote user has no dial-in privileges. You can check the privileges either by looking at the Dial In tab on the user’s properties sheet in Active Directory Users And Computers, or by looking at the domain’s remote access policy. This would also be a good time to verify that the user actually knows how to establish the VPN connection and that the user is using the correct username and password.

This may sound obvious, but if your domain is running in Windows 2000 Native Mode, your VPN server needs to be a member of the domain. If the VPN server hasn’t joined the domain, it will be unable to authenticate logins.

You also need to take a look at IP addresses. Each Web-based VPN connection actually uses two different IP addresses for the VPN client computer. The first IP address is the one that was assigned by the client’s ISP. This is the IP address that’s used to establish the initial TCP/IP connection to the VPN server over the Internet. However, once the client attaches to the VPN server, the VPN server assigns the client a secondary IP address. This IP address has the same subnet as the local network and thus allows the client to communicate with the local network.

At the time you set up the VPN server, you must either specify that the server will use a DHCP server to assign addresses to clients, or you can create a bank of IP addresses to assign to clients directly from the VPN server. In either case, if the server runs out of valid IP addresses, it will be unable to assign an address to the client and the connection will be refused.

For environments in which a DHCP server is used, one of the more common setup errors is specifying an incorrect NIC. If you right-click on the VPN server in the Routing And Remote Access console and select the Properties command from the resulting shortcut menu, you’ll see the server’s properties sheet. The properties sheet’s IP tab contains radio buttons that allow you to select whether a static address pool or a DHCP server will be used. If you select the DHCP server option, you must select the appropriate network adapter from the drop-down list at the bottom of the tab. You must select a network adapter that has a TCP/IP path to the DHCP server.

Acceptance of unauthorized connections
Now that I’ve discussed reasons why a connection might be refused, let’s take a look at the opposite problem in which unauthorized connections are accepted. This problem is much less common than not getting connected at all, but is much more serious because of the potential security issues.

If you look at a user’s properties sheet in the Active Directory Users And Computers console, you’ll notice that the Dial In tab contains an option to control access through the remote access policy. If this option is selected and the effective remote access policy is set to allow remote access, the user will be able to attach to the VPN. Although I have been unable to re-create the situation personally, I have heard rumors that a bug exists in Windows 2000 that causes the connection to be accepted even if the effective remote access policy is set to deny a user’s connection, and that it’s best to allow or deny connections directly through the Active Directory Users And Computers console.

Inability to reach locations beyond the VPN server
Another common VPN problem is that a connection is successfully established, but that the remote user is unable to access the network lying beyond the VPN server. By far, the most common cause of this problem is that permission hasn’t been granted for the user to access the entire network. If you have ever worked with Windows NT 4.0, you may recall a setting in RAS that allowed you to control whether a user had access to one computer or to the entire network. This particular setting doesn’t exist in Windows 2000, but there is another setting that does the same thing.

To allow a user to access the entire network, go to the Routing And Remote Access console and right-click on the VPN server that’s having the problem. Select the Properties command from the resulting shortcut menu to display the server’s properties sheet, and then select the properties sheet’s IP tab. At the top of the IP tab is an Enable IP Routing check box. If this check box is enabled, VPN and RAS users will be able to get to the rest of the network. If the check box is not selected, these users will be able to access only the VPN server, but nothing beyond.

The problem could also be related to other routing issues. For example, if a user is dialing directly in to the VPN server, it’s usually best to configure a static route between the client and the server. You can configure a static route by going to the Dial In tab of the user’s properties sheet in Active Directory Users And Computers, and selecting the Apply A Static Route check box. This will cause Windows to display the Static Routes dialog box. Click the Add Route button and then enter the destination IP address and network mask in the space provided. The metric should be left at 1.

If you're using a DHCP server to assign IP addresses to clients, there are a couple of other problems that could cause users not to be able to go beyond the VPN server. One such problem is that of duplicate IP addresses. If the DHCP server assigns the user an IP address that is already in use elsewhere on the network, Windows will detect the conflict and prevent the user from accessing the rest of the network.

Another common problem is the user not receiving an address at all. Most of the time, if the DHCP server can’t assign the user an IP address, the connection won’t make it this far. However, there are situations in which an address assignment fails, so Windows automatically assigns the user an address from the 169.254.x.x range. If the client is assigned an address in this range, but this address range isn’t present in the system’s routing tables, the user will be unable to navigate the network beyond the VPN server.

Difficulty establishing a tunnel
If everything seems to be working well, but you can’t seem to establish a tunnel between the client and the server, there are two main possibilities of what could be causing the problem. The first possibility is that one or more of the routers involved is performing IP packet filtering. IP packet filtering could prevent IP tunnel traffic. I recommend checking the client, the server, and any machines in between for IP packet filters. You can do this by clicking the Advanced button on each machine’s TCP/IP Properties sheet, selecting the Options tab from the Advanced TCP/IP Settings Properties sheet, selecting TCP/IP Filtering, and clicking the Properties button.

The other possibility is that a proxy server is standing between the client and the VPN server. A proxy server performs NAT translation on all traffic flowing between the client and the Internet. This means that packets appear to be coming from the proxy server rather than from the client itself. In some cases, this interaction could prevent a tunnel from being established, especially if the VPN server is expecting the client to have a specific IP address. You must also keep in mind that a lot of older or low-end proxy servers (or NAT firewalls) don’t support the L2TP, IPSec, or PPTP protocols that are often used for VPN connections.