From: "Jason Opperisano" <Jopperisano@xxxxxxxxxxxxxxxx>
To: <netfilter@xxxxxxxxxxxxxxxxxxx>
Subject: RE: Combination of state match and source/destination match problem.
Date: Wed, 4 Aug 2004 08:49:34 -0400
> I just want to figure out the relation between state match and IP address
> (source and destination ) match of iptables. And my Redhat 9.0 box which
> has a static IP address of 192.168.220.8 has a ssh service runing on tcp
> port 22. And my client Linux box with
> IP address 192.168.220.6 try to ssh my RH9 box.
>
> Here is my simple iptables rule on 192.168.220.8.
>
> #iptables -F
> #iptables -F -t nat
> #iptables -F -t mangle
Flushes the filter, nat and mangle tables. Note that flushing does not reset the POLICY setting of any chain.
> #iptables -P INPUT DROP
Sets the POLICY of the INPUT chain to DROP, meaning: if a packet goes through this chain and never matches any rule, it will be dropped.
> #iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
Any packet that is part of an ESTABLISHED conenction will be accepted.
> #iptables -A INPUT -s 192.168.220.6 -j ACCEPT
Any packet with a source IP of 192.168.220.6 will be accepted.
> To my understanding, the INPUT chain of 192.168.220.8 box here deny all the
> external NEW connetions INCLUDING connetions from 192.168.220.6. And the
> result is exact what
> I expected. I can't ssh my RH9 box from 192.168.220.6 as well as other
> boxes.
Not really--the rules you have specified should allow 192.168.220.6 to initiate a connection to any >port on any IP address local to any interface of the netfilter machine. The fact that it's not >working would lead me to believe that there's something else going on in your OUTPUT chain, or >the source of your connection is not actually 192.168.220.6. Remember--just because you allow a >packet in--doesn't necessarily mean that it has a way out.
> But when I change the iptables to:
> #iptables -F
> #iptables -F -t nat
> #iptables -F -t mangle
> #iptables -P INPUT DROP
> #iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
> #iptables -A INPUT -d 192.168.220.8 -j ACCEPT
>
> This time it works, I can ssh 192.168.220.8 from 192.168.220.6. Even when I
> replace the last rule with
> #iptables -A INPUT -p tcp --dport 22 -j ACCEPT
> it also works.
This would lead me to believe that somehow--the source IP of your SSH packets are not actually 192.168.220.6. If they were the previous ruleset should have worked too. So it probably does not have anything to do with the OUTPUT chain.
Yes , you are right. My source IP address was not 192.168.220.6. When I netstat it I ultimately found it's not 192.168.220.6! It's 192.168.220.1! I realized this was a problem of my VMware. My redhat 9 is a client OS with IP address 192.168.220.8. My VMware SNAT my host OS IP to 192.168.220.1 when it try to connect RH9 box. (Indeed my host OS doesn't have a IP of 192.168.220.6. I use this just because it explain easy).
> So this time it means INPUT chain of 192.168.220.8 box here deny all the
> external NEW connetions EXCEPT connetions to 192.168.220.8 OR destination
> port 22.
> But this conflicts with previous one. According to the previous example this
> doesn't work.
>
> So my question is what's the relation between state match and
> source/destination match?
> Or maybe which one comes first or who's seting overwrite the other?
The relation is this: the rules for each chain are process in order, one by one, first match wins. If no rule matches--the chain POLICY is enforced.
-j
Thanks very much Regards.
_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus
