2

I can read all over the internet that the iptables raw table is only there to specify if connection tracking should not be applied. However, when a rules destination in the raw table is -j DROP for instance, then the packet gets dropped and everything seems to work fine.

I have the following set of questions regarding this topic:

  • Will the connection tracking get confused when I -j DROP a packet in the raw table? One could assume that the kernel checks for the DROP destination at first, when reaching mangle/PREROUTING when dropping a packet according to "the internet" is allowed at first and therefore it would get connection tracked.
  • Would the use of the -j SYNPROXY destination in the raw table work?
  • Would the use of a final destination like -j ACCEPT in the raw table also lead to connection tracking?
  • Will the use of the -j NOTRACK stop the evaluation of the following rules in the raw table?

My aim is to use iptables with the highest possible performance, because I need to setup a Linux router which needs to guard a 10 GbE internet connection. My hope is that dropping a packet in the raw table without first specifying -j NOTRACK and then dropping the packet at a later stage will work just fine. I'm aware of the problem that I can't use connection tracking modules in the raw table. My aim is to use it as a first defense line with some generic hashlimit, SYNPROXY and DROP rules.

2

Netfilter packet flow diagram

This picture shows the flowing of packets in Linux kernel Netfilter subsystem, and is very useful in understanding how different rules affect network traffic.

Now to your questions:

Will the connection tracking get confused when I -j DROP a packet in the raw table?

When one drops a packet in raw table, the packet never reaches the conntrack module. This means that no connection tracking entry is created / consulted during packet's flow in the blocked direction.

However, there can be cases where a connection tracking entry is created when the traffic goes to the opposite direction. The conntrack knows this can happen and has for example INVALID state for those connections.

So, conntrack will not get "confused". However, you may encounter some unexpected behaviour due to different rules affecting packets on different directions for one connection.

Would the use of the -j SYNPROXY destination in the raw table work?

According to https://patchwork.ozlabs.org/patch/53494/ , the SYNPROXY target is designed to the PREROUTING chain of the RAW table. So, the answer is yes.

Would the use of a final destination like -j ACCEPT in the raw table also lead to connection tracking?

The ACCEPT is a "local" final destination, that is, when a packets hits an ACCEPT rule in a chain, it will leave current chain and go to the next chain according to the diagram.

So, it will lead to connection tracking, unless you enter the NOTRACK as the jump target.

Will the use of the -j NOTRACK stop the evaluation of the following rules in the raw table?

No, it is not a chain-terminating target.

2
  • Follow-up question: When the evaluation of a chain isn't stopped when -j NOTRACK is used, does that mean, that all other NOTRACK checks in the raw table are also executed? Wouldn't it be better to stop checking there, because the raw table "should" only contain checks regarding connection tracking? – Matthias Sep 29 '18 at 12:55
  • Yes, it means this. You can also set -j NOTRACK and a terminating target next to each other, which would prevent further NOTRACK rules evaluation. If NOTRACK would stop checking rules by itself, then you have no option to apply other rules (for example logging) to the packet, which is why it is not a terminating target. – Tero Kilkanen Sep 29 '18 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.