Score:0

Windows Server 2019 accessing shares over VPN for some users

nl flag

I'm using Windows Server 2019 and have setup a OpenVPN 2.5.4 Client as a service to start a VPN link back to my pfSense box at another location. The problem is only some Windows Server users can access the Samba shares on a Debian machine on the other side of the VPN.

If I login as user A, they can see the mapped drives at \192.168.0.4 but user B cannot. User B can however ping the 192.168.0.4 machine.

For both tests I connected via the VPN using the same credentials.

The VPN is starting up on boot of the Windows Server and connecting.

It works for user A and the Administrator. The error message I get for user B when trying to access \192.168.0.4 in the explorer is;

  Windows cannot access \\192.168.0.4\data
  Check the spelling of the name. Otherwise, there might be a problem with your network. To
  try to identify and resolve network problems, click Diagnose.

I've tried setting user B as an Administrator, rebooting and logging in again but that didn't work. It feels like a permissions problem. The first time I tried accessing a Samba share as User A it prompted me for credentials, but it doesn't do this for User B.

Update: More detail

My share is on my Debian 10 box using Samba 4.9.5, I've defined the 'data' share in my smb.conf like so;

[data]
    path = /media/data
    read only = No
    guest ok = Yes

I connect from my Windows Server 2019 VM over an OpenVPN client installed on Windows Server (the OpenVPN server is running on a pfSense machine) so that I can connect to my Debian machine. The Debian machine and pfSense firewall are at the office and the Windows Server is a VM at a VPS provider at a different location.

On the Windows Server I can login as 'User A' and connect to the Debian box through the windows file manager and I can connect to the 'data' share. If I login as User B though I get the error.

My office lan is on 192.168.0.x (which includes the pfSense and Debian box), there are some legacy systems onsite which are hard to change their static addresses. The Window Server 2019 VM is running on 10.0.192.x and the VPN(client) is setup on 10.0.8.x and the VPN(server) is on the 192.168.0.x network.

User A & B are both on the Windows Server.

User A can see mount points on 192.168.0.4 and HTTP access. User B cannot see mount points but can go to http://192.168.0.4.

Update: User B starts VPN

When I stop the OpenVPN Client service on the Windows Server and I manually start the VPN link with User B, it connects to the VPN but still gets an error when looking at the shares through Windows Explorer //192.168.0.4/data.

However, starting the VPN manually with User A and then connecting through Windows Explorer to //192.168.0.4/data works for this user.

To me it still looks like User B has a permissions problem accessing remote shares over a VPN or something.

Jacob Evans avatar
br flag
can you add more details around sources and destinations and what works and what doesn't work, for example your SHARE is on Server 2019? and your users vpn into the pfsense? and then access the server 2019 smb share from debian clients? and the debian clients are running openvpn client to connect? are those clients in the same location as each other? Subnet Conflicts? why the heck you used 192.168.0.0 for your office network is beyond me, grab a random 10/8 network like 10.13.57.0/24 instead? what network is the vpn? client lan? server lan? are user A and user B using same exact desktop
Score:1
nl flag

Found the issue. The username on the Windows Server was different to the allowed users on the Samba box.

User A was the same on both Windows Server and Debian and it was setup using smbpasswd on the debian server, that's why it worked. But User B was only on Windows Server. Once I found this I mapped the drive and entered in a valid samba user to map the drive.

Auditor avatar
mm flag
Good to see people coming back to their own questions with a solution. Thanks
Paul avatar
cn flag
Please consider selecting your answer as the answer.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.