- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Access to SMB share over split-tunnel VPN only works if full VPN tunnel first established
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
- Labels:
-
Client VPN
-
Other
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have you tried to access via IP? It looks like a DNS issue.
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Well, in this case, it looks like a server issue, does this server have any policy or internal firewall that can block the connection?
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
https://documentation.meraki.com/MX/Client_VPN/Configuring_Split_Tunnel_Client_VPN
Please, if this post was useful, leave your kudos and mark it as solved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
will try that out thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 😞
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have the SMB server subnet in your route-table? And also the return route?
Like what you see? - Give a Kudo ## Did it answer your question? - Mark it as a Solution 🙂
All code examples are provided as is. Responsibility for Code execution lies solely your own.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.