0

assume you have an iptables rule as follows : source A ------> source B accept source B ------> source A drop.

i observe that : - a first tcp packet from A to B is accepted - reply packet from B is dropped.

why would reply packet is being dropped ? since the first packet from A - > B was allowed and accepted , it should have been added to connections table. when packet from B -> A is entering , a lookup should have been done prior to run rulematch and accept without running the rulebase which decides to drop. why do iptables doesnt perform a lookup ?

Thanks.

10
  • You really need to post an iptables-save. If even your rules are right, the order there in also is crucial to success. Do you have the standard related,established rule? iptables -I INPUT 1 -m conntrack -j ACCEPT --ctstate RELATED,ESTABLISHED
    – cybernard
    Mar 8, 2017 at 14:55
  • Hi, I have 2 rules : 1 rule is A - > B accept , second rule is B -> A drop and iptables always drop response from B to -> A. Why packets comming from B -> A are dropped ? does it mean that if i want to have connectivity between A to -> B , i always need to add a rule to "accept" reply packets ? Thanks.
    – Avi Nehori
    Mar 8, 2017 at 15:05
  • what are your default policies for INPUT,FORWARD,OUTPUT? you need this otherwise you will have problems. iptables -I INPUT 1 -m conntrack -j ACCEPT --ctstate RELATED,ESTABLISHED
    – cybernard
    Mar 8, 2017 at 15:44
  • my default policy is of course drop for all .
    – Avi Nehori
    Mar 8, 2017 at 15:46
  • my default policy is of course drop for all . my expectation is that when one flow of packet is accpted , teh reverse flow will be accepted as well . connection tracking for state doesnt help , i have tried it and still i get drops for the reverse flow . my expectation was that if A -> B is accpeted by the iptables rulematch , the reverse packets will be accepted as well . i dont see the reason why iptables perform rulmatch on a reverse packet. this means , that i need to create 2 rules for every single accept rule i desire . isnt it so ?
    – Avi Nehori
    Mar 8, 2017 at 15:49

2 Answers 2

0

Yes I did add it and no change. I observe this as general behaviour and when I look through Iptables source code it is expected behaviour . I wonder how iptables can be used at all as this is totally ridiculous thingy to add reverse rule . It is impossible to manage such rulebase. I hope we can clarify this. Thanks.

0

iptables is very low-level, and when you are writing iptables rules, you are dealing with raw IP packets. This has a number of implications, one of which you have found.

There are perfectly valid use cases for when outgoing traffic should be allowed, but any corresponding incoming traffic should not be allowed to pass through the firewall; or the other way around, incoming traffic allowed but outgoing not allowed. One common example for this is log storage servers (which in turn are often useful for auditing): Log traffic should be allowed in, but none should be allowed out. In the extreme case, log traffic should be allowed in, but nothing else should be allowed either in or out.

By iptables not making any assumptions about what you want, you not only increase security, but performance as well, because the rule set can be optimized for exactly what you want the firewall to actually do.

If you want to allow incoming traffic that is related to an already established connection or session, then just tell it so:

sudo iptables -I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

or for IPv6:

sudo ip6tables -I INPUT 1 -m state --state RELATED,ESTABLISHED -j ACCEPT

Adjust the -I INPUT 1 part on an as-needed basis (for example, if you have other rules that should take precedence over the general rule of allowing traffic relating to an established connection or session).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .