No access over firewall to shared folder on clustered fileserver, but access to shares on a single member server works

short description of the problem:

I can access a file share on a single Windows server through a firewall, using the notation \IPaddress\sharename and using credentials from the domain of the sharing server (no domain trust).

I cannot access another file share that resides on a clustered file server in the same network. This clustered share is a copy of the first, which includes identical permissions.

Both shares (clustered and single) can be accessed from within their own network as well as via VPN (so we know they work and permissions are OK).

Other services on the same cluster are available through the firewall just fine, a ping to the IP address of the cluster resource name of the clustered file server works, and I even switched IP-addresses of the clustered file server and the single server, in order to have the cluster be available at the same address as the single server was before. So I'm pretty sure that the firewall configuration is not a direct issue here.

So why is the clustered file share not available through the firewall? What's different in the process, when I try to access a clustered file share instead of one on a single host?

I suspect maybe something with authentication? But i have no idea. Any one of you have a hint where to look?

Thanks for your time,
Karsten

--- many more details, if required:

We have a company net with the '.companydomain.com' with IP addresses 10.x.x.x.

Apart from that, a separate domain exists '.separatedomain.private' with IP addresses 192.168.0.x., which hosts some servers.

Clients from .companydomain.com currently access services on those servers in .separatedomain.private. Relevant services are shared folders, MS-SQL databases and some applications hosted on IIS.

There is a firewall between the subnets that maps three pairs of IP-addresses by port-forwarding. 10.0.0.101 is mapped to 192.168.0.101, same with .102 and .103. So the clients can access for instance IIS on the server with the 192.168.0.101 by connecting to 10.0.0.101:80.

There is no trust between the domains. Authentication is done via SQL DB internal users (for the database connections) or by user accounts from .separatedomain.private (for the shares).

.separatedomain.private. has its own domain controllers, dc01 and dc02 (Windows 2016), which are new and recently replaced old ones (olddc1 and olddc2, Windows 2008R2).

For the scope of this question, please accept that this setup cannot be changed due to company policy, and the firewall has to be treated as a black box. - So far everything works.

After renewing the domain controllers we now want to switch the SQL-Server, the IIS and the Fileshares in .separatedomain.private from two old mirrored machines (oldDB1 and oldDB2, Windows 2008R2) to new ones in a Windows failover cluster (db01, 192.168.0.201 and db02, 192.168.0.202, Windows 2016). The cluster is already set up and features an MS-SQL-DB Failover Cluster Instance, IIS in a failover configuration, and a clustered file server. Each has its own cluster ressource set up in the domain (named SQLFCI, CLIIS and CLFS). All three services run and failover nicely and are properly accessible by their IP addresses as well as cluster ressource names from clients in .separatedomain.private.

All fileshares have permissions set for user accounts in .separatedomain.private. For testing, we use the same user fsuser@separatedomain.private, which is granted proper permissions on all file shares and all servers.

In order to have the new clustered services go productive, we need to switch the cluster ressources to the IP addresses mapped through the firewall. And here I run into a problem with the fileshares.

Currently, fileshares reside on oldDB1 (192.168.0.101 mapped to 10.0.0.101). A client from .companydomain.com, authenticating with fsuser@separatedomain.private, can properly access those fileshares (as \10.0.0.101\sharename).

As a test, we copied some fileshares to dc01 and switched dc01 to 192.168.0.101, just to do a test with shares on a server that runs Windows 2016. Again, the client from .companydomain.com, authenticating with fsuser@separatedomain.private, can properly access those fileshares (as \10.0.0.101\sharename).

Then we copied the fileshares to the clustered file server and switched the IP address for the clustered file server ressource (CLFS.separatedomain.private) to 192.68.0.101 (moving dc01 away from 101 with all the care necessary when altering the IP address of a DC). - A client from .separatedomain.private still can access the file shares on the cluster by using IP address (\192.168.0.101\sharename) as well as by cluster resource name name (\CLFS\sharename), but now the clients from .companydomain.com no longer have access to \10.0.0.101\sharename. (They can only go via IP address, as names in separatedomain.private cannot be resolved in companydomain.com): After the dialog to enter user and password, 'Windows security - connect to 10.0.0.101' appears and stays for a while, then we get network error with the code 0x80070035 'The network path was not found'.

10.0.0.101 pings fine and the clustered IIS and the clustered databases CAN be reached through the firewall, despite the respective IP addresses .102 and .103 also only being assigned to their clustered resources. So routing seems to be fine. My guess is that it has something to do with the user authentication process (as DB uses SQL server internal accounts and the IIS hosts a public site without authentication, they don't follow the same process). But why does it work with non clustered shares?

At the moment, I don't even have any idea where to start looking for a specific cause. I will still restart analysing from scratch, of course, and also go over the setup again to check for any admin too dumb error, but any hint speeding this up would be greatly appreciated.