# [Solved] Connect to Samba takes aprox 2 minutes w/iptables

## ziggysquatch

I have a problem with Samba.  When you try to connect to the Samba share with windows XP, it takes about 2 minutes (last timed one was 1 minute 37 seconds) to connect.  This only happens when you have iptables running on the server.  If you shut off iptables the connection takes like 2 seconds.  Also browsing the share after connecting takes no time at all, it's nice and fast after the initial connection.

The client machine has Netware on it.  

We have tried opening port 135 - 139 and also port 445 in iptables without success.

I have suggested setting a reject rule for port 445 to keep windows xp from trying that before 139 but I would think that with port 445 open samba should deal with either accepting or rejecting the connection the same as having the firewall off.

Does anyone know if there is some other thing in iptables that needs to be set up for this to work?  I have looked on the samba website and the usual googling and having the normal samba ports open should be fine.

some expired web site I found in google's cache:

 *Quote:*   

> Samba does have the ability to accept connections on port 445, but it does not listen on this port when started with the -D option. Instead, it must be started from inetd (without the -D flag) and inetd must be configured to accept smb connections on port 445.

 

smbd man page:

 *Quote:*   

> -p <port number(s)>
> 
>               port number(s) is a space or comma-separated list of  TCP  ports
> 
>               smbd should listen on. The default value is taken from the ports
> ...

 Last edited by ziggysquatch on Fri Oct 02, 2009 1:54 pm; edited 1 time in total

----------

## ziggysquatch

Using a reject rule for port 445 didn't work either.

----------

## plut0

It would help if you posted your iptables rules.  However, ports 139 and 445 should be TCP while ports 137 and 138 should be UDP.

----------

## ziggysquatch

My bad, see below...

```

*filter

:INPUT ACCEPT [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT ACCEPT [0:0]

:RH-Firewall-1-INPUT - [0:0]

-A INPUT -j RH-Firewall-1-INPUT

-A FORWARD -j RH-Firewall-1-INPUT

-A RH-Firewall-1-INPUT -i lo -j ACCEPT

-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

...

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 137 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 138 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 139 -j ACCEPT

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT

...

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT

...

-A RH-Firewall-1-INPUT -p tcp -j LOG --log-tcp-options --log-ip-options --log-level warning

-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

COMMIT

```

The ... parts are where we have other non-related ports listed.  Any ideas?

----------

## plut0

Not sure how well the stateful 'new' connections work with UDP, some packets could be related.  So try taking out the stateful options for the UDP ports.

----------

## ziggysquatch

Taking out the new stuff had no effect.

We posted on the Novell forums because the issue also only happened with XP clients with Netware installed.  It turns out that Netware tries port 524 first then after timing out it tries to connect with the normal samba ports.

We added a rule to allow 524 and that fixed the issue.  I think it would be better to add a rule to reject 524 as we don't have any netware stuff on the server itself.  Either way, mystery solved!

Thanks for your suggestions plut0.

----------

