* NEW, The NEW state tells us that the packet is the first packet that we see. This means that the first packet that the conntrack module sees, within a specific connection, will be matched. For example, if we see a SYN packet and it is the first packet in a connection that we see, it will match. However, the packet may as well not be a SYN packet and still be considered NEW. This may lead to certain problems in some instances, but it may also be extremely helpful when we need to pick up lost connections from other firewalls, or when a connection has already timed out, but in reality is not closed.

* ESTABLISHED, The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED connections are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet, and that it later on gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state. ICMP reply messages can also be considered as ESTABLISHED, if we created a packet that in turn generated the reply ICMP message.

* RELATED, The RELATED state is one of the more tricky states. A connection is considered RELATED when it is related to another already ESTABLISHED connection. What this means, is that for a connection to be considered as RELATED, we must first have a connection that is considered ESTABLISHED. The ESTABLISHED connection will then spawn a connection outside of the main connection. The newly spawned connection will then be considered RELATED, if the conntrack module is able to understand that it is RELATED. Some good examples of connections that can be considered as RELATED are the FTP-data connections that are considered RELATED to the FTP control port, and the DCC connections issued through IRC. This could be used to allow ICMP error messages, FTP transfers and DCC's to work properly through the firewall. Do note that most TCP protocols and some UDP protocols that rely on this mechanism are quite complex and send connection information within the payload of the TCP or UDP data segments, and hence require special helper modules to be correctly understood.

So here is how it happens for a TCP connection:

Note that this rule only allows the return traffic in thru our router, it doesn’t tell the packet which PC in our network to go to. When the traffic first left the router and was classified as NEW, it also made a NAT table entry (therefore allowing return traffic to return to its rightful owner the PC that originated the connection). So the NAT table entry forwards it to the right local PC, but only after its allowed with the iptables conntrack entry (if iptables conntrack blocked it, then the traffic would drop, and never get forwarded – return traffic wouldn’t come thru)

Above we see how a connection goes from an ESTABLISHED state to a CLOSED state. CLOSED states are not allowed in (only ESTABLISHED and RELATED are allowed in), so thats when a connection is stopped/closed/finished.

For that link, you can see how the states work for UDP and ICMP traffic as well. We allow all NEW or outbound connections to start & go out the firewall; then we also allow ESTABLISHED and RELATED traffic to return. Then 2 way traffic allows can flow without issue as ESTABLISHED.

SIDENOTE  you might notice that the iptables module used to keep track is called -m conntrack, however there is another module called state that we setup with -m state. its practically identical, you can use either or. Id say its better to use conntrack because its newer and therefore supersedes state (therefore state is obsolete – however still used). difference between them: https://bbs.archlinux.org/viewtopic.php?id=131895. example of how to use state: http://www.puschitz.com/FirewallAndRouters.shtml