1. Overview

In this tutorial, we’ll learn about the different tables and chains in the iptables command. Additionally, we’ll learn how a packet traverses among these tables and chains.

2. Firewall Components

In Linux, there are a few parts that provide the firewall mechanism, such as the iptables and the netfilter. Understanding the relationship between the netfilter framework and the iptables command is vital for knowing how a packet gets processed by the firewall rules we’ve set on the system.

2.1. The iptables and netfilter

Firstly, the netfilter framework is an infrastructure in the kernel that provides the foundation for the firewall. Specifically, the netfilter provides five different hooks that are triggered on different parts of the journey of a packet. For example, any incoming traffic when it first enters the network stack will trigger the NF_IP_PRE_ROUTING hook.

Different programs can then register handling functions with these five hooks to perform some filtering or mangling on the packet. The ip_tables is one such kernel module that registers different tables and chains to the netfilter hooks. This way, when the different netfilter hooks are triggered, the ip_tables module will be notified, and actions can be performed on the packets.

Then, the popular iptables command is the userspace tool for managing the various tables and chains of the ip_tables kernel modules.

Next, we’ll learn about the meaning of chains and tables in the context of the iptables command.

2.2. Rules and Chains

At the lowest level of the firewall, a rule serves as the basic building block. We can define a rule to perform various actions on a packet, such as rejecting, dropping, logging, or mangling the packet. For example, with the iptables command, we can define a rule to deny all incoming packets targeting port 22 using the DROP syntax.

We can then combine these rules to form a chain. When a packet goes through a chain, the various rules on the chain will sequentially process the packet. If any of the rules reject or deny the packet, the journey of the packet terminates at that point in the system.

2.3. Tables

The different chains we define will, in turn, form the basis of a table. In the iptables command, there are the natmangle, and filter tables. As their name implies, each table consists of different chains that perform different actions on the packet that traverses it.

For example, the filter table contains chains that define rules for filtering packets by their attributes. We commonly work on the filter table to define rules for blocking or allowing traffic.

On the other hand, the nat table defines chains that perform network address translation (NAT) on the packet.

The mangle table consists of rules that modify the packet at various points of the journey. For example, we can modify the packet’s time to live (TTL) value by defining rules on the mangle table. These modifications allow us to change the path a packet takes by modifying its header.

With all these tables and chains, we must understand how a packet traverses through the network stack to prevent misconfiguring the firewall. In the following section, we’ll dive deep into the packet’s traversal path across the different tables and chains.

3. Packet Traversal

Generally, there are three different paths a packet can take, depending on the scenario. Firstly, a packet can come from outside the system, with the destination set to a local process. On the other hand, a local process can generate an outgoing packet to be delivered to another remote host. Finally, the system might receive a packet not intended for local processes and should be forwarded to another host.

All the different paths will hit the different iptables chains and tables in different sequences.

3.1. Incoming Packet to Local Process

When a packet comes into the network interface, the packet first hits the PREROUTING chain of the mangle table. This chain is typically used for changing the header value of the packet before it’s sent down to the rest of the chains.

Subsequently, the PREROUTING chain of the nat table will work on the packet to perform destination network address translation (DNAT) on the packet. The DNAT converts the destination IP address of the packet to the private IP address for further routing.

After the executions of the PREROUTING chains from the mangle and nat tables, the kernel will perform a routing decision for this packet. At this point, the packet could either be forwarded to another host using the forward packet path or the packet is destined for a local process. In the latter case, the packet is passed to the INPUT chain of the mangle table.

The INPUT chain of the mangle table defines a list of mangling operations on packets that are deemed for the local process.

Next, the packet hit the INPUT chain of the filter table. This is the chain where all the rules about dropping or rejecting a packet will reside. When a packet survives the entire traversal, it’ll finally reach the local process for further processing.

3.2. Outgoing Packet from Local Process

For an outgoing packet leaving the host, it first hits the OUTPUT chain of the mangle table. Then, the packet moves onto the OUTPUT chain of the nat table.

