0

Update 2019-11-21:

We have new a Windows Failover Cluster installed and are running a clustered file server on it that hosts file shares.

We need to access these shares through a firewall from another network that has no domain trust established and no DNS resolution into the server network. The shares are accessed by \IP.add.re.ss\sharename instead of by \servername.domain.name\sharename (I don't know whether that's important, I just mention it for completeness), which so far has never been a problem.

So for testing we have a shared folder on an old member server. We have a shared folder directly on one node server of the cluster. We have the administrative share (R$) of the clustered file server volume. And finally we have a shared folder on the cluster file server, which we ultimately want to use.

From inside the server network, even via VPN, I can access all these shares as \IP.add.re.ss\sharename, with IP addresses from that network, and credentials from that domain. To access the shared folder on the clustered file server, I use the IP address of the corresponding cluster resource name as registered in local DNS.

Coming through the firewall (using the same credentials and the mapped IP addresses form the client network), I can access all shares, except the one on the clustered file server.

Other services (IIS, SQL) on the same cluster are available through the firewall just fine and all addresses reply to ping.

So why is the clustered file share not available through the firewall? Why can I access \IP.add.re.ss\R$ but not \IP.add.re.ss\sharename, when this is basically the same?

We did a Wireshark trace and found that the client gets a STATUS_BAD_NETWORK_NAME as Tree Connect Response. But going through the SMB protocol definition I do not see, why this gets triggered.

I noticed that "sharename" does not appear in the share list of the cluster nodes. Should it? Or is it correct that clustered shares only appear under the cluster resource?

Does this ring a bell with any of you? Any hint will be appreciated.

Thanks for your time,
Karsten

Improve this question
4
  • 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). Seems like an easy fix, and certainly less convoluted than this setup. Commented Nov 15, 2019 at 18:00
  • @GregAskew I meant to say that clients from companydomain only have the possibilty to go by IP address, not by servername, for accessing the share. And this works for all single server hosted shares (via \10.0.0.10x\sharename). But if I try to access the clustered file share that way, using the same credentials, it does not work. I cannot connect to it, so it's no fix, it's the problem. Commented Nov 18, 2019 at 15:48
  • Should be able to test with using the name in the hosts file. Commented Nov 19, 2019 at 10:29
  • @GregAskew the local admin at the customer site just told me that access to hosts file is locked by domain policy, and net access is MAC filtered, so i cannot test that. I am curious though why you suggested it. Would using the resource name on the client side not just be locally resolved into an IP address and then be the same from there on? Would that introduce any difference on the other side of the firewall? If I understand the idea behind your suggestion, maybe I can go from there. Commented Nov 21, 2019 at 13:47

0

Reset to default

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.