If you’re staring at a wall of iptables rules wondering what on earth is going on, you’re not alone.

Linux firewalls can feel hostile when all you want is: “Let the right packets in, keep the wrong packets out, and don’t break SSH.”

This guide walks through the basic architecture of iptables and netfilter so you understand where your rules actually run. Once that clicks, building and troubleshooting firewall policies gets much less scary.

I’ll keep it practical, short-paragraph style. No theory rabbit holes, just enough to help you fix real servers faster.

What problem are we actually solving?

If any of this sounds familiar, you’re in the right place:

• You added an iptables rule… and nothing changed.
• You opened a port but traffic still gets blocked.
• You’re not sure which rules apply to incoming vs outgoing vs forwarded packets.
• You see terms like netfilter, hooks, chains, and wonder how they connect.

Under the hood, iptables is not “the firewall” by itself.

It’s a userspace tool that talks to the Linux kernel’s packet filtering system, called netfilter. The kernel has well-defined points where packets can be inspected; iptables’ job is to install rules that run at those points.

If you don’t know those points, you end up guessing and poking at rules blindly. So let’s fix that.

Step 1: Understand the netfilter hooks (the real checkpoints)

The kernel networking stack has hooks where it lets firewall modules inspect packets.

Every packet that comes in or goes out triggers one or more of these hooks. The exact path depends on:

• Is the packet coming in or going out?
• Is this machine the final destination or just forwarding it?
• Did some rule already drop or reject it earlier?

Netfilter defines multiple hooks. The guide specifically mentions this one:

• NF_IP_PRE_ROUTING

This is triggered by any incoming traffic very soon after it enters the network stack.

It runs before routing decisions are made. That means the packet has just arrived, and the kernel hasn’t yet decided if it’s meant for this machine or should be forwarded somewhere else.

In plain language: PRE_ROUTING is the “front door” for anything entering the box.

The important idea:

• Programs (like the iptables kernel modules) register with these hooks.
• When a packet hits a hook, the registered code checks it against your firewall rules.
• Depending on the rule, the packet might be accepted, modified, or dropped.

You don’t call these hooks directly from the command line.

Instead, every iptables rule you write ends up attached to one of these hook points through the appropriate chain and table. That’s the mapping we care about.

Step 2: See how iptables talks to netfilter

iptables is the tool you use, but netfilter is the engine.

Here’s the relationship in simple terms:

• Netfilter provides hooks in the kernel networking stack.
• iptables provides syntax and commands in userspace.
• When you run iptables commands, they configure kernel modules that plug into those hooks.

So when the guide says:

The kernel modules associated with iptables register with these hooks in order to ensure that the traffic conforms to the conditions laid out by the firewall rules.

That’s the key link.

In practice, that means:

• You define rules with iptables.
• Those rules are stored in the kernel.
• As packets move through the networking stack and hit netfilter hooks, your rules are checked.

Why this matters for troubleshooting:

• If traffic isn’t behaving as expected, you want to know which hook (and therefore, which kind of chain) is in play.
• Rules on a hook that the packet never touches will do nothing, no matter how correct they look.

Step 3: Trace how a packet moves through the hooks

The guide explains that:

Every packet that passes through the networking layer (incoming or outgoing) will trigger these hooks, allowing programs to interact with the traffic at key points.

And:

The hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet’s destination, and whether the packet was dropped or rejected at a previous point.

Let’s turn that into a simple mental model.

We’ll focus on the high-level flow, without adding any extra hook names beyond what’s mentioned.

Incoming packet (maybe for this server, maybe passing through)

1. Packet arrives on a network interface.
2. It first hits NF_IP_PRE_ROUTING.
3. At this point, the firewall can already inspect it.
4. After that, the kernel decides: is this packet for us, or should we send it onward?
5. Depending on earlier decisions and rules, more hooks may or may not be triggered.

Key things to notice:

• Because PRE_ROUTING happens so early, rules tied to that hook are great for filtering or changing packets before routing.
• If a packet is dropped or rejected at this stage, it will never reach later hooks. So a too-strict rule early on can “mysteriously” block things you expected another rule to handle.

Outgoing packet (originating from this server)

The guide doesn’t go into details for every hook on outgoing traffic, but it tells us one important fact that applies to both directions:

As packets progress through the stack, they will trigger the kernel modules that have registered with these hooks.

In other words:

• Outgoing traffic has its own path through the stack.
• At each step, it triggers different hooks and thus different sets of rules.

So for troubleshooting, remember: incoming and outgoing flows do not necessarily hit the same hooks, and thus not the same rules.

Step 4: Use this mental model when writing rules

Now that you know there are multiple checkpoints (hooks), and rules attach to those via iptables, here’s how to apply that when you build or debug a firewall.

1. Always ask: where is this packet in its journey?

Before adding a rule, answer these:

• Is the traffic incoming, outgoing, or being forwarded?
• Is this machine the final destination or just a router/gateway?

Because:

The hooks that a packet will trigger depends on whether the packet is incoming or outgoing, the packet’s destination, and whether the packet was dropped or rejected at a previous point.

If you put a rule on a stage the packet never touches, it won’t help you.

2. Remember that early hooks see more traffic

NF_IP_PRE_ROUTING is:

triggered by any incoming traffic very soon after entering the network stack… processed before any routing decisions have been made.

So rules associated with that early point can:

• Act on all incoming packets, regardless of their final destination.
• Block or modify packets before routing.

When troubleshooting, that means:

• If some incoming traffic mysteriously never reaches your application, check the rules associated with that early stage.
• A too-broad or misconfigured rule there can make later rules irrelevant, because the packet is killed early.

3. Dropped early = invisible later

The guide mentions:

The hooks that a packet will trigger depends on… whether the packet was dropped or rejected at a previous point.

So:

• If you have a rule that drops the packet at an early point, the packet never reaches the next hooks.
• That’s why your “allow” rule might not seem to work: the packet died before it got there.

When debugging, mentally walk the packet through:

1. It arrives.
2. It hits the early hooks.
3. If it survives, it continues.

If you suspect an early drop, review your earlier-stage rules first, not just the ones you think should allow the traffic.

Step 5: Practical safety tips before changing firewall rules

Anytime we touch firewall rules on a live server, there’s one big fear: locking ourselves out, usually from SSH.

Even though the source text doesn’t list tools or commands, we can still follow some general safety practices that fit the architecture described.

1. Make changes in a test-friendly way

• If you can, use a staging server to test new policies before applying to production.
• The same netfilter/iptables architecture applies, so you can safely confirm that packets behave as expected.

Why it matters:

• Firewall mistakes are often about rules in the wrong place (wrong stage of the packet’s journey).
• Experimenting on a non-critical box helps you learn how packets hit the hooks without risking downtime.

2. Adjust rules in small steps

Because packets can be dropped early and never hit later hooks, change things in small increments:

• Add or adjust one rule at a time.
• After each change, test the specific traffic you care about.

If traffic suddenly stops working, you know exactly which change did it.

3. Document what you expect at each stage

Even a simple text note like this helps:

• “Incoming HTTP traffic should reach the server and not be dropped early.”
• “SSH from my IP should never be blocked at the earliest checkpoints.”

Mapping your intention against how the hooks work makes it easier to see where things might be wrong:

• If your intent is to block something late, but your rule attaches early, you’ll know why it acts differently than expected.

Step 6: Checklist for troubleshooting weird firewall behavior

Here’s a quick, architecture-based checklist for when iptables doesn’t behave how you expect.

You can walk through this mentally or on a notepad next to your terminal.

1. Identify the direction:
2. Is the traffic incoming or outgoing?

3. Could it be forwarded traffic through this server?

4. Consider the early stage:

5. Remember that NF_IP_PRE_ROUTING sees all incoming traffic early.

6. Ask: could any existing rule there be dropping or modifying it?

7. Check for early drops:

8. If the packet is rejected or dropped early, it never hits later hooks.

9. So look for rules that act on “any incoming traffic” and might be too broad.

10. Re-check your assumptions:

11. Don’t assume all traffic hits the same rules.

12. Different directions (incoming vs outgoing) and different roles (destination vs router) touch different hooks.

13. Change one thing at a time:

14. Adjust or comment out one suspicious rule.
15. Test again to see if packets start flowing.

Use the netfilter concept from the guide as your mental map: hooks are checkpoints, iptables rules sit on those checkpoints, and packets walk through them until something decides their fate.

Quick recap and next step

We’ve kept to the essentials from the source:

• Netfilter lives in the kernel and provides hooks where packets are inspected.
• iptables is the userspace tool that installs rules into kernel modules plugged into those hooks.
• Every packet triggers one or more hooks depending on direction, destination, and whether it was already dropped.
• NF_IP_PRE_ROUTING is the early checkpoint for any incoming traffic, before routing decisions.
• If a packet is dropped or rejected at an earlier checkpoint, it never reaches later rules, which explains a lot of “why doesn’t my rule work?” situations.

Use this mental model next time you touch your firewall: think in packet journeys and checkpoints, not just lines of iptables syntax.

Need more help? Check the latest CrushEdge posts.