MAC OS SMB://IPaddress

[DHAnderson]

I have a client who have Mac Os devices who access Windows file shares while at work.  They use SMB://ipaddress to access the shares.

There are two servers which have the shares.  One is an old Server 2003 (not domain managed) using SMB1.0 (I know the security risk!), and the other is a Server 2016 Domain Controller using the newer file sharing protocol.   Mac and PCs in the offices can get at shared folders on both servers.

When the clients took their laptops home and connect to the VPN, Mac OS users cannot get to the file shares.  Windows users can get to them.

In the Client VPN settings I have the DNS set to the IP of the domain controller, and WINS set for both the domain controller and the Server 2003.

I have done a packet capture when a Mac was trying to access share and I could see the SMB request and responses going back and forth.  I did not understand the packet data though.

I do not know what could be causing the Macs to fail while accessing those shares over VPN.

Any insight would be appreciated.

[PhilipDAth]

Can the Macs ping the two file servers?

[DHAnderson]

Philip,

Yes, the Macs can successfully ping both servers. In the packet capture I can see traffic over Ports 445 and 137 when a Mac is trying smb, but Macs fail to connect.

[PhilipDAth]

>Yes, the Macs can successfully ping both servers. In the packet capture I can see traffic over Ports 445 and 137 when a Mac is trying smb, but Macs fail to connect.

It's not something dumb like the MAC is trying to authenticate with the VPN credentials rather than the share credentials?

[Uberseehandel]

Move the files up to OneDrive in the Cloud - problem goes away - they are encrypted at rest and in transit

Apparently, MS has noticed “a 775 percent increase of our cloud services in regions that have enforced social distancing or shelter in place orders”.

https://azure.microsoft.com/en-us/blog/update-2-on-microsoft-cloud-services-continuity/ 

[DHAnderson]

Moving the files up to G Suite or One Drive is not an short term option, and the files are part of a production process.

[cmr]

If you look on the client Mac when connected over the VPN, have the DNS and WINS settings actually taken?  We found that Macs are particularly bad about getting DNS servers etc. from a VPN conection.

[PhilipDAth]

>If you look on the client Mac when connected over the VPN, have the DNS and WINS settings actually taken? 

He's connecting via IP address, so it can't be an issue with name resolution.

[DHAnderson]

The client sent me this picture.  It looks like the server cannot be found, but it can be successfully pinged.  Another interesting item is that PCs have not problem accessing the file shares on that server, so it shouldn't be that SMB is not being routed properly through the VPN subnet to the server subnet.

In the MX event log, I can see the client VPN Connect event, but there are no other events until the client VPN Disconnect event.

Does anyone have a similar issues with Mac computers accessing a Windows file server over the VPN?

[PhilipDAth]

Thinking sideways here - what method does the Mac use to authenticate?  NTLM, Kerberos, or something using certificates?

If certificates, does the server perhaps have a certificate that the mac doesn't trust?

If it is using NTLM - is the version of NTLM that the Mac is trying to use also enabled on the Windows servers?

On the Windows server security event log - do you see the user as having authenticated to the server (you might need to turn on additional audit logging to see the authentication events)?

Server 2003 will be using SMBv1.  Server 2016 will be using SMBv2.  Is the Mac using a version of SMB that is enabled on the Windows servers?

[DHAnderson]

It is using Meraki Cloud Authentication.

So Macs can get the to shares if they are on the local lan or the site to site VPN.

Macs and PC can ping the servers when they are on the client VPN.

PCs can use SMB to get the the servers, but the Mac SMB is failing.

It almost seems like a timing thing, where the routing through the client's home network to the Meraki firewall, through the subnet routing to the machine takes a bit longer than the Mac likes?

[PhilipDAth]

Lets try some experiments.  Are you able to try dropping the MTU on the VPN to something stupid like 1000 bytes.  If that makes no difference change it back.

This will tell us if perhaps their is an MTU squeeze.

Are you able to enable TCP timestamps on the Mac.  Perhaps it is getting affected by asymmetric variations in timing.  f that makes no difference change it back to the default.

Does the Mac platform support select acks?  If so and they are not on by default, perhaps try turning them on.  If it makes no difference turn it back off.

Are you able to get a packet capture (as in Wireshark) of the issue happening?

[DHAnderson]

I just send out a request to that client to schedule more testing time.

Earlier I did a packet capture to a different server, and I could see traffic between the client on the VPN and that server on ports 445 and 139, but the Mac was still giving the same error. I will re-run that test on both servers.

Thanks for the suggestions.

[Reis]

Greetings DHAnderson:

Were you able to resolve this issue? I'm running into a similar problem with some of my Macs. Client VPN connects successfully, then cannot SMB to server IP address. It has happened to users who connect successfully in location A, but travel to location B and the VPN no longer connects. However I have two users that recently connected to VPN successfully, but cannot open shares, or even just connect to the server IP.

Let me know if you found the source of your issue, as it may be useful for mine.

Thank you.

[DHAnderson]

Reis,

Unfortunately, I have not resolved the issue.

My client is working around the problem by connecting to the VPN, then accessing the shares by using remote desktop to their computer on the LAN.

[Reis]

Bummer...I did find this searching around, and I'm looking forward to seeing if it solves the issue:

https://community.meraki.com/t5/forums/replypage/board-id/security/message-id/21878

I will post my findings later today...

Reis