Client connects but unable to connect to all servers

SOLVED
TRooper_X
Conversationalist

Client connects but unable to connect to all servers

Windows 10 client. She has been able to connect and be fully operational before.

Now she can connect and is able to access file shares on Server1. Server2, however cannot be connected to using windows UNC or mapped network drives. The system responds with "error reconnecting network drive" when she goes to a persistent network drive. The laptop is able to resolve and ping the TCPv4 ip address of both servers.

 

We've removed the VPN configuration and recreated the connection.

 

Any thoughts? 

1 ACCEPTED SOLUTION

Whelp, we figured it out.

 

It was a simple IP address conflict. The user's home network and the corporate network have the same subnet. A device on the home network was assigned an address that conflicted with Server2.

Lesson learned on selecting corporate subnets. But that was 20+ years ago when this office was setup.

We are going to either move the DHCP scope range or setup a reservation on the home DHCP to avoid these conflicts.

 

Thank you Nash for your reply.

 

Tim

View solution in original post

4 REPLIES 4
Nash
Kind of a big deal

How are you trying to access the drive? By fully qualified domain name, WINS (please no), IP address?

 

What kind of VPN credential are you using? If Meraki cloud credential, then Windows automatically tries to use that credential to authenticate to the remote server.

 

Assuming you created this as a single user connection, instead of in the Public phonebook, there's a simple fix.

 

Use PowerShell on the user's computer while logged in as her:

# Set RASPhone.pbk so that the Windows credential is used to authenticate to servers.
# Important when you use Meraki cloud credentials.

$PbkPath = Join-Path $env:APPDATA 'Microsoft\Network\Connections\Pbk\rasphone.Pbk'
(Get-Content -path $PbkPath -Raw) -Replace 'UseRasCredentials=1','UseRasCredentials=0' | Set-Content -pat $PbkPath

 

Otherwise change $PbkPath to the exact file path for her appdata, instead of using 'Join-Path $env:APPDATA' to append the environmental variable.

 

If it is Public, change it to $env:PROGRAMDATA. 🙂 

TRooper_X
Conversationalist

Thank you for the info Nash.

 

To further clarify we are using AD authentication on the VPN so all authentication is passed through to the AD accounts. The servers are generally accessed by mapped drives pushed out by domain group policy. I'm not sure authentication is the issue here.

 

In this case the user can access the drives mapped to Server1 without any problems. She used to be able to connect to Server2 as well. At some point in the last two weeks the connection to Server2 was somehow broken. 

 

She can ping both server2 and server2.domain.com. Ping resolves the proper name server2.domain.com from its IP address. So it does not look like DNS is the problem either.

 

Whelp, we figured it out.

 

It was a simple IP address conflict. The user's home network and the corporate network have the same subnet. A device on the home network was assigned an address that conflicted with Server2.

Lesson learned on selecting corporate subnets. But that was 20+ years ago when this office was setup.

We are going to either move the DHCP scope range or setup a reservation on the home DHCP to avoid these conflicts.

 

Thank you Nash for your reply.

 

Tim

Nash
Kind of a big deal

Oh, solidarity. I have several clients with, you know, hundreds of machines on 192.168.1.x or 192.168.0.x and they don't see why that ever needs to change. 

 

Glad you're using AD creds on the VPN though. That makes life a lot easier, right?

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels