Is your VPN active but not functioning? Learn about the four most common VPN connection problems and how to resolve them right away.
Virtual private networks have emerged from obscurity to become a popular choice for tying together private networks. Although VPN use soared because the technology proved to be comparatively easy, dependable, and safe, VPNs gained popularity because they made it possible to use the Internet to protect network connections, obviating the need for pricey dedicated circuits.
However, believing VPNs to be impenetrable creates a false sense of security. Organizations learned the hard way that VPN accounts need continuous monitoring and protection after state-sponsored attacks that leveraged compromised VPNs to facilitate exploitative attacks.
VPNs continue to successfully address a crucial need by reliably and securely connecting other systems, branch offices, authorized partners, and remote employees when security procedures are followed. However, issues with VPN connections inevitably persist.
Problems with Windows servers-powered VPN connections typically fall into one of four groups:
- It rejects the VPN connection.
- It accepts an unauthorized connection.
- Locations outside the VPN server are inaccessible.
- There can be no tunnel built.
- These typical Windows Server-powered VPN connection issues are fixed here.
Using the Windows Server Routing and Remote Access interface
Even when a connection has previously been stable, once a VPN is configured using a Windows Server, connectivity problems can occasionally happen. Microsoft concentrates numerous VPN setup parameters in the Routing and Remote Access console snap-in tool, which is used frequently while troubleshooting Windows servers.
The Microsoft Management Console, or MMC, houses the Routing and Remote Access snap-in. The MMC can be accessed in several ways. The console can be chosen from the list of programs under the Programs’ menu in Windows Server, from the Administrative Tools folder in the Control Panel, or by typing mmc at a command line. Additionally, you can access the MMC by simultaneously pressing the Windows key and the letter R, typing mmc, and then pressing the Enter key.
Administrators should be able to navigate the various consoles using the same method whether using an older version of the server or the most recent Windows Server 2022 iteration, despite the fact that the actual user interface and menu options occasionally differ slightly between specific server versions.
How to resolve the four main issues that cause broken VPN connections
It rejects the VPN connection.
The most frequent VPN issue is probably having a VPN client’s connection refused. The fact that numerous faults might result in a connection being refused is one of the reasons this issue is so prevalent.
Verify that the Routing and Remote Access Service is indeed running on the Windows server if the Windows server-powered VPN is refusing client connections. By choosing Start | Control Panel | Administrative Tools | Services on the Windows server, you may visit the Services interface and do the verification. Navigate to the Routing and Remote Access entry in the list of services while the Services’ console is open to confirm that its service is active.
The Services interface shows the status of the Routing and Remote Access entry, as Brandon Vigliarolo of TechRepublic demonstrates in his video at the beginning of this post. You can start the service by clicking Start the Service in the Service’s panel while the Routing and Remote Access entry is highlighted, or you can right-click the entry and choose Restart. You can open the item, change the Startup Type to Automatic, click Start, and OK if the RRAS service was set to Manual or Disabled.
Pinging the VPN server first by its IP address and then by its fully qualified domain name is a smart idea after making sure the RRAS service is up and functioning, as Vigliarolo also discusses. If you see issues, a DNS issue is probably at play; you should focus your emphasis on fixing it.
However, if the VPN server pings successfully, and you’re still experiencing connection problems, focus on resolving a possible authentication discrepancy. Occasionally, the VPN server and client are configured to use various forms of authentication.
Open the server console to see if the issue is an authentication error. Another way to access the MMC is to press Control+R to launch a command prompt, where you can type mmc and press Enter or click OK to access the MMC.
Navigate to the Routing and Remote Access entry while the console is open. Click File, pick Add/Remove Snap-in, select the Routing and Remote Access option from the selections, click Add, then OK if the entry is missing.
Right-click the VPN server after adding the Routing and Remote Access snap-in, then select Properties. Then, verify the authentication strategy by checking the Security tab. Although RADIUS or another option, such as Windows Authentication, may also be in use, it is more typical. Make that the authentication mechanism chosen in the Security tab is active in the VPN client.
Added details to review
The things we just discussed are typically to blame for the majority of VPN connection refusal issues. However, other fundamentals must also be true.
For instance, the server won’t be able to authenticate logins if the Windows Server hosting the VPN hasn’t joined the Windows domain. The server must first be linked to the domain.
Another key component that requires proper administration settings is IP addresses. The VPN client PC typically utilizes two separate IP addresses for each Web-based VPN connection. The first IP address is the one that the client’s ISP gave them. The initial TCP/IP connection to the VPN server over the Internet is made using this IP address. However, the VPN server gives the client a secondary IP address after the client connects to the VPN server. This IP address often belongs to the same subnet as the local network, enabling communication between the client and local network.
You can either construct a bank of IP addresses to assign addresses to clients directly from the VPN server, or you can configure a DHCP server to do so when you set up the VPN server. In either scenario, if the server runs out of usable IP addresses, it will be unable to give the client an address and would reject the connection.
A common configuration mistake for DHCP server installations is choosing the wrong NIC. The server’s properties should be visible if you right-click on the VPN server within the Routing and Remote Access snap-in and choose the Properties option from the resulting shortcut menu. The relevant IP page has settings that let you choose the DHCP source. Make sure the correct network adapter is used if the DHCP server option is enabled. The network adapter you choose must have a TCP/IP connection to the DHCP server.
2: A rogue connection is permitted.
Let’s now examine the situation where unauthorized connections are permitted. This issue is significantly less frequent than not connecting, but it is much more important due to the possible security risks and unwanted traffic that could arise.
The Dial In tab typically has a setting to limit access using the remote access policy, if you look at a user’s properties sheet in the Active Directory Users and Computers console. The user will be able to connect to the VPN if this option is chosen and the effective remote access policy is configured to permit remote access.
Despite my inability to replicate the issue firsthand, I have heard stories that an issue with older Windows servers may allow connections to be accepted even when the effective remote access policy is configured to block them. Therefore, it’s recommended to authorize or prohibit connections directly through the Active Directory Users and Computers dashboard, especially on older server architectures.
To aid in preventing unwanted VPN access, a number of additional security fundamentals should also be in place. When possible, unnecessary VPN accounts should always be terminated or even eliminated. Users should be obliged to routinely update the passwords associated with their accounts, and such passwords should adhere to complexity standards.
All VPN connections should be subject to multifactor authentication, and network firewalls and security services should be constantly on the lookout for unauthorized or suspect connections in order to send out high-priority notifications whenever potential problems arise. Putting those measures into practice will lessen the possibility that an unauthorized connection will be accepted.
3. Remote locations outside the VPN server are inaccessible.
Another frequent issue with VPNs is when a connection is made, but the remote user is unable to access the network outside the VPN server. The fact that the user doesn’t have permission to access the full network is by far the most frequent source of this issue.
Go to the Routing and Remote Access console, right-click on the problematic VPN server, and then grant the user access to the entire network. To display the server’s properties page, choose the Properties command from the shortcut menu that appears, and then choose the IP tab. An Enable IP Routing check box is located at the top of the IP tab. In the event that network firewalls and security-as-a-service settings allow it, users of VPNs will be able to access the rest of the network if this check box is enabled. These users will only be allowed to access the VPN server if the checkbox is not checked. They won’t have access to anything else.
Another routing issue can possibly be the cause of the issue. For instance, it’s typically ideal to set up a static route between the client and the server if a user is phoning straight into the VPN server.
By choosing the Apply A Static Route check box in Active Directory Users and Computers’ Dial In tab of the user’s properties sheet, you may set up a static route. Windows will then show the Static Routes dialog box as a result. After entering the target IP address and network mask in the spaces given, click the Add Route button. The metric need to remain at 1.
There are a few more issues that could prevent users from leaving the VPN server if a DHCP server is being used to allocate IP addresses to clients. The issue of redundant IP addresses is one such issue. Windows will identify the conflict and bar the user from accessing the rest of the network if the DHCP server gives the user an IP address that is already in use on another device on the network.
Not receiving any addresses at all is another frequent issue. Most of the time, the connection won’t get thus far if the DHCP server is unable to give the user an IP address. The user will automatically be given an address from the 169.254.x.x range by Windows in cases where an address assignment fails. The user won’t be able to leave the VPN server’s network if the client is given an address in a range that isn’t listed in the system’s routing tables.
This difficulty can also be influenced by other factors. Make that the user can access the resources they’re trying to access on the network they’re connecting to.
It’s possible that the user is looking for a resource on the wrong network or on a subnet that the network to which the user is connected cannot access, given the proliferation of servers, cloud platforms, and application as a service possibility. It may be necessary to establish a VPN connection to the other subnet. If there is a firewall or security as a service solution between the VPN server and the resources the user is trying to access, check the settings of those components as well.
4: It is impossible to build a tunnel.
There are two primary things that could be wrong, if everything appears to be working well, but you still can’t get a tunnel to form between the client and the server.
The first scenario is that one or more of the relevant routers are filtering IP packets. IP tunnel traffic could be avoided with IP packet filtering. I advise looking for IP packet filters on the client, the server, and any devices in between. You can accomplish this by selecting TCP/IP Filtering from the Options tab on the Advanced TCP/IP Settings Properties sheet, clicking the Properties button, and then clicking the Advanced button on each machine’s TCP/IP Properties sheet.
The presence of a proxy server between the client and VPN server is an additional possibility. All Internet traffic traveling between a client and a proxy server is translated using NAT. As a result, transmissions seem to originate from the proxy server rather than the client. In some circumstances, this interaction might impede the establishment of a tunnel, particularly if the VPN server anticipates the client to have a particular IP address.
The L2TP, IPSec, or PPTP protocols, which are frequently used for VPN connections, are not supported by older or low-end proxy servers (or NAT firewalls).
In some instances, a VPN tunnel may not be able to create because of firewall security services or security as a service solution. To confirm that the Windows server-powered VPN traffic is fully supported, check the configuration of those various devices or services.
