Le dim 12/10/2003 à 19:53, richard lucassen a écrit : > case 1 > ************************************************************** > $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH > [..] > $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT > ************************************************************** Working... > case 2 (I swapped rule 1 and 2) > ************************************************************** > $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH > $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT > [..] > $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT > ************************************************************** Not working for SSH. In fact, it should work. A TCP SYN flaged as NEW will be sent to CH_SSH chain, then be accepted by CH_SSH rule that allows NEW packets. Then further packets are going by. They are ESTABLISHED. They match first rule so they are sent to CH_SSH chain. They do not match the rule, for thieses packets are not NEW. So they hit end of user chain and are returned to FORWARD chain, rule 2. They match rule 2 and then get accepted. If it does not work as your's, then you have a drop all rule at the end of CH_SSH chain (I suppose) that prevents packet from returning from user chain (CH_SSH here) to calling chain (FORWARD here). To me, the best way to handle this is : # ESTABLISHED and RELATED packets are accepted anyway # We accept them first as they are most treated packets $IPT -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Then we care of each proto. $IPT -A FORWARD -p tcp --dport 22 -j CH_SSH [...] $IPT -A CH_SSH -m state --state NEW -s 1.2.3.4 -j ACCEPT Case 3 works because you enforce ESTABLISHED,RELATED accept in your use chain. I really do think that 1st case is the best way to handle, as it implies less rules evaluation for each packet. -- http://www.netexit.com/~sid/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
