Latest posts by Joseph Moody (see all)
- Outlook attachments now blocked in Office 365 - Tue, Nov 19 2019
- PolicyPak MDM Edition: Group Policy and more for BYOD - Tue, Oct 29 2019
- SmartDeploy: Easy software and OS deployment - Tue, Oct 1 2019
An Always On VPN infrastructure is complex. The chances are that if you are reading this, your Always On VPN setup is failing to connect clients to your internal network. This could be caused by an invalid VPN certificate, incorrect NPS policies, or issues in Routing and Remote Access. Or you might be running into problems with the client deployment scripts from Microsoft. Either way, let’s walk through the Always On VPN connection process and fix some failures!
Understanding the core components of the Always On VPN infrastructure is the first step in troubleshooting and testing your VPN connection. If you haven’t done so, review this services guide first as it lays out the server role relationships.
This article is divided into two sections. In the first section, client installation issues are discussed. In the second session, client connection issues are addressed. Because Always On VPN services are interrelated, there will be some overlap between the two sections.
PowerShell installation script issues ^
Grab a test machine and ensure that you are connected to an external network. I prefer to use the computer that I configured the VPN template on as it allows me to test initial golden settings. Select your VPN template (either in Settings or from the notification area at the bottom right of the Taskbar). Press Connect.
Hopefully, your VPN template connected successfully. If it did not, you will need to refer to the second section and resolve the template connection issue first. Now disconnect the session and install the Always On VPN profile. There are multiple ways to install the VPN profile, and the most troublesome one is when using the VPN_Profile.ps1 script.
The most common issues when manually running the VPN_Profile.ps1 script are:
- The user is not logged in interactively, or you are using a remote connection tool that messes with the user logon detection mechanism. Ensure that RDP or another remote connection method is not being used.
- The user is not an administrator of that local machine while the script is being run. (They do not have to be an administrator after the script has completed successfully.)
- Additional PowerShell security features have been enabled. Ensure that the PowerShell execution policy is not blocking the script. Consider turning off Constrained Language mode if enabled. (Constrained Language mode can be activated after the script completes successfully.)
- Other security features, such as AppLocker, are blocking the script from completing.
If you are still having an issue installing the VPN connection on a client, leave a detailed comment below.
Always On VPN client connection fails ^
Good news! The problem is likely to be a small misconfiguration or missing check mark somewhere. The trick is finding out where that misconfiguration is. On the client template machine, open the Application Event log and look for events with a RasClient source. You should see a message and an error code. Microsoft provides some basic guidance for Always On VPN 800 X errors here.
Always On VPN Error Code 809 is caused by UDP 500 or 4500 being blocked on the VPN server or the firewall.
An Always On VPN client goes through several steps before a connection is established. The items listed below are roughly in order from the beginning until the end of the connection process.
- Is the template machine externally connected? A whatismyip scan should show a public IP address that does not belong to you.
- Can you resolve the Remote Access/VPN server name to an IP address. In Control Panel\Network and Internet\Network Connections, open the properties for your VPN Profile. The value in the General tab should be publicly resolvable through DNS.
- Can you access the VPN server from an external network? Consider opening ICMP to the external interface and pinging the name from the remote client. After a ping is successful, you can remove the ICMP allow rule.
- Do you have the internal and external NICs on the VPN server configured correctly? Are they in different subnets? Does the external NIC connect to the correct interface on your firewall?
- Are UDP 500 and 4500 open from the client to the VPN server’s external interface? Check the client firewall, server firewall, and any hardware firewalls.
- Port 500 is used for IPSEC. Ensure that you do not have IPEC disabled or blocked anywhere.
- Does everyone have the correct certificates (users and servers)? Refer to Part 2 if you aren’t sure.
- Check your NPS rules and client configuration carefully. Ensure that you have the correct VPN server IP specified as an NPS client. Make sure that you are authenticating with PEAP, and the Protected EAP properties should only allow authentication with a certificate. You can check the NPS event logs for authentication failures. Refer to Part 3.
- Is certificate validation failing? If you are not sure, test by unchecking Verify the server’s identity; click Configure and uncheck the same option there as well.
If you connect but do not have internet/local network access, check your DHCP/VPN server IP pools for configuration issues.
- If you connect and have a valid internal IP but do not have access to local resources, ensure that clients know how to get to those resources. Your VPN server can be used to route requests.
Hopefully, your issue was fixed in one of the bullet points above! If you still have a connection issue, leave a detailed comment below. If you had another problem and fixed it, be sure to let me know as well.