iptables Interview Questions: Packet Paths, Rule Order, and NAT Failures

A port-forward rule can record a hit while the application remains unreachable. A new allow rule can exist below the rule that already drops the packet. And a connection can keep using yesterday's NAT mapping after you edit today's rules.

Strong iptables interview answers follow the packet's current addresses, chain position and connection state. Explain which observation separates a filtering failure from a translation or return-path failure.

Evidence boundary: upstream iptables manuals, Netfilter documentation and Linux kernel documentation support the mechanics below. The gateway, rule traces and counter examples are original practice exercises. They are not candidate reports, employer question predictions or measurements of a real network. An offline model checks the worked verdicts; no host firewall configuration was changed. For ordered matching practice, start with First-Match CIDR Firewall: Status of an IP Address or a Whole CIDR Block.

Which chain sees this packet?

The filter table distinguishes packets delivered to local sockets (INPUT), routed through the machine (FORWARD), and generated locally (OUTPUT). A table groups rules; a chain is an ordered evaluation path. PREROUTING and POSTROUTING are not alternative names for the filter table's three chains. Upstream iptables manual

Before naming a chain, identify the address family, network namespace and routing decision. These exercises assume ordinary routed IPv4 traffic, enabled connection tracking and no bridge-specific path, tunnel or earlier packet drop. They omit other hooks to make the relevant decisions visible.

Original exercise	Relevant filter chain	What would change the answer?
External client connects to a socket on this gateway.	INPUT.	DNAT sends the destination to another host before routing.
Gateway routes a client's packet to a private server.	FORWARD.	The translated destination is instead a local address.
A process running on the gateway initiates a request.	OUTPUT.	The process is actually inside another network namespace.

The phrase “incoming traffic” is insufficient. A packet arriving on a physical interface may be forwarded rather than delivered locally. Likewise, testing a public address from the gateway itself does not reproduce the external client's ingress path.

Practice inference: if the failed request is forwarded, adding an INPUT allow rule does not address that request's filter decision. Confirm the path before proposing a change.

Trace a public port through DNAT and forwarding

Use this original topology: client 203.0.113.10:51000 reaches gateway 198.51.100.20:8443 on wan0. The gateway sends the service to private server 10.0.0.8:443 through lan0. Assume the server routes replies through the gateway and this example performs destination translation only.

A possible lab rule expresses the intended mapping:

# Illustrative lab configuration, not a complete gateway ruleset.
iptables -t nat -A PREROUTING -i wan0 -p tcp \
  -d 198.51.100.20 --dport 8443 \
  -j DNAT --to-destination 10.0.0.8:443

The DNAT target changes the destination address and optionally its port. The upstream extension manual documents its valid chains and options. DNAT documentation

Observation point in this request	Source	Destination	Decision to explain
External arrival, before translation	203.0.113.10:51000	198.51.100.20:8443	Does the new flow match the mapping?
After PREROUTING DNAT	203.0.113.10:51000	10.0.0.8:443	The destination has changed; the source has not.
Routing and filter FORWARD	203.0.113.10:51000	10.0.0.8:443	Is this destination routed through lan0 and allowed?
Private-server arrival	203.0.113.10:51000	10.0.0.8:443	Did the translated request reach the listener?
Reply as seen by the external client	198.51.100.20:8443	203.0.113.10:51000	Reverse translation preserves the public service identity.

The FORWARD rule in this exercise matches 10.0.0.8:443, not the original public destination. After forwarding, the request reaches POSTROUTING; there is no additional source rewrite in this particular ledger. Stateful NAT records the binding and applies the corresponding translation to subsequent traffic, including the reply direction. Netfilter stateful NAT guide

Practice inference: a DNAT counter increase establishes that the mapping rule was reached for a new binding lookup. It does not establish that forwarding is enabled, that FORWARD permits the translated tuple, or that the server returns traffic through this gateway.

Predict ordered rules, jumps and RETURN

Consider this original filter excerpt. The numbers label this exercise; they are not permanent rule identifiers. The FORWARD policy is DROP; all jumps shown use -j.

FORWARD
1  ESTABLISHED,RELATED                         -> ACCEPT
2  NEW, TCP, dst 10.0.0.8, dport 443            -> WEB_CHECK
3  NEW, TCP, dst 10.0.0.8, dport 443            -> ACCEPT
4  any                                        -> DROP

WEB_CHECK
1  src 203.0.113.0/24                          -> RETURN
2  any                                        -> DROP

A nonmatching rule advances evaluation. A matching target determines what happens next: a terminating verdict ends this traversal, while a jump enters another chain. RETURN from the called chain resumes after the caller's jump; in a built-in chain, RETURN invokes that chain's policy. iptables target semantics

For the allowed client's new translated request, FORWARD rule 1 does not match. Rule 2 calls WEB_CHECK; its first rule returns. Evaluation resumes at FORWARD rule 3, which accepts. RETURN is neither an unconditional accept nor a restart at FORWARD rule 1.

Change only the client to 198.51.100.77. WEB_CHECK's source condition fails, so its second rule drops the packet. FORWARD rule 3 is never reached. For an established reply, FORWARD rule 1 accepts before the destination-specific new-flow rules.

Now insert a broad DROP immediately after the jump and before the final allow. The permitted client's RETURN resumes at that DROP. Appending another allow at the bottom leaves the failure intact. “The rule exists” is weaker evidence than “the relevant packet reaches the rule.”

For two original new requests, one allowed and one denied, predict these increments:

Rule	Counter increment	Why?
FORWARD 2	2	Both requests enter WEB_CHECK.
WEB_CHECK 1	1	Only the permitted source returns.
WEB_CHECK 2	1	The other request terminates here.
FORWARD 3	1	Only the returning request reaches the allow.

A counter increase is not necessarily an accepted packet. A jump rule can count traffic later dropped in its child chain. A logging target can also continue evaluation; always inspect the target rather than assuming every matching rule terminates. Upstream extension manual

Why can NAT counters stay flat?

For normal stateful NAT, rule lookup establishes a flow's binding on its first packet; later packets use that binding without another NAT rule lookup. Consequently, a NAT rule's counter is not a byte-throughput measurement for every packet in the translated connection. Netfilter NAT binding semantics

In this exercise, imagine changing the destination from 10.0.0.8 to 10.0.0.9. An existing tracked flow can continue to the old destination. That observation does not, by itself, prove the edited rule was ignored. Compare an existing connection with a fresh flow whose tuple has no retained binding, and inspect the relevant conntrack entry.

NEW is also not a synonym for “TCP SYN.” The conntrack match describes NEW as a new connection or one that has not seen packets in both directions; ESTABLISHED concerns a connection seen in both directions. These are tracking classifications, distinct from an application's success or TCP flag shorthand. Conntrack match states

For evidence collection, use a filtered listing where supported, or inspect conntrack -L -p tcp in the relevant namespace and compare original and reply tuples. The official conntrack-tools manual covers listing and flow events. Avoid clearing the whole state table to test one mapping; that destroys evidence and affects unrelated flows. conntrack-tools manual

Diagnose a NAT failure with bounded evidence

Start with read-only observations in the namespace that owns the path:

iptables -V
iptables -t filter -S FORWARD
iptables -t filter -L FORWARD -n -v -x --line-numbers
iptables -t nat -L PREROUTING -n -v -x --line-numbers
iptables-save -c
sysctl -n net.ipv4.ip_forward

The version output identifies the kernel API in use. iptables-nft accepts iptables syntax while operating on nf_tables; it is not the legacy ruleset under another display name. Where native nftables rules coexist, inspect nft list ruleset as well. xtables-nft documentation

The save command records rules and, with -c, counters. Record counter values before and after one identified attempt without resetting them. iptables-save manual

Evidence from the original gateway exercise	Bounded conclusion	Next useful observation
Fresh flow has no matching DNAT increment.	The expected mapping match is unproved.	Check namespace, backend, arrival interface and original destination.
DNAT increments; an earlier FORWARD DROP increments.	Translation and a filtering failure are observed.	Trace translated fields through the ordered rules.
FORWARD allow increments; server sees no request.	This rule's allow verdict is observed.	Check route, egress and intervening devices.
Server sees request and sends reply; client sees nothing.	The fault remains on the return path or later processing.	Compare routes, gateway reply evidence and binding tuples.

IPv4 forwarding is a separate kernel setting. Reverse-path filtering can also matter when routes are asymmetric; inspect the applicable interface and global settings before changing either. Linux IP sysctl documentation

An ACCEPT verdict in one chain is not proof of end-to-end delivery. Native nftables can evaluate another base chain later and drop the packet. Its official manual documents that broader ruleset behavior. nftables evaluation semantics

Propose a narrow correction and prove its scope

Suppose the translated packet is dropped by an earlier broad FORWARD rule. In an isolated lab, insert the exact intended exception before that observed drop, then remove that same specification after the test:

# Replace position 2 with the observed insertion point in your lab.
iptables -I FORWARD 2 -i wan0 -o lan0 -p tcp \
  -s 203.0.113.10 -d 10.0.0.8 --dport 443 \
  -m conntrack --ctstate NEW -j ACCEPT

# Remove by exact specification; line numbers may have shifted.
iptables -D FORWARD -i wan0 -o lan0 -p tcp \
  -s 203.0.113.10 -d 10.0.0.8 --dport 443 \
  -m conntrack --ctstate NEW -j ACCEPT

This exception deliberately bypasses later checks for one tuple. Verify that this is the intended policy, preserve the separate reply rule, and check that denied sources remain denied. A remotely applied change also needs a recovery path; iptables-apply provides timed rollback when confirmation is not received. Availability and integration depend on the system. iptables-apply manual

Finish your answer with the observed failure, the smallest proposed change, a fresh-flow test, a denied-source test and rollback. Flushing the firewall loses the relationship between the defect and its correction.

Practice the matching and routing decisions

Practice question	What to explain afterward
Implement firewall matching with CIDR rules	Separate address membership from the policy verdict.
Implement CIDR firewall matcher	Check boundaries and overlapping source ranges.
First-Match CIDR Firewall: Status of an IP Address or a Whole CIDR Block	Show how an earlier terminating match changes the result.
Explain VPCs and private/public network connectivity	Distinguish translation, routing and policy boundaries.
Explain OS and networking basics	Connect host-generated traffic with sockets and packet paths.

Start with the First-Match CIDR Firewall exercise, then add the original gateway's changed destination and user-chain return. For capture construction and missing-packet limits, continue with tcpdump Interview Exercises.

Sources and Further Reading

• Upstream iptables manual
• Upstream iptables extension manual
• xtables-nft backend documentation
• Netfilter stateful NAT and binding semantics
• Official conntrack-tools user manual
• Linux IP sysctl documentation
• Official nftables manual and evaluation semantics
• iptables-save manual
• iptables-apply timed rollback manual

Research checked October 4, 2026. Commands are Linux lab examples; installed backend, kernel, namespaces and ruleset ownership determine the actual path.