LinuxQuestions.org - iptables: rule with RETURN target just after a rule with ACCEPT target

- Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)

- - iptables: rule with RETURN target just after a rule with ACCEPT target (https://www.linuxquestions.org/questions/linux-networking-3/iptables-rule-with-return-target-just-after-a-rule-with-accept-target-548857/)

iptables: rule with RETURN target just after a rule with ACCEPT target

Hi, I've seen in several scripts the following layout:

iptables criteria -j ACCEPT
iptables the_same_criteria_as_above -j RETURN

for instance:

iptables -A INPUT -p tcp -m tcp --dport 100 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 100 -j RETURN

The last rule will be never matched, because all tcp incoming
connections will be accepted, and then will go throw the next chain.
So, What is the usefulness of this configuration?

IMHO, I think is for changing the scripts in a fast way (just
commenting on the first line will yield in default policy for the
INPUT chain)

TIA

Paranoia, just in case it magically doesn't meet the accept criteria return to the table it came from so you're guaranteed it'll continue processing and eventually die(assuming your default policy is a paranoid DROP or DENY).

So, for example:

o If policy is DROP, all packets that match a rule with the ACCEPT target won't be accepted unless they match another rule with the RETURN target.

o If policy is ACCEPT, all packets that match a rule with the DROP target will be accepted
unless they match another rule with the RETURN target.

What if a packet matches a rule with a DROP/ACCEPT in a DROP/ACCEPT policy? Is it dropped/accepted at this moment ( independently the next rules) ??

TIA

Did you get those quotes from a man page, or from the script you are looking into?

From personal experience, if I set my default policy of DROP, and I have a rule that explicitly ALLOWs a packet, it passes through fine.

In the example you posted, the RETURN rule will never match if iptables is behaving properly. When you ACCEPT a packet, it moves on through routing and will never match another rule. Think of the following example:

Code:

iptables -P INPUT DROP

iptables -A INPUT -p tcp --dport 80 -j SOMEOTHERCHAIN

iptables -A INPUT -p tcp --dport 80 -j SOMEOTHERCHAIN2

iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -s 192.168.0.0/16 -j ACCEPT

iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -s 10.10.0.0/16 -j ACCEPT

iptables -A SOMEOTHERCHAIN -p tcp --dport 80 -j RETURN

iptables -A SOMEOTHERCHAIN2 -p tcp --dport 80 -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A SOMEOTHERCHAIN2 -p tcp --dport 80 -j RETURN

Any packet destined for port 80 moves into SOMEOTHERCHAIN, if it's source is 192.168.0.0/16 or 10.10.0.0/16 they are allowed through the firewall, all others will RETURN to the originating chain(in this case the INPUT chain) and then branch to the SOMEOTHERCHAIN2 rules(which will probably never match, nothing coming into the INPUT on port 80 will be established or related thanks to process forking).

Now, the RETURN statement is redundant, if it doesn't match the two rules for ACCEPT it will automatically fall back to the INPUT chain which would move it along in it's processing order.

Now, why wouldn't I just add my state checking in my original table? Sometimes it's for readability or script processing.

Code:

iptables -nvL --line-numbers INPUT

iptables -nvL --line-numbers SOMEOTHERCHAIN

iptables -nvL --line-numbers SOMEOTHERCHAIN2

Would give me the statistics per table that I can then use perl or python or bash to grep through and get numbers.

Quote:

Did you get those quotes from a man page, or from the script you are looking into?

They was just bad conclusions about the configuration script.

So, the last RETURN target from my script is completely useless, that is to say, that rule will be never matched.

Thanks

Correct, it will never match unless some really weird packet mangling happens.

Hi, can you help me?
I need iptables rule to allow all packets passing that comes from port 81