The first question is what is conntrack. This is the website for conntrack-tools. With that in mind what does state do?
The State Match
The most useful match criterion is supplied by the state' extension,
which interprets the connection-tracking analysis of the
ip_conntrack' module. This is highly recommended.
Specifying -m state' allows an additional
--state' option, which is
a comma-separated list of states to match (the `!' flag indicates not
to match those states). These states are:
NEW A packet which creates a new connection.
ESTABLISHED A packet which belongs to an existing connection (i.e., a
reply packet, or outgoing packet on a connection which has seen
replies).
RELATED A packet which is related to, but not part of, an existing
connection, such as an ICMP error, or (with the FTP module inserted),
a packet establishing an ftp data connection.
INVALID A packet which could not be identified for some reason: this
includes running out of memory and ICMP errors which don't correspond
to any known connection. Generally these packets should be dropped.
An example of this powerful match extension would be:
# iptables -A FORWARD -i ppp0 -m state ! --state NEW -j DROP
Firewall questions about state and policy?
So, to answer the question, conntrack is for use with the conntrack toolkit and supersedes state in this regard. It is better than state if you are planning on using the conntrack tool kit.
Connection tracking is on for traffic flows, it constantly tries to match flows to rules.
The answer that follows for question 2 is, yes, use conntrack
To answer question 3, which case? The answer for state is in the definition above.
The answer to 4 is, conntrack is for use with the conntrack toolkit, and state, for not using the toolkit. Yes, you can use conntrack at no penalty over using state with your example.
Further to the other good answers, I recently had to use the mangle table to adjust for MTU (maximum transmission unit) discrepancies caused by traffic being brought through PPPoE, PPP, and ATM, each of which adds overhead that reduces the payload available for IP from the usual 1500 bytes of an Ethernet frame.
Systems on each end of the pipe, as is normal, would have their MTU at the regular default of 1500 and so they would try to send IP frames that large. Since the actual payload size available was smaller, this would have caused packet fragmentation, except that often the sender will request that packets not be fragmented, and as such they end up getting dropped entirely.
In an ideal world, path MTU discovery would have allowed the endpoints to adjust their MTU down as needed, but this discovery depends upon ICMP, and networks outside of my control were often configured to drop ICMP for security reasons.
The only choice was to use packet mangling in my router in order to modify TCP SYN packets to lower the maximum segment size at the transport layer:
iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1452
This sort of thing is messy and ideally should be avoided, but I had no other options and this did solve the problem.
Hope these examples help, as well as the man page.
Best Answer
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 theconntrack
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 exampleINVALID
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 thePREROUTING
chain of theRAW
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 anACCEPT
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.