Accessing a Windows 10 share via Ubuntu/CIFS over OpenVPN

Question

Goal: To access Windows 10 file shares, from Linux, over a VPN.

In this context: "server" is a simple Windows 10 machine, and "client" is Ubuntu 18.

I have an OpenVPN tunnel setup, connection seems good, can connect, ping the server, portscan provides correct results, and I can manually establish a telnet connection to port 135.

I am trying to mount a folder on linux, to the windows share, using CIFS, something I have done many times before - but not to this particular windows machine admittedly.

I am effectively using: mount -t cifs //server/share /mnt/share but the result is always:

mount: /mnt/share: mount(2) system call failed: Connection refused.

dmesg/syslog show:

CIFS VFS: Error connecting to socket. Aborting operation.
CIFS VFS: cifs_mount failed w/return code = -111

I have tried nearly all the CIFS flags I can think of, including all security options. The actual current command I am using is:
sudo mount -v -t cifs -o vers=3.1.1,username=myuser,pass=mypass,servern=WINDESKTOP,sec=ntlmssp //10.8.0.1/share /mnt/share

Windows firewall is turned off, the the share, and folder, have full permissions for the user account I am trying to use, as well as guest, anonymous login.

I installed an FTP server on the server just to triple check connectivity, works find.

Why isn't CIFS connecting? Is there any way on the windows server to see exactly what it is doing to the connection? And/or is there anyway to get greater debugging output from CIFS on Ubuntu?

Edit:
A nmap -Pn <host> portscan shows the following open ports:

PORT STATE SERVICE
135/tcp open msrpc
554/tcp open rtsp
2869/tcp open icslap
10243/tcp open unknown

Update/Solution:

The problem and a workaround were found. The answer below from @grawity alerts to the fact that server is not listening on port 445. The problem has nothing to do with OpenVPN or linux/CIFS

1. Noted that the smb server service is not listening on port 445, this means ms_server component is not operational.
2. ms_server is the SMB server service, this is enabled/disabled by toggling the following checkbox in a device's network settings: File and Printer Sharing for Microsoft Networks.
3. In this case the check box was already checked. Unchecking it and checking it again, fixes the issue, server listens on port 445, and file sharing works. But only temporarily, until the next reboot.
4. This whole issue appears to be a known problem with Windows 10, caused by a reasonably recent Windows Update
5. I was unable to find a clean solution, or real patch to the actual issue.
6. One short-term workaround is to create a small script that effectively "unchecks and checks the box", and run when a user logs in.

The powershell commands to workaround this issue are:
Disable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server
Enable-NetAdapterBinding -Name "MyVPN" -ComponentID ms_server

Solution

I can manually establish a telnet connection to port 135.

That's not the correct port (that's the RPC-EPMAP port). SMB runs on TCP port 445.

(You might also see port 139 for compatibility with old pre-Win2000 clients, which only supported SMB-over-NetBIOS. Those clients would also need NetBIOS datagram services on UDP 137–138.)

mount: /mnt/share: mount(2) system call failed: Connection refused
CIFS VFS: Error connecting to socket. Aborting operation.
CIFS VFS: cifs_mount failed w/return code = -111

"Connection refused" implies that the client received a TCP RST in response to its handshake attempt, which generally means either that the server isn't listening on that TCP port or that there's a firewall spoofing a RST in order to block the connection.

That's usually not a matter of protocol versions or security options, which are only negotiated after the TCP connection has been established.

Windows firewall is turned off

Why?

The Windows firewall is configurable: if you want to allow a protocol through it, you can create a rule to allow that protocol. (Or indeed just enable a predefined rule when it comes to allowing SMB or ICMP.)

Is there any way on the windows server to see exactly what it is doing to the connection? And/or is there anyway to get greater debugging output from CIFS on Ubuntu?

Install a packet capture tool such as Wireshark; start a capture on tun0 or the OpenVPN TAP adapter; look at what happens immediately before the TCP RST is generated.

Pay attention to whether both sides see the same packets, e.g. if the client actually receives a TCP RST, does the server show that it has sent one?

Comments

[Mtl Dev]

1) Ah!I understand SMBv1 runs on ports 135..139, know I know SMBv2+ run on port 445....a port scan (see "Edit" in question shows the server is not listening on port 445...at least not on the VPN IP..I guess this is an issue to investigate...)

[Mtl Dev]

2) Windows Firewall just turned of temporarily during testing, to eliminate it as a possible cause.

[user1686]

Both SMBv1 (aka CIFS) and SMBv2+ use the same transport: TCP/445 for modern systems or TCP/139 for old NetBIOS-using systems. The other ports aren't actually SMB: TCP/135 is MS-RPC, and UDP/137-138 are miscellaneous NetBIOS services.

[user1686]

What nmap shows is exactly the same as what the cifs module is telling you. It cannot remotely obtain any extra information, and it doesn't know whether a port is "listening" – all it sees is whether the port has accepted the connection attempt. So you really have to check on the server itself, and/or on router firewalls along the way.

[Mtl Dev]

Ok, thanks! The server is listening (netstat -an) on 445 on it's regular IP, but 445 is not open on it's VPN IP. Manifestation of this: if I enter, on windows server, \\serverIP or \\127.0.0.1 I can see the shares just fine, but if I enter `\\serverVPNip` I can not see the shares, times out

[user1686]

Actually, as far as your system goes, you are correct: SMBv2+ does not use any NetBIOS services and therefore only needs TCP/445. (SMBv1 can use either TCP/445 or TCP/139 depending on system.)

[Mtl Dev]

So, based on nmap results, we can say 100% that port 445 is not listening on the server? As there are no firewalls in the path, thus the problem must be: Windows File Sharing is somehow disabled for the TAP network device? Does that sound a reasonable conclusion?

[user1686]

No, but based on your netstat -an results on the server itself, you can say that it's not listening on that port (at least not on the right address). The protocol is probably disabled in the network adapter's "Properties" window.

[Mtl Dev]

Aye good suggestion, that was one of the first things I checked. I did find the following article Which the solution is basically "uncheck file sharing", close, and the recheck it.

[Mtl Dev]

So it now works, is listening on 445. Solution: as per the microsoft help: uncheck and recheck file sharing (!). This fix does not surive a reboot, I'll work on that, as post back. Your answer was helpful in pointing me towards port 445 not being open, when I get back with the reboot-survival-fix, please feel free to consolidate into one answer, so I can accept.

[Mtl Dev]

Appreciate if you can please review solution included in question. Perhaps, for next user, you would wish to extend answer with ""server not listening on port 445..ensure "File and Printer Sharing.." is checked. If already checked, then uncheck and recheck it"". Also, as per your experience, level, do you think I should remove all references to openvpn/linux from the question, as to avoid red herrings?