Windows ports file sharing.

[cibonato]

Ladies and genttlemen, I'm trying to configure IPTABLES to open just the necessary ports on a Samba server to Windows file sharing, but I'm in trouble.

The server has 137/UDP, 138/UDP, 139/TCP and 445/TCP ports open but if I try to "Run" \\<computer> (on a Windows machine) I get an error message.

Many web pages say that's exactly the ports/protocols needed to this, but it's not working.

Using smbclient I can mount the SMB share from Linux machines.

Any clue?

[htranou]

Can you with the ip address instead?

Windows also has a limitation on the use of credentials for smb, like it can only use 1 login/password at the same time, so give a try with a public share first.

[jmbsvicetto]

Hi.

Are you sure that you don't have a name resolution problem?
Can you ping from windows to your samba host? Does it work using the name and not the IP?

[cibonato]

htranou: Using the IP address returns the same error.

jmbsvicetto: I don't think it is name resolution problem because if I try to ping the server (from any client) by its name everything seems go fine. I can't ping indeed because ping is disabled, but one can note that it would goes fine without IPTABLES.

I found a kind of solution... there's a file called lmhosts that works very similar to the /etc/hosts file in Linux. This file has just the line "a.b.c.d server_name", where a.b.c.d is the server's IP and server_name is its NetBIOS name. The server is Linux and the clients is Windows, so the lmhosts is a Windows file.

Another fact that enforce my theory is the possibility of resolve the problem telling to the client what is the NetBIOS name of the server.

I've used snort to grab the traffic between the server and the client and I saw indeed packets going to the server's 137/UDP and 138/UDP ports.

The weirdest thing is: opening 135/TCP, 137/UDP, 138/UDP and 139/UDP ports is not enough to enable normal NetBIOS sessions.

Let's keep trying...

[GetCool]

You could try forgetting about NetBIOS completely, and using plain TCP/IP name resolution. Modify the hosts file in Windows:

Code: Select all

%Systemroot%\System32\Drivers\Etc\hosts

...and fill in the IP and name.

You have all the right ports open. In fact, I've gotten Windows 2000/XP clients to access a share with only TCP port 445 open. It's been a while, though...

[cibonato]

GetCool, it was the solution I found and indeed the solution I've implemented, but...

Maybe could do exist some secret port to open...

It was not a problem itself.

Ok, thank you all.

[jmbsvicetto]

jmbsvicetto: I don't think it is name resolution problem because if I try to ping the server (from any client) by its name everything seems go fine. I can't ping indeed because ping is disabled, but one can note that it would goes fine without IPTABLES.
I found a kind of solution... there's a file called lmhosts that works very similar to the /etc/hosts file in Linux.

Actually lmhosts is used for netbios resolution. If things work when you use it, then it surely must be a name resolution problem. Are you using DNS or WINS? Are you sure that your Samba host is registered on the server the windows clients use?
Since you can't test with ping, try doing a telnet from your windows clients to port 139 of the Samba host. Try using the server name and the server ip.

[GetCool]

Maybe could do exist some secret port to open...

There is no secret port.

If you're using Windows 2000 or later, then you have two options for the SMB protocol. One is to run it over NetBIOS over TCP/IP, which utilizes ports 137 (UDP), 138 (UDP) and 139 (TCP), and the other is to run SMB directly over TCP/IP, which utilizes only port 445 (TCP).

If I remember correctly, you can disable NetBIOS over TCP/IP on your Windows client via the Properties window of the TCP/IP protocol for your network adapter. I don't have a Windows machine in front of me, so I can't verify exactly where it is. If you disable this, your Windows client will forget about NetBIOS and only use port 445 (TCP).

Of course, you need either a DNS server to resolve the hostname of your Samba server, or an entry in your hosts file (not your lmhosts file).

[cibonato]

jmbsvicetto: I think I misunderstood something, when I read about name resolution problem I was thinking about DNS and not about the NetBIOS name. I don't use WINS, just DNS. The Samba server is registered in the DNS, in fact, its NetBIOS name, hostname and "DNS name" is the same.

GetCool: I read about the possibility of using SMB over TCP/IP, it could be a solution since the Samba server possess the 445/TCP port open. But, and here is where things get weird, there's also Windows 9x clientes, so I opened these 3 ports (137/UDP, 138/UDP and 139/TCP) on the server and it was not enough because I still get the same error. There's also another port open, 135/UDP. All the ports, but these 4 and 22/TCP, are closed.

