[CentOS] Samba and iptables - woes

[Rob Townley]

The poster suggesting a lopsided interfaces is correct.  Look at
incoming vs outgoing packets via
ifconfig -a.
  Use /sbin/ip to fix it.  Since the subnet is the same, u need a
/sbin/ip rule.

On 3/31/09, Rob Kampen <rkampen at kampensonline.com> wrote:
>
>
> Craig White wrote:
>> On Tue, 2009-03-31 at 00:19 -0400, Rob Kampen wrote:
>>
>>> Hi folk,
>>> I am trying to get iptables working on a samba server but find it is
>>> blocking something that prevents the windoze clients from being able to
>>> access the share.
>>> here are the bits from iptables:
>>>
>>>> # nmb provided netbios-ns
>>>> -A RH-Firewall-1-INPUT -p udp -m udp -s 192.168.230.100/24 -i eth1
>>>> --dport 137 -j ACCEPT
>>>> # nmb provided netbios-dgm
>>>> -A RH-Firewall-1-INPUT -p udp -m udp -s 192.168.230.100/24 -i eth1
>>>> --dport 138 -j ACCEPT
>>>> # Samba
>>>> -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -s 192.168.230.100/24 -i
>>>> eth1 --dport 135 --state NEW -j ACCEPT
>>>> # smb provided netbios-ssn
>>>> -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -s 192.168.230.100/24 -i
>>>> eth1 --dport 139 --state NEW -j ACCEPT
>>>> # smb provided microsoft-ds
>>>> -A RH-Firewall-1-INPUT -p tcp -m tcp -m state -s 192.168.230.100/24 -i
>>>> eth1 --dport 445 --state NEW -j ACCEPT
>>>>
>>> so as far as I can tell this should provide access to the required
>>> services.
>>> BTW the server has two NICs; 100Mb is eth0 at 192.168.230.230 and
>>> connects to the router with internet/NAT firewall; 1Gb is eth1 at
>>> 192.168.230.232 and this connects to a G ethernet switch that has the
>>> windoze clients.
>>> The smb.conf is as follows:
>>>  [global]
>>>         workgroup = NDG
>>>         netbios name = SAMBA
>>>         netbios aliases = Samba
>>>         server string = Samba Server Version %v
>>>         interfaces = lo, eth1, 192.168.230.232
>>>         bind interfaces only = Yes
>>>         security = DOMAIN
>>>         obey pam restrictions = Yes
>>>         passdb backend = tdbsam
>>>         pam password change = Yes
>>>         log file = /var/log/samba/%m.log
>>>         max log size = 50
>>>         load printers = No
>>>         add user script = /usr/sbin/useradd "%u" -n -g users
>>>         delete user script = /usr/sbin/userdel "%u"
>>>         add group script = /usr/sbin/groupadd "%g"
>>>         delete group script = /usr/sbin/groupdel "%g"
>>>         delete user from group script = /usr/sbin/userdel "%u" "%g"
>>>         add machine script = /usr/sbin/useradd -n -c "Workstation (%u)"
>>> -M -d /nohome -s /bin/false "%u"
>>>         logon path =
>>>         domain logons = Yes
>>>         os level = 32
>>>         preferred master = Yes
>>>         domain master = Yes
>>>         dns proxy = No
>>>         wins support = Yes
>>>         ldap ssl = no
>>>         create mask = 0664
>>>         directory mask = 0775
>>>         hosts allow = 127., 192.168.230., 192.168.231.
>>>         case sensitive = Yes
>>>         browseable = No
>>>         available = No
>>>         wide links = No
>>>         dont descend = /
>>>
>>> [homes]
>>>         comment = Home Directories
>>>         valid users = %S
>>>         read only = No
>>>         browseable = Yes
>>>         available = Yes
>>>
>>> [NDG]
>>>         comment = NDG files
>>>         path = /NDG
>>>         write list = @NDGstaff, @birdseye
>>>         read only = No
>>>         browseable = Yes
>>>         available = Yes
>>>
>>> I found that making the rule for port 139 ignore the eth port (i.e.
>>> remove the -i eth1) allowed things to work better, but do not want this
>>> to be the case as I do not want the eth0 interface to be used for this
>>> traffic.
>>> looking at netstat -l -n shows only lo and eth1 listening on port 139,
>>> so how is this failing to work??
>>> Any ideas?
>>> Thanks
>>>
>> ----
>> I don't believe that you want to use comma separators in things like
>> 'bind interfaces' or 'interfaces' - it doesn't seem that samba is
>> consistent here.
>>
>>
> removed
>> I have never used two separate hardware network interfaces on the same
>> subnet and suspect that it may actually be trying to communicate back
>> from the wrong one which is confusing things. Also, it doesn't make
>> sense to list both eth1 and the actual ip address in bind interfaces but
>> I would tend to doubt that would be a problem.
>>
>> Try taking eth0 down (as root - ifdown eth0) and see if that fixes the
>> problem.
> tried this and things appear to work okay, so I guess I need to split my
> subnet into two......
> Some further thinking required here. I have an almost identical set up
> in my home and actually tried all this there first, as I do not want my
> business impacted. So it appears to work fine at home but not at the
> office, some more testing required. I have only two windoze machines at
> home and neither access the server, so I'll have to contrive a setup
> that tries this out properly. Will keep you posted.....
>>
>>
>> Also, I'm not sure why some of the firewall rules include --state NEW
>> and some of the don't - that doesn't fully make sense to me.
>>
> state NEW is irrelevant for udp as it is a single direction with no
> handshaking such as tcp has - i.e. connectionless?
>> Craig
>>
>> _______________________________________________
>> CentOS mailing list
>> CentOS at centos.org
>> http://lists.centos.org/mailman/listinfo/centos
>>
>