How to fix the 4 biggest problems with VPN connections
– 👌
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 problem areas with VPN connections and how you can fix them.
Editor’s note: In the video, Brandon Vigliarolo uses Microsoft Windows Server 2016, and some steps and menus differ from the following tutorial by Brien Posey. This tip was first published in May 2003.
VPNs have gone from obscurity to being a popular way to connect private networks together across the Internet. Although VPNs initially became popular because they freed businesses from the expense of connecting networks with dedicated leased lines, part of the reason VPNs are accepted is that they tend to be very reliable. However, VPN connections sometimes have problems. Here are several methods that you can use to troubleshoot VPN connections.
We see: How to work from home: The IT pros’ guide to telecommuting and telecommuting (TechRepublic Premium)
What is the problem?
There are four types of issues that typically occur with VPN connections. These include:
- VPN connection denied.
- Accept unauthorized connection.
- Inability to access websites that are located outside the VPN server.
- Inability to create a tunnel.
1: The VPN connection is denied.
VPN client connection refusal is probably the most common VPN problem. Part of the reason why this issue is so common is that there are a lot of issues that can result in the connection being refused. If your VPN server refuses client connections, the first thing you need to do is check to make sure that the Routing and Remote Access service is running. You can check this by opening the Server Control Panel and clicking on the Administrative Tools icon, followed by the Services icon.
Once you have verified that the necessary services are running, try to ping the VPN server by the IP address from the VPN client. You have to ping the IP address initially so that you can check that you have a basic TCP/IP connection. If the ping succeeds, ping the server again, but this time using the server’s fully qualified domain name (FQDN) instead of its address. If this ping fails as the ping of the IP address succeeds, you have a DNS issue, because the client is unable to resolve the server name to an IP address.
Check the authentication process
Once you have established that there is a valid TCP/IP connection between a VPN client and server, and that name resolution is working correctly, the next thing to check is the authentication process. As you know, there are a lot of different authentication methods available for a VPN connection. Both the VPN client and the VPN server must have at least one common authentication method.
You can check to see what authentication methods the VPN server is configured to use by entering the MMC command at the launch prompt. When you do this, Windows will open an empty session from the Microsoft Management Console. 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 available plug-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 plug-in should be added to the console. Right-click on your VPN server menu and select the properties command from the resulting shortcut menu. This will display the server properties sheet. Select the Security tab and click the Authentication Methods button. This will cause Windows to display a dialog with all available authentication methods. You can enable or disable authentication methods by selecting or deselecting the appropriate check boxes.
The method of validating the authentication method on the client end varies depending on the client’s operating system. For Windows XP, right-click on the VPN connection and select the properties command from the resulting shortcut menu. This will reveal the connection properties sheet. Now, select the Security tab on the property sheet, 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 should verify that the client supports RADIUS and that the VPN server has no problem connecting to the RADIUS server.
See: Understanding VPNs and How to Choose One (CNET)
More things to check
If the authentication methods appear to be set correctly, the next step is to check the technology by which the client is trying to connect to the VPN server. If the client is connecting to the server, rather than online, it is possible that the remote user does not have connection privileges. You can check the privileges either by looking at the Request tab in the user 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 already knows how to establish a VPN connection and that the user is using the correct username and password.
This may seem obvious, but if your domain is running in Windows 2000 Native Mode, your VPN server must be a member of the domain. If the VPN server does not join the domain, it will not be able to authenticate the logins.
You also need to look at the IP addresses. Each web-based VPN connection actually uses two different IP addresses of the VPN client computer. The first IP address is the one assigned by the customer’s ISP. This is the IP address used to establish the initial TCP/IP connection to the VPN server over the Internet. However, once the client connects to the VPN server, the VPN server assigns a secondary IP address to the client. This IP address has the same subnet as the local network and thus allows the client to connect to 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 clients directly from the VPN server. In either case, if the server runs out of valid IP addresses, it will not be able to assign an address to the client and the connection will be refused.
For environments where a DHCP server is used, one of the most common setup errors is selecting an incorrect NIC. If you right-click on the VPN server in the Routing and Remote Access console and choose the properties command from the resulting shortcut menu, you will see the server properties sheet. The IP tab of the property sheet contains radio buttons that allow you to specify whether to use a static address pool or a DHCP server. If you select the DHCP server option, you must select the appropriate network adapter from the drop-down list under the tab. You must specify a network adapter with a TCP/IP path to the DHCP server.
2: Accepting unauthorized communications.
Now that we have discussed the reasons for connection denial, let’s have a look at the opposite issue where unauthorized connections are accepted. This problem is less common than no connection at all, but more serious due to potential security issues.
If you look at the user properties sheet in the Active Directory Users And Computers console, you will notice that the Dial In tab contains an option to control access through a remote access policy. If this option is checked and the effective remote access policy is set to allow remote access, the user will be able to connect to the VPN. Although I haven’t been able to personally recreate the situation, I’ve heard rumors that there is a bug in Windows 2000 that causes the connection to be accepted even if the effective remote access policy is set to Deny user connection, which is better to allow or deny connections directly through Active Directory Users and Computers console.
See: The Best Mobile VPNs Can Ensure Your Privacy Anywhere (ZDNet)
3: Not being able to access sites outside the VPN server.
Another common VPN problem is that the connection is established successfully, but the remote user is unable to access the network outside the VPN server. By far, the most common cause of this problem is that the user is not given permission to access the entire network. If you’ve ever worked with Windows NT 4.0, you may remember a setting in RAS that allows you to control whether a user has access to a single computer or to the entire network. This specific setting does not exist in Windows 2000, but there is another setting that does the same thing.
To allow the user to access the entire network, go to the Routing and Remote Access console and right-click on the VPN server that is experiencing the problem. Select the properties command from the resulting shortcut menu to display the server’s property sheet, then select the IP tab of the property sheet. At the top of the IP tab is the Enable IP Routing check box. If this checkbox is enabled, VPN and RAS users will be able to access the rest of the network. If the check box is not checked, these users will only be able to access the VPN server, but nothing beyond that.
The problem could also be related to other routing issues. For example, if a user connects directly to a VPN server, it is usually best to configure a static path between the client and server. You can configure a static path by going to the Request tab in the user properties sheet in Active Directory Users And Computers, and selecting the Apply static path check box. This will cause Windows to display a Static Routes dialog. Click on the Add Route button and then enter the destination IP address and netmask in the space provided. The scale should be left at 1.
See: Cybersecurity in the World of Internet of Things and Mobile Devices (ZDNet Special Report) | Download the report in PDF format (TechRepublic)
If you are using a DHCP server to assign IP addresses to clients, there are two other issues that may cause users to be unable to bypass the VPN server. One such problem is the problem 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 that the user does not receive an address at all. Most of the time, if the DHCP server can’t assign a user IP address, the connection won’t get that far. However, there are situations when the address assignment fails, so Windows automatically assigns an address to the user from the 169.254.xx range. If the client is assigned an address in this range, but this address range is not in the system routing tables, the user will not be able to navigate the network outside the VPN server.
4: The difficulty of constructing a tunnel.
If everything seems to be working fine, but you can’t create a tunnel between the client and server, there are two main possibilities of what could be causing the problem. The first possibility is that one or more of the routers in question are filtering IP packets. IP packet filtering can block IP tunnel traffic. I recommend checking the client, server, and any devices in between for IP packet filters. You can do this by clicking the Advanced button on each device’s TCP/IP Properties sheet, selecting the Options tab from the TCP/IP Advanced Settings Properties sheet, selecting TCP/IP Filtering, and clicking the “Characteristics”.
Another possibility is that the proxy server is standing between the client and the VPN server. The proxy server performs a NAT translation on all traffic flowing between…
[ad_1]
Don’t forget to share this post with friends !
