Rob Townley wrote: > 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. > Okay, I get the issue, packet arrives on one interface but server sends it back on the other one due to routing rules, thus the client gets confused. Reading the man ip leaves me confused, I understand the basics but this is WAY over my competence level. What kind of rule do I need here, need some expert assistance please. Thanks Rob > 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 >>> >>> > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos > -------------- next part -------------- A non-text attachment was scrubbed... Name: rkampen.vcf Type: text/x-vcard Size: 121 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20090331/3b424a41/attachment-0005.vcf>