DNS is running and it is resolving the Samba server's name very well (from Linux I run ssh server_name and connect to the machine with no problem).

And now another curious fact: the only file I touched on the Windows clients (no matters which one) was lmhosts, just it. hosts file is there, but empty.

[GetCool]

And now another curious fact: the only file I touched on the Windows clients (no matters which one) was lmhosts, just it. hosts file is there, but empty.

Try using the hosts file. I've found that sometimes SMB chokes completely under Windows if there is no entry in the hosts file for the server you wish to communicate with.

I was a Windows network admin for five years and I found many things that Windows does which I can't logically explain.

[jmbsvicetto]

jmbsvicetto: I think I misunderstood something, when I read about name resolution problem I was thinking about DNS and not about the NetBIOS name. I don't use WINS, just DNS. The Samba server is registered in the DNS, in fact, its NetBIOS name, hostname and "DNS name" is the same.
DNS is running and it is resolving the Samba server's name very well (from Linux I run ssh server_name and connect to the machine with no problem).

Actually, I think it's a name resolution problem at the clients. Can you ping your Samba server from windows using its name? Try using both the fqdn name and the hostname. Windows hosts use different methods to resolve names if you use the fqdn or just the hostname. By the way, no matter what MS says, you should still use WINS with win2k. As far as I know, you have to use WINS for Win9X. You can have your Samba server acting as a WINS server.

[GetCool]

By the way, no matter what MS says, you should still use WINS with win2k.

But this isn't really necessary, and WINS is archaic. A Windows 2k or XP client can happily resolve a name without WINS, and use SMB directly over TCP/IP. I've done this.

[jmbsvicetto]

By the way, no matter what MS says, you should still use WINS with win2k.

But this isn't really necessary, and WINS is archaic. A Windows 2k or XP client can happily resolve a name without WINS, and use SMB directly over TCP/IP. I've done this.

I didn't say that you shouldn't use SMB over TCP/IP. I just said, that even though you do that and use DNS, you will probably have a better experience also running WINS. By the way, Win2K03 WINS implementation "finally works" ! I think it was Mark Minasi who said that it took Microsoft so long for implementing WINS properly and when they finally did it, they also made it irrelevant.

[cibonato]

First of all... What the h*** is WINS? Will it really help me? What does it do?

¿Why many questions?

I've been enabling WINS support on Windows clients and making some Samba server also a WINS server since a long time and my conclusion is... it did not help for anything!

Simple like that!

[GetCool]

First of all... What the h*** is WINS? Will it really help me? What does it do?

WINS stands for Windows Internet Naming Service. It is basically a name resolution service, like DNS, but designed obviously for networks composed of Windows machines. It doesn't handle domain name resolution (this is the job of DNS), which is why it is really only necessary for networks that have older Windows clients.

Today, WINS is obsolete, and even Microsoft is making it obsolete with their switch to DNS with Windows 2000/2003. Prior to Windows 2000, the Windows platform didn't really support FQDNs; machines had an arbitrary hostname (i.e. "win98box"), which was the name stored in the WINS database and associated with an IP. Clients were given the address of the WINS server (via DHCP), and contacted the WINS server to resolve these hostnames.

With the implementation of a domain name on your Windows 2000/2003 network, WINS isn't necessary (although it can still be used), as DNS takes care of name resolution. Plus, it can obviously support FQDNs. Now, instead of "win98box", you have "winxpbox.network.com", and clients can exclusively ask a DNS server to resolve this name instead of a WINS server.

There are a couple of things to note. If you have any Windows 9x machines at all, you will need WINS. You will also need WINS if you don't want to use an actual domain name (which isn't required). And WINS, as jmbsvicetto mentioned, was never all too reliable (remarkably, Linux can make a better WINS server than Windows).

Furthermore, even if you are using a pure Windows 2000/XP network with Windows 2003 servers, relying on straight DNS for internal name resolution may not always be reliable either. WINS actually does handle Windows clients with dynamic IPs a little better, but this is probably an issue with Microsoft's implementation of DNS more than anything else (specifically, as Windows clients are given new IPs via DHCP, the DNS host records may not always be updated properly). This is what jmbsvicetto means by "you will probably have a better experience also running WINS".

So, in short, name resolution in Windows is still a bit screwy, but this is probably due to maintaining backwards compatibility with legacy systems. Solution? Stop using Windows! (but that's too easy...)

[cibonato]

Solution? Stop using Windows! (but that's too easy...)

It's always the solution.

Good explanation, thank you.