Issue Accessing Network shares over Always On VPN

VPN
1

Hi folks,

I’ve been tasked with resolving an issue that cropped up a couple months ago regarding Always On VPN. We have the VPN configured so that users can connect to the company network automatically on start-up. The primary purpose of this VPN is to allow access to company shares while working remotely. This VPN is deployed to our users via a powershell script that is run upon login via a GPO. The VPN itself appears to work just fine. People turn on their machines, connect to the VPN, and they can ping our network. There have been no changes to our network infrastructure in the past two months and our VPN’s configuration and deployment has remained the same as it was 3 years ago. The server’s VPN certificate and the client’s are both valid.

Many of our network shares are already mapped via group policy, and there seems to be no issue with users being able to connect to those. However, some sites have their own network shares that are not mapped via GPO, and when they are mapped manually or reached by a UNC path, they are presented with a prompt for the user’s domain credentials and error underneath stating:

“The system cannot contact a domain controller to service the authentication request. Please try again later.”

If the user enters their credentials, 9 times out of 10, the drive is mapped and they can see the share, but if they log off or reboot, they have to go through this process again and remove the drive map before trying again.

Now, I’m pretty confused by the error, because in my testing, the client machine can ping our domain controllers both by name and IP, and resolution seems to be working in relation to the Group policy mapped drives. In my testing, I’ve collected some event logs while on a remote client machine, and the system logs that I have collected have the event ID’s of 9, 1129, 40960, and 1048. These logs have to do with either DNS events about reaching the domain controller, or being unable to determine the the revocation status of the domain controller certificate used for authentication, but in light of my connectivity tests, I’m not sure they’re related.

I’m looking for more ways to test and diagnose the issue, but part of me doesn’t know where to start looking. If anyone has any ideas and can point me in the right direction, it’d be greatly appreciated.

2

idk man, if you work over wlan it sometimes on my companies dell laptop takes like 30 seconds until he finds the wlan adapter. thats when i get the error couldnt map some network drives.

3

Make sure the clients don’t have stale DNS data in the cache.

4

I don’t know man. It could be possible that mounting network drives as set as a local setting instead of the domain profile or gpo could be run before the vpn auto connect. So it fails before the connection process and then doesn’t try again after the connection succeeds. Maybe attach a logon script to reattach network drives will help?

5

Sounds like Cisco AnyConnect. If it is, make sure you have DART installed (Diagnostic and Reporting Tool) and create a support bundle. There are good logs in there if you’re willing to look for them.

6

I know you checked some certificates but have you checked the revocation list? If you have an offline root ca it sounds likely its revocation list has expired on your online intermediate. It will cause that issue.

7

Any asymmetrical routing issue possible? SMB gets mad. Pings would work fine,

8

You mention other sites. Are they configured in AD Sites and Services? Are the sites connected to main site via site to site?

9

UPDATE: So I’ve had some interesting results. When users map our network drives, they are using the NetBIOS name of the server in the UNC field: \\server\share. Interestingly, when they map the drive with the FQDN, or even just enter \\server.domain.dom\share into the UNC field, it works just fine, no Domain controller error or prompts for domain credentials.

It seems to me like NetBIOS lookups are causing it, but I’m not sure why or how to resolve that. Will continue to look into it,

Thanks everyone for your support so far.

10

I’ve recently moved over from helpdesk and we had taken many of these steps when we initially encountered the issue. We cleared the DNS cache of the user’s pc with ipconfig /flushdns as part of our troubleshooting.

11

It’s interesting you mention Cisco Anyconnect. We have two VPNs. We set up a Windows-based VPN using an NPS server and RAS, and that runs our AOVPN connection, and then we have Cisco Secure Client (anyconnect) as our backup VPN. Everything seems to work fine over the Cisco VPN.

12

So, I’ve used certutil to check the CRL for our Subordinate CA, and it’s able to download the CRL from the subordinate CA for my VPN Client certificate. Even though the errors involve PKI, I don’t think PKI itself is the cause.

13

No, from what I can tell we don’t have any asymmetrical routing that could be causing this issue.

14

Yes other sites are in ADSS, and they have a site to site connection with our main office.