After both of the OUTPUT chains have processed the packets, the kernel makes a routing decision on the packet. This is because the chains might’ve altered the destination of the packet.

For packets that are leaving the system after the routing decision, they go through the OUTPUT chain of the filter table. Through the OUTPUT chain of the filter table, we can maintain rules to ensure that all the outgoing packets are only targeting trustable hosts.

If a packet survives the OUTPUT chain of the filter table, the kernel then passes the packet through the POSTROUTING chains of the mangle and nat table in that order. The main thing the OUTPUT chain of the nat table does here is source network address translation (SNAT). The SNAT ensures that the source IP address of the packet is updated to the public address of the network interface instead of a private network address.

3.3. Forwarded Packets

For packets that are to be forwarded, the first leg of the journey is the same as incoming packets. Concretely, the packet hits the PREROUTING chains of the mangle and nat table before the kernel performs the routing decision.

After the routing decision, all the packets to be forwarded will be evaluated by the FORWARD chain of the mangle table. We can define mangling operations on this chain to target forwarding packets specifically.

Then, the packet reaches the FORWARD chain of the filter table. Similar to the other chains on the filter table, we can define rules to drop or reject unwanted packets on the forward path.

Any surviving packets will be processed by the POSTROUTING chain of the mangle and nat tables, respectively. The POSTROUTING chain of the nat table is responsible for performing the SNAT to convert the source IP address from a private IP address to a public address.

3.4. Summarizing the Journeys

We can visualize the journeys of the packets using an ASCII diagram:

[network interface]
        |
        |                                         
        v                                               <incoming packet>
  PREROUTING (mangle) --> PREROUTING (nat) --> [routing] -----------> INPUT (mangle) --> INPUT (filter) --> [local process]
                                                   |                                                              |
                               <forwarding packet> |                                                              | <outgoing packet>
                                                   v                                                              v
                                           FORWARD (mangle)                                                 OUTPUT (mangle)
                                                   |                                                              |
 	                                           |                                                              |
                                                   v                                                              v
                                             FORWARD (filter)                                                 OUTPUT (nat)
                                                   |                                                              |
                                                   |                                                              |
                                                   |                                                              v
                                                   |                                                           [routing]
                                                   |                                                              |
                                                   |                                                              |
                                                   |                                                              v
                                                   |                                                           OUTPUT (filter)
                                                   |                                                              |
                                                   |                                                              |
                                                   |                                                              v
                                                   └----------------------------------------------------> POSTROUTING (mangle)
                                                                                                                  |
                                                                                                                  |
                                                                                                                  v
                                                                                                            POSTROUTING (nat)
                                                                                                                  |
                                                                                                                  |
                                                                                                                  v
                                                                                                          [network interface]

From the diagram, we can observe several interesting points. Firstly, the mangling chains always process the packets first in all three different paths. Right after the mangling, the chains in the nat table will kick in to ensure the addresses are correct.

As a rule of thumb, the hooks trigger the PREROUTING chains before any routing decision. This is to enable the flexibility for customizing the routing of packets. Conversely, the hooks always trigger the POSTROUTING chains right before the packets leave the host.

Interestingly, the chains in the filter tables always see the packets after the mangle and nat chains have processed them. Therefore, the rules in the filter tables always work on the post-mangle, post-translation packet state.

4. Conclusion

In this tutorial, we’ve looked at an overview of the iptables command. Then, we’ve also learned about the difference between a rule, chain, and table in the context of the iptables command.

Subsequently, we’ve taken a deep dive into the topic of packet traversal among the different tables and chains. Specifically, we detailed the path taken by incoming packets, outgoing packets, and packets to be forwarded.

By understanding the exact path a packet takes depending on the situation, we’ll be able to build better firewall rules to protect our system. Importantly, by understanding the interactions between the different tables and chains, we’ll be able to know which chain to look at when issues arise with our firewall setup.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.