iptables: Questions regarding the raw table

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.

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.