Access to SMB share over split-tunnel VPN only works if full VPN tunnel first established

[Cleartech]

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

[alemabrahao]

Have you tried to access via IP? It looks like a DNS issue.

[Cleartech]

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.

[alemabrahao]

Well, in this case, it looks like a server issue, does this server have any policy or internal firewall that can block the connection?

[Cleartech]

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.

[alemabrahao]

https://documentation.meraki.com/MX/Client_VPN/Configuring_Split_Tunnel_Client_VPN

[Cleartech]

will try that out thanks!

[Cleartech]

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 😞

[Cleartech]

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.

[rhbirkelund]

Do you have the SMB server subnet in your route-table? And also the return route?

[Cleartech]

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.

[Cleartech]

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.