Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About Cleartech
Cleartech
Here to help
Member since May 21, 2019
Apr 3 2023
Community Record
8
Posts
0
Kudos
0
Solutions
Badges
Apr 3 2023
1:34 PM
fwiw, the only correlation we’ve found to date is that the same Dell Precision 5570 endpoints are the only ones affected; firmware and driver updates already done on same.
... View more
Apr 3 2023
1:30 PM
Bumping this thread to see if there's any other ideas on this extremely perplexing matter: Most recently, the one symptom change is the following (when connected via split-tunnel VPN) - access to \\10.10.10.xx confirmed SUCCESSFUL - access to \\<name> resulted, one time, in "enter network credentials" prompt with default username=office\<username> - removed cached credentials in Windows for the server <name> in question - the next access attempt to either \\<name> or \\<namewithFQDN> resulted in typical timeout and error as normal - verified DNS results via nslookup (DNS server accurate, and <name> returns accurate IP address) SMB over split-tunnel VPN with "name" continues to fail, while access to SMB over VPN via “full tunnel” VPN succeeds without issue.
... View more
Feb 9 2023
1:34 PM
fwiw, here's a screenshot of the IPv4 route table of the problem system. endpoint IPv4 address over VPN adapter: 172.10.10.9 remote LAN network IP: 10.10.10.0/24 Further, we compared the route of problem system with a known good working system - route table of the 10.10.10.0/24 entries were identical.
... View more
Feb 9 2023
1:32 PM
Update - we checked the routing table (via "route print") and compared it to a known good system; the route to the LAN address of the SMB resources was present on the problem system and looked correct. Still, proceeded to try to re-add the route as: netsh interface ipv4 add route 10.10.10.0/24 "client VPN" with this result: “The object already exists” We also tried a different user profile on the Windows endpoint in question to rule out any profile issues - same result 😞
... View more
Feb 7 2023
3:00 PM
will try that out thanks!
... View more
Feb 7 2023
2:53 PM
TBH, seems doubtful that it's a server issue if a) only handful of endpoints affected (majority of remote endpoints do not experiencing this issue, all are Win10 and b) toggling full vpn connection, then reconneting with split tunnel suddenly allows SMB connections/mapped drives to work.
... View more
Feb 7 2023
2:42 PM
yep, tried accessing via \\<ipaddress> .... same issue. Worth noting that looking up the <SERVER> via nslookup and ping <server> work - latter we receiving ping responses, in former the correct IP address of the "server" is returned.
... View more
Feb 7 2023
2:29 PM
On each affected endpoint, two VPN connections exist 1. Standard VPN (split tunnel) 2. Full Tunnel VPN Symptom: when connected to standard VPN (split tunnel), access to mapped network drives (e.g., S: drive to \\server\share) fails with following error: An error occurred while reconnecting S: to \\server\share ... The network path was not found Connecting to "full tunnel" VPN does not result in this same error When this error is observed during a split-tunnel VPN connected session, we have verified the following: - DNS server = 10.10.10.xx (correct) - Ping tests to the server in question are successful (both to SMB name and the FQDN of server) - Credential manager on endpoints checked, and no domain-related entries found - Access mapped drive S: drive fails, as do SMB connection attempt to \\server and \\server.office.<company>.com The following WORKAROUND seems to reliably allow SMB/mapped drives to be accessible however: 1. Connect to FULL TUNNEL vpn and then access S: drive while connected (this step is required, as not accessing S: drive doesn’t allow the subsequent standard VPN connection to access S: drive) 2. Disconnect from full tunnel VPN 3. Then connect to standard VPN (split tunnel) ...at this point, S: and all other mapped drives on <SERVER> are confirmed to become available at the endpoint It's worth noting that only a handful of endpoints are afflicted with this issue; other endpoints using the identical split-tunnel VPN connection (created via PS script, so we can confirm the VPN config is identical) have no issues in accessing SMB resources over VPN, whether split-tunnel or otherwise The interface metric (for the IPv4 layer of standard VPN) on each affected endpoint has been confirmed to be higher precedence (lower value) and we have further verified the active DNS at endpoint during VPN-connected sessions is the office-based DNS server
... View more
Labels:
- Labels:
-
Client VPN
-
Other
© 2024 Cisco Systems, Inc.
