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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx
>> http://lists.centos.org/mailman/listinfo/centos
>>
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
