Iptables on TurboVision

Linux Networking Series, Part 7: Ten Years Later - nftables in Production

Wed, 09 Oct 2024 00:00:00 +0000

Ten years after nftables entered the Linux landscape, we can finally evaluate it as operators, not just early adopters.

In 2024, nftables has enough production mileage for operator-grade evaluation: distributions default toward nft-based stacks, migration projects have real scar tissue, and incident history is deep enough to separate marketing claims from operational truth.

By 2024, in many production environments, nftables has effectively displaced direct iptables administration. Compatibility layers still exist, legacy scripts still survive, but the center of gravity changed.

The important question now is not “is nftables new?”
The important question is “did the move improve real operations?”

What changed in daily practice

For teams that completed migration well, the practical improvements are clear:

one coherent rule language replacing fragmented command styles
better support for sets/maps and reduced rule duplication
cleaner atomic rule updates
improved maintainability for larger policy sets

For teams that migrated poorly, pain persisted:

compatibility confusion
mixed toolchain behavior surprises
partial rewrites with hidden legacy assumptions

As always, tools reward process quality.

The old world we came from

Before judging nftables, remember what many teams were carrying:

years of iptables shell scripts
environment-specific includes and patches
temporary exceptions that became permanent
inconsistent naming conventions
sparse ownership metadata

nftables did not magically erase this debt. It made debt more visible during migration.

Visibility is progress, but not completion.

Why `nftables` won mindshare

Operationally, three features drove adoption:

better data structures (sets/maps) for policy expression
transaction-like updates reducing partial-state risk
cleaner rule representation easier to review as code

The first point alone changed large policy management economics.

In iptables world, big address/port lists often meant repetitive rules. In nftables, sets made this concise and maintainable.

Example: policy expression quality

Conceptual nft style:

allow tcp dport { 22, 80, 443 } from trusted set
drop invalid states
allow established,related
default drop

This reads closer to policy intent than many historical shell loops building dozens of near-identical iptables rules.

Readable policy is not cosmetic. It lowers incident and audit cost.

The migration trap: compatibility wrappers as comfort blanket

Many distributions provided iptables-nft compatibility tooling. Useful for transition, dangerous if treated as destination.

Why dangerous:

operators think they are “still on old semantics”
actual backend behavior is nft-based
debugging assumptions diverge from runtime reality

Teams got into trouble when they mixed direct nft changes with legacy wrapper-driven scripts without explicit governance.

Recommendation:

decide primary control plane (nft native preferred)
isolate legacy wrapper usage to transition window
remove wrapper dependencies deliberately, not accidentally

Atomic updates: underrated reliability win

In older operational flows, partial firewall updates could produce transient lockouts or inconsistent states during deploy.

nftables transactional update behavior reduced this class of outage when used properly.

But “used properly” includes:

versioned rulesets
staged validation
tested rollback path

Atomicity reduces blast radius, not operator accountability.

Sets and maps: scaling policy without rule explosions

Large environments benefit massively:

IP allow/deny lists
service exposure groups
environment-based policy partitions

Instead of endless repetitive rule lines, sets centralize change points.

This improved both:

performance characteristics in many cases
human review quality

When policy size grows, abstraction quality determines whether your firewall remains operable.

Incident story: mixed backend confusion

A common migration-era outage:

legacy automation pushes iptables wrapper rules
on-call engineer applies urgent direct nft hotfix
next automation run overwrites assumptions
service flap and blame spiral

Root cause was not nftables quality. It was governance failure: no single source of truth.

Fix pattern:

freeze mixed write paths
declare canonical ruleset source repository
enforce one deployment mechanism
document break-glass procedure in same model

You cannot automate coherence if your control plane is politically split.

Operational model that works in current production

Mature teams converged on:

declarative ruleset files in version control
CI lint/sanity checks before deploy
environment-specific variables handled cleanly
staged rollout with quick rollback
post-deploy validation matrix

This looks like software engineering because by now it is software engineering.

Firewall policy is code.

Relationship with modern routing and observability stacks

In current production, networking operations usually combine:

nftables for policy and translation
iproute2 for route and link control
modern telemetry/flow visibility layers (sometimes eBPF-assisted)

The key is boundary clarity:

what nftables owns
what routing policy owns
what telemetry stack reports

Without boundaries, incident triage loops between teams.

The “iptables was simpler” argument

This argument appears in every migration.

Sometimes it means:

“we have not finished training”
“our old scripts hid complexity we no longer understand”
“our docs are behind”

Sometimes it reflects real pain:

migration tooling immaturity in specific environments
team overload during platform transitions

Dismissive responses are counterproductive. Serious response is better:

identify concrete friction
fix docs/tooling/process
keep policy behavior stable during change

Security posture: did `nftables` improve it?

In most disciplined environments, yes, through:

clearer policy expression
fewer accidental rule duplications
safer update semantics
better maintainability and review

In undisciplined environments, benefits were limited because:

stale exceptions remained
ownership remained unclear
review cadence remained weak

No firewall framework can compensate for absent operational governance.

Migration playbook (battle-tested)

If you still have substantial iptables legacy:

inventory active policy behavior and dependencies
classify rules by purpose and owner
model target policy natively in nft syntax
validate in staging with replayed representative flows
deploy in phases by environment criticality
retire compatibility wrappers on schedule
run monthly hygiene reviews post-migration

This is slower than big-bang conversion and faster than outage-driven rewrites.

Appendix: nftables production readiness audit

For teams wanting a hard self-check, this audit is practical.

Category 1: source-of-truth integrity

ruleset in version control
deploy path automated and consistent
emergency changes reconciled within SLA

Category 2: operability

on-call can inspect active ruleset quickly
rollback tested recently
incident runbooks reference current commands

Category 3: governance

each non-obvious rule or set has owner
temporary exceptions have expiry
review cadence enforced

Category 4: migration completeness

wrapper dependency inventory empty or controlled
no hidden automation writers using legacy paths
deprecation timeline executed and documented

Scoring low in one category is enough to trigger targeted remediation.

Appendix: standard post-deploy verification outline

After each policy release, we ran:

load confirmation check
published-service reachability checks
blocked-path verification checks
chain/set counter sanity checks
alert baseline check for abnormal deny spikes

This gave immediate confidence and faster rollback decisions when needed.

Appendix: monthly improvement loop

review top deny trends
remove stale exceptions
reconcile emergency hotfixes
review one random chain for readability
run one recovery drill scenario

This loop kept policy from drifting back into opaque legacy style.

Appendix: migration KPI set that actually helped

We tracked a short KPI set during migration:

policy-related incident count (monthly)
firewall-change-induced outage minutes
mean time from policy request to safe deployment
stale-exception count
operator onboarding time to independent change review

These KPIs reflected operational health better than raw rule-count or tool-version milestones.

Appendix: decommission proof package

When declaring iptables-era retirement complete, we archived a proof package:

final legacy script inventory marked retired
current native nft source-of-truth references
deploy pipeline logs for last 3 releases
runbook revision history
exception ledger with active owners

This package prevents recurring “are we really migrated?” uncertainty and makes audits straightforward.

Appendix: realistic warning

Even in 2024, full migration can regress if organizational discipline slips. Tooling maturity does not immunize teams against drift. Keep the hygiene loops, keep the ownership model, and keep practicing rollback. Mature stacks remain mature only while teams actively maintain them.

Appendix: shift-handover checklist for firewall operations

To reduce cross-shift mistakes, we standardized handover notes:

currently deployed ruleset revision
active temporary incident-control rules
unresolved policy-related alerts
next approved change window
explicit no-touch warnings for ongoing investigations

Strong handovers reduced accidental policy collisions and shortened investigation restarts.

Appendix: one-page migration retrospective

After each migration wave, teams captured one page:

what improved measurably
what remained harder than expected
which legacy assumptions survived
what process change must happen before next wave

This simple artifact preserved learning and prevented repeating the same migration mistakes at the next stage.

Appendix: practical maturity declaration criteria

A team can reasonably declare “nftables migration mature” only when all are true:

native ruleset is authoritative in production
compatibility wrappers are either removed or strictly bounded with documented exceptions
emergency changes are reconciled into source-of-truth within a defined SLA
runbooks and training are nft-native across all on-call rotations
regular hygiene reviews remove stale rules and exceptions

Anything less is an ongoing migration, not a completed one.

Final operational reflection

What ten years of nftables experience proves is simple: better primitives help, but discipline determines outcomes. If teams preserve ownership clarity, review culture, and rollback practice, nftables delivers substantial operational gains over legacy sprawl. If teams skip those disciplines, old failure patterns reappear under new syntax.

That conclusion is encouraging, not pessimistic: it means reliability is controllable. Teams can choose habits that make advanced tooling safe and effective. In that sense, nftables is not the end of a story; it is another chance to prove that operational craft scales across generations.

And that is the best way to interpret “obsoleted” in practice: not as a sudden replacement event, but as a completed operational transition where the newer model becomes the normal way teams design, deploy, review, and recover policy changes.

When that transition is complete, the debate shifts from “which command do we use” to “how quickly and safely can we adapt policy as systems evolve.” That is where mature operations teams should live.

And that is the operational meaning of progress in this domain: less time debating tooling identity, more time improving policy quality, deployment safety, and recovery speed. That focus is how migrations stay complete instead of cyclic. Sustained discipline is the real long-term differentiator. Without it, every tool generation eventually repeats old failure patterns.

Deep migration chapter: translating intent, not syntax

A mature nftables migration starts with intent mapping:

what should be reachable
who should reach it
under which protocol constraints
what should be blocked and logged

Teams that begin with command translation usually carry old complexity forward unchanged.

A practical method:

extract current behavior from legacy policy and flow observations
rewrite as plain-language policy statements
implement statements natively in nft syntax
validate against behavior matrix

This turns migration into architecture cleanup rather than command replacement.

Rule-object taxonomy that improved governance

We standardized object categories:

base chains
service exposure sets
admin/trust sets
temporary incident-control sets
logging policy chains

Each category had owner, review cadence, and naming style.

The result was faster audits and fewer accidental edits in critical chains.

CI/CD chapter: firewall policy as release artifact

By 2024, many teams manage firewall policy like software releases:

lint and parse validation in CI
style and convention checks
test environment apply and smoke validation
promotion to production with signed change metadata

This reduced midnight manual errors and created a defensible change history.

Drift control chapter

Even with good pipelines, drift appears through emergency interventions.

Drift control loop:

detect runtime ruleset deviation from repository state
classify drift as authorized emergency or unauthorized change
reconcile or revert
document root cause

Without drift control, teams eventually lose trust in both tooling and documentation.

Incident chapter: partial migration pitfall

A common failure pattern:

core firewall migrated to nft
one old maintenance script still uses compatibility commands
scheduled job rewrites expected objects unexpectedly

Symptoms:

intermittent policy regressions on schedule
difficult blame assignment

Resolution:

inventory all automation write paths
remove remaining wrapper-based writers
enforce one pipeline policy

This incident class is common enough to assume until disproven.

Incident chapter: set update gone wrong

Set-based policy is powerful and can fail loudly if update validation is weak.

Failure mode:

malformed or overbroad set input accepted
legitimate traffic blocked (or undesired traffic allowed)

Mitigation:

pre-apply set sanity checks
bounded change windows for large set updates
instant rollback object snapshot

Operationally, set management deserves same rigor as core ruleset changes.

Audit chapter: proving deprecation of iptables

When governance asks, “are we truly migrated?”, provide:

evidence that native nft is source-of-truth
proof compatibility wrappers are absent (or tightly isolated)
policy deploy logs from one controlled pipeline
runbook references using nft-native diagnostics

If this evidence is hard to produce, migration is likely incomplete.

Team design chapter: policy ownership model

High-maturity teams avoid ownership ambiguity by splitting roles:

architecture owner: policy model and standards
service owners: request and justify service-specific rules
operations owner: deploy and incident response process
security owner: review and risk posture validation

Shared responsibility with explicit boundaries outperforms vague “network team handles firewall.”

Resilience chapter: recovery drills in nft-era

Quarterly drills we found useful:

accidental overbroad deny in production-like environment
failed deploy transaction and rollback execution
stale set corruption simulation
mixed-tooling regression simulation

Drills expose process gaps faster than postmortems alone.

Documentation chapter: what should always exist

Minimum doc set:

ruleset architecture map
naming conventions and examples
emergency rollback playbook
source-of-truth and deploy pipeline policy
compatibility deprecation status

If docs are missing, staff turnover becomes outage risk.

Performance chapter: where teams overfocus

Many teams chase micro-benchmarks while ignoring bigger wins:

safer and faster change windows
lower human error rate
reduced policy drift

These are real performance metrics in operations, even if not expressed in packets per second.

Forward-looking chapter

With nftables mature in production, the challenge shifts:

keep policy understandable as systems grow
integrate with modern observability and programmable data-path tools
avoid recreating old debt in new syntax

The teams that win are not those with the fanciest commands. They are those with repeatable, explainable, well-governed operations.

A decade timeline: how the migration really unfolded

Looking back from 2024, the journey usually followed phases rather than one clean switch:

Phase 1 (early years): curiosity and lab adoption

selective testing
wrapper compatibility experiments
high uncertainty on tooling and operational patterns

Phase 2: controlled production use

non-critical environments migrate first
policy abstractions improve
mixed backends common and risky

Phase 3: default-by-distribution momentum

newer distributions steer teams toward nft backend
legacy scripts keep running through compatibility layers
operational debt from mixed models becomes visible

Phase 4: governance cleanup

teams choose native nft as source of truth
wrappers retired with deadlines
policy reviews and CI/CD mature

This timeline matters because expectations should match phase reality. Teams in phase 2 that claim phase 4 maturity tend to suffer avoidable incidents.

Native nftables design patterns that scale

The strongest production rulesets share consistent architecture patterns:

base chains by traffic direction and hook
include files or logical sections by service domain
sets/maps for large dynamic matching needs
clear naming conventions
explicit comments on non-obvious policy logic

Example conceptual structure:

table inet edge {
  set trusted_admin_v4 { ... }
  set trusted_admin_v6 { ... }
  chain input_base { ... }
  chain input_services { ... }
  chain forward_base { ... }
  chain nat_prerouting { ... }
  chain nat_postrouting { ... }
}

Using inet family tables where appropriate reduced policy duplication across IPv4/IPv6 in many deployments.

Translation quality: why naive conversion fails

Many teams attempted direct line-by-line conversion from historical iptables scripts. That preserved old debt under new syntax.

Better approach:

define desired traffic policy now
map to native nft constructs cleanly
only keep legacy quirks that are still required and documented

You do not get maintainability gains if you drag every historical workaround forward unexamined.

Atomic changes in real release pipelines

One underrated nftables win is controlled update behavior in deployment pipelines:

lint and parse checks pre-deploy
transactional apply
immediate post-apply validation probes
fast rollback artifact available

This reduced partial-state outages that were common in manual iptables command sequencing.

But this only works when deployment pipeline is respected. Manual emergency edits still need strict “reconcile back to source-of-truth” policy.

Container and orchestration era interactions

By 2024, many environments include container platforms and platform-managed network policy layers. nftables operations now intersect with:

orchestration-injected rules
overlay network behavior
host firewall baseline policy

Operational requirement:

explicitly define ownership boundary between platform-managed rules and operator-managed rules
inspect full effective ruleset during incidents

Blaming “the firewall” or “the orchestrator” separately is unhelpful if both write to packet policy domain.

Observability expectations in nft-era operations

Modern teams expect more than packet drop counters.

Useful observability stack around nftables:

per-chain/section counter dashboards
change annotation tied to deploy commits
deny spike alerts by zone/service class
periodic policy drift detection

This changed culture from reactive troubleshooting toward proactive hygiene.

Rule naming and policy language discipline

Nftables made policy more readable, but readability can still decay without naming conventions.

Good conventions include:

chain names by role and direction
set names by business intent (allow_partner_vpn, deny_known_abuse_sources)
comment style with owner and reason for exceptional cases

When names express intent, reviews are faster and safer.

When names are opaque (tmp1, fix_old), debt accumulates rapidly.

Case study: hosting provider edge modernization

A mid-size hosting provider migrated from legacy iptables script sprawl to native nft rulesets.

Initial state:

thousands of lines of generated and manual rules
weak ownership metadata
high fear around deploy windows

Program:

classify policy into baseline/shared/customer-specific layers
convert repetitive address rules into sets/maps
implement staged deployment with validation and rollback
build chain-level metrics dashboards

Outcomes:

smaller, clearer rulesets
faster onboarding for new operators
reduced policy-related incidents during releases

Main lesson:

tooling helps, but architecture and governance do the heavy lifting.

Case study: university network with legacy exceptions

A university environment had many long-lived exceptions:

research lab odd protocols
legacy service dependencies
temporary events becoming permanent

Migration approach:

every legacy exception mapped with owner and review date
unknown exceptions moved to quarantine review bucket
only justified exceptions migrated to native nft policy

Result:

policy shrank significantly
incident triage improved because unknown exceptions were no longer silently in path

This showed that migration projects are excellent opportunities for debt reduction, not just syntax replacement.

Case study: manufacturing network with strict uptime windows

In a manufacturing environment, release windows were narrow and outage tolerance low.

nftables adoption succeeded because:

canary lines were used before plant-wide rollout
rollback was automated and tested
production incident drills included firewall change failure scenarios

The critical factor was rehearsal.

Teams that rehearse recover faster and panic less.

Runbook upgrades for nftables operations

Mature runbooks now include:

how to inspect effective ruleset state quickly
how to correlate counters with expected traffic classes
how to identify whether policy mismatch is source-of-truth drift or deploy failure
how to execute emergency rollback safely
how to reconcile emergency hotfixes back into versioned policy

This closes the gap between emergency operations and long-term policy integrity.

Compatibility deprecation strategy

A realistic strategy to retire iptables compatibility layers:

inventory all remaining wrapper-based tooling
migrate automation to native nft interfaces
freeze new wrapper usage by policy
schedule staged disable in lower-risk environments
verify no hidden dependency before full removal

Teams that skip step 1 are surprised by old scripts embedded in forgotten maintenance jobs.

Security review benefits from cleaner policy constructs

Security assessments improved because nftables policy can be reviewed closer to business intent:

what should be reachable
from where
under what protocol constraints
with what exception ownership

Cleaner review language reduced meetings that previously devolved into command-by-command translation arguments.

Performance and correctness tradeoffs in large sets

Sets are powerful, but operational care is still needed:

update path validation
source-of-truth synchronization
sanity checks for accidental overbroad entries

A single bad set update can have wide impact quickly. Strong CI validation and staged deployment mitigate this.

Organizational anti-patterns still common in 2024

“nftables migration done” declared while wrappers still drive production
no clear chain ownership across teams
emergency fixes not reconciled into source repository
dashboards showing counters nobody reviews

Maturity is not installation status.
Maturity is reliable operational behavior over time.

What high-maturity teams do differently

maintain policy architecture docs as living artifacts
enforce review culture around policy changes
run recurring recovery drills
measure policy-related incident rates and MTTR
budget time for cleanup, not only feature work

These behaviors produce compounding reliability gains.

Interop with eBPF-focused environments

In modern stacks, nftables and eBPF often coexist:

nftables anchors baseline filtering/NAT policy
eBPF contributes specialized telemetry or high-performance path logic

The critical point is explicit contract:

which layer is authoritative for which decision
how changes are coordinated
where to debug first during incidents

Without this contract, teams chase ghosts between layers.

A practical 2024 checklist for “iptables truly replaced”

You can claim real replacement when:

native nft ruleset is sole source-of-truth
wrappers are removed or strictly isolated and monitored
deploy pipeline validates and applies nft rules atomically
rollback path is tested quarterly
incident runbooks reference nft-native diagnostics first
operators across rotations can explain chain/set architecture

If any item is missing, migration is still in progress.

Performance observations from the field

Performance outcomes depend on workload and rule design, but practical wins often came from:

set-based matches replacing long linear rule chains
more coherent ruleset organization
reduced update churn side effects

The biggest measurable gain in many teams was not raw packet throughput. It was reduced operational latency: faster safer changes, faster audits, faster incident interpretation.

Documentation style for nft-era teams

Useful documentation moved from command snippets to policy intent artifacts:

ruleset architecture overview
object naming conventions
change workflow and approval boundaries
emergency response runbooks
compatibility deprecation timeline

This lowered onboarding time and reduced “single wizard admin” risk.

Cultural lesson: migrations fail socially first

After a decade of experience, one pattern is constant:

technical migration plans usually exist
social adoption plans often do not

Successful nftables programs included:

training sessions by incident scenario, not only syntax
paired reviews between legacy and modern operators
explicit retirement dates for old methods
leadership support for refactor time

Without these, teams keep legacy behavior under new syntax and call it progress.

Where nftables sits relative to eBPF era

Some people frame this as a binary:

“nftables is old now, eBPF is what matters”

Operationally, that framing is weak.

Most production environments use layered tooling:

nftables for clear policy expression and NAT/filter foundations
eBPF-based systems for advanced telemetry and specialized packet processing

Complementary tools, not forced replacement.

A hard truth from long production operation

Tool migrations are often sold as feature upgrades. In reality, they are reliability projects.

You should judge success by:

fewer policy-related incidents
faster safe change windows
clearer ownership and auditability
lower onboarding friction

If those outcomes are absent, migration is unfinished regardless of syntax.

What we should stop doing

By now, teams should retire these anti-patterns:

editing production firewall state manually without source-of-truth update
keeping undocumented temporary exceptions
running mixed compatibility/native control paths indefinitely
treating firewall policy as network-team-only concern

Policy touches application behavior, security posture, and operations. Shared ownership with clear boundaries is mandatory.

What we should keep doing

behavior-first policy design
deterministic deploy + rollback workflows
regular rule hygiene reviews
incident-driven runbook refinement
cross-team training with real scenarios

These practices survived every generation in this series because they work.

A practical 30-day hardening plan after migration

Many teams complete syntax migration and declare victory too early. The first 30 days after cutover decide whether the change actually improves reliability.

Week 1:

freeze non-essential policy expansion
run daily diff review against source-of-truth ruleset
verify compatibility-layer usage is decreasing, not growing

Week 2:

execute controlled incident drill (published service break, rollback, restore)
validate that on-call responders can diagnose with native nft outputs
review emergency exceptions and attach expiry/owner to each one

Week 3:

perform cross-team rule-readability review with security and application owners
remove duplicate or obsolete set entries
document one-page “critical path” policy map for high-impact services

Week 4:

run reboot and deployment pipeline validation end-to-end
confirm audit artifacts are generated automatically
close migration ticket only when rollback and diagnostics are demonstrated by non-author operator

This plan is deliberately simple. The objective is to convert a technical migration into an operationally stable state.

When teams skip this hardening phase, the same pattern appears repeatedly:

temporary compatibility shortcuts become permanent
native model understanding remains shallow
incidents regress to guesswork during pressure windows

When teams run this hardening phase with discipline, they usually get the benefits they expected from nftables in the first place.

Closing this series

From 90s basics to nft-era production, Linux networking history is not a museum of commands. It is a story of progressively better models and the teams learning (sometimes slowly) to operate those models responsibly.

The command names changed:

ifconfig/route
ipfwadm
ipchains
iptables
nftables

The core craft did not:

understand packet path
express policy clearly
verify with evidence
document intent
rehearse recovery

If you keep that craft, you can survive the next tooling decade too.

And if you want one fast self-test for your own environment, ask this during your next incident review: could a non-author operator explain the active policy path and execute rollback confidently? If the answer is yes, your migration is operationally real.

Linux Networking Series, Part 5: iptables and Netfilter in Practice

Mon, 09 Oct 2006 00:00:00 +0000

If ipchains was a meaningful step, iptables with netfilter architecture was the real modernization event for Linux firewalling and packet policy.

This stack is now mature enough for serious production and broad enough to scare teams that treat firewalling as an occasional script tweak. It demands better mental models, better runbooks, and better discipline around change management.

This article is an operator-focused introduction written from that maturity moment: enough years of field use to know what works, enough fresh memory of migration pain to teach it honestly.

The architectural shift: from command habits to packet path design

The most important change from older generations was not “different command syntax.” It was architecture:

packet path through netfilter hooks
table-specific responsibilities
chain traversal order
connection tracking behavior

Once you understand those, iptables becomes predictable. Without them, rules become superstition.

Netfilter hooks in plain language

Conceptually, packets traverse kernel hook points. iptables rules attach policy decisions to those points through tables/chains.

Practical flow anchors:

PREROUTING (before routing decision)
INPUT (to local host)
FORWARD (through host)
OUTPUT (from local host)
POSTROUTING (after routing decision)

If you misplace a rule in the wrong chain, policy will appear “ignored.” It is not ignored. It is simply evaluated elsewhere.

Table responsibilities

In daily operations, you mostly care about:

filter: accept/drop policy
nat: address translation decisions
mangle: packet alteration/marking for advanced routing/QoS

Other tables exist in broader contexts, but these three carry most practical deployments on current systems.

Rule of thumb

security policy: filter
translation policy: nat
traffic steering metadata: mangle

Mixing concerns makes troubleshooting harder.

Built-in chains and operator intent

For filter, the common built-in chains are:

INPUT
FORWARD
OUTPUT

Most gateway hosts focus on FORWARD and selective INPUT. Most service hosts focus on INPUT and minimal OUTPUT policy hardening.

Explicit default policy matters:

1
2
3

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

Defaults are architecture statements.

First design principle: allow known good, deny unknown

The strongest operational baseline remains:

set conservative defaults
allow loopback and essential local function
allow established/related return traffic
allow explicit required services
log/drop the rest

Example core:

1
2
3

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

Then explicit service allowances.

This style produces legible policy and stable incident behavior.

Connection tracking changed everything

Stateful behavior through conntrack was a major practical improvement:

easier return-path handling
cleaner service allow rules
reduced need for protocol-specific workarounds in many cases

But conntrack also introduced operator responsibilities:

table sizing and resource awareness
timeout behavior understanding
special protocol helper considerations in some deployments

Ignoring conntrack internals under high traffic can produce weird failures that look like random packet loss.

NAT patterns that appear in real deployments

Outbound SNAT / MASQUERADE

Small-office gateways commonly used:

`1`	`iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE`

Or explicit SNAT for static external addresses:

`1`	`iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to-source 203.0.113.10`

Inbound DNAT (port-forward)

Example:

1
2

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 443 -j DNAT --to-destination 192.168.10.20:443
iptables -A FORWARD -p tcp -d 192.168.10.20 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Translation alone is not enough; forwarding policy must align.

Common mistake: NAT configured, filter path forgotten

A recurring outage class:

DNAT rule exists
service reachable internally
external clients fail

Cause:

missing FORWARD allow and/or return-path handling

Fix:

treat NAT + filter + route as one behavior unit

This sounds obvious. It still breaks real systems weekly.

Logging strategy for operational clarity

A usable logging pattern:

1
2

iptables -A INPUT -j LOG --log-prefix "FW INPUT DROP: " --log-level 4
iptables -A INPUT -j DROP

But do not blindly log everything at full volume in high-traffic paths.

Better:

log specific choke points
rate-limit noisy signatures
aggregate top offenders periodically
keep enough retention for incident context

Log design is part of firewall design.

Chain organization style that scales

Monolithic rule lists become unmaintainable quickly. Better pattern:

create user chains by concern
dispatch from built-ins in clear order

Example concept:

INPUT
  -> INPUT_BASE
  -> INPUT_SSH
  -> INPUT_WEB
  -> INPUT_MONITORING
  -> INPUT_DROP_LOG

This improves readability, review quality, and safer edits.

Scripted deployment and atomicity mindset

Manual command sequences in production are error-prone. Use canonical scripts or restore files and controlled load/reload.

Key habits:

keep known-good backup policy file
run syntax sanity checks where available
apply in maintenance windows for major changes
validate with fixed flow checklist
keep rollback command ready

Firewalls are critical control plane. Treat deploy discipline accordingly.

Migration from ipchains without accidental policy drift

Successful migrations followed this path:

map behavioral intent from existing rules
create equivalent policy in iptables
test in staging with representative traffic
run side-by-side validation matrix
cut over with rollback timer window

The dangerous approach was direct command translation without behavior verification.

One line can look equivalent and still differ in chain context or state expectation.

Interaction with `iproute2` and policy routing

Many advanced deployments now mix:

iptables marking (mangle)
ip rule selection
multiple routing tables

This enabled:

split uplink policy
class-based egress routing
backup traffic steering

It also increased complexity sharply.

The winning strategy was explicit documentation:

mark meaning map
rule priority map
table purpose map

Without this, troubleshooting becomes archaeology.

Performance considerations

iptables can perform very well, but sloppy rule design costs CPU and operator time.

Practical guidance:

place high-hit accepts early when safe
avoid redundant matches
split hot and cold paths
use sets/structures available in your environment for repeated lists when appropriate

And always measure under real traffic before declaring optimization complete.

Packet traversal deep dive: stop guessing, start mapping

Most iptables confusion dies once teams internalize packet traversal by scenario.

Scenario A: inbound to local service

High-level path:

packet arrives on interface
nat PREROUTING may evaluate translation
route decision says “local destination”
filter INPUT decides allow/deny
local socket receives packet

If you add a rule in FORWARD for this scenario, nothing happens because packet never traverses forward path.

Scenario B: forwarded traffic through gateway

High-level path:

packet arrives
nat PREROUTING may alter destination
route decision says “forward”
filter FORWARD decides allow/deny
nat POSTROUTING may alter source
packet exits

Teams often forget step 5 when debugging source NAT behavior.

Scenario C: local host outbound

High-level path:

local process emits packet
filter OUTPUT evaluates policy
route decision
nat POSTROUTING source translation as applicable
packet exits

When local package updates fail while forwarded clients succeed, check OUTPUT policy first.

Conntrack operational depth

The ESTABLISHED,RELATED pattern made many policies concise, but conntrack deserves operational respect.

Core states in day-to-day policy

NEW: first packet of connection attempt
ESTABLISHED: known active flow
RELATED: associated flow (protocol-dependent context)
INVALID: malformed or out-of-context packet

Conservative baseline:

1
2

iptables -A INPUT -m state --state INVALID -j DROP
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Capacity concerns

Under high connection churn, conntrack table pressure can cause symptoms misread as random network instability.

Signs:

intermittent failures under peak load
bursty timeouts
kernel log hints about conntrack limits

Response pattern:

measure conntrack occupancy trends
tune limits with capacity planning, not panic edits
reduce unnecessary connection churn where possible

Timeout behavior

Different protocols and traffic shapes interact with conntrack timeouts differently. If long-lived but idle sessions fail consistently, timeout assumptions may be involved.

This is why firewall ops and application behavior discussions must meet regularly. One side alone rarely sees full picture.

NAT cookbook: practical patterns and their traps

Pattern 1: simple internet egress for private clients

1
2
3

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i ppp0 -o eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT

Trap:

forgetting reverse FORWARD state rule and blaming provider.

Pattern 2: static public service publishing with DNAT

1
2

iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 25 -j DNAT --to-destination 192.168.30.25:25
iptables -A FORWARD -p tcp -d 192.168.30.25 --dport 25 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Trap:

no explicit source restriction for admin-only services accidentally exposed globally.

Pattern 3: SNAT for deterministic source address

`1`	`iptables -t nat -A POSTROUTING -o eth1 -s 192.168.30.0/24 -j SNAT --to-source 203.0.113.20`

Trap:

mixed SNAT/masquerade logic across interfaces without documentation.

Anti-spoofing and edge hygiene

Early iptables guides often underplayed anti-spoof rules. In real edge deployments, they matter.

Typical baseline thinking:

packets claiming internal source should not arrive from external interface
malformed bogon-like source patterns should be dropped
invalid states dropped early

This reduced noise and improved signal quality in logs and IDS workflows.

Modular matches and targets: power with complexity

iptables module ecosystem allowed expressive policy:

interface-based matches
protocol/port matches
state matches
limit/rate controls
marking for downstream routing/QoS

The danger was uncontrolled growth: each module use introduced another concept reviewers must validate.

Operational safeguard:

maintain a “module usage registry” in docs
explain why each non-trivial match/target exists

If reviewers cannot explain module intent, policy quality decays.

Marking and advanced steering

A powerful pattern in current deployments:

classify packets in mangle table
assign mark values
use ip rule to route by mark

This enabled business-priority routing strategies impossible with naive destination-only routing.

But it required exact documentation:

mark value meaning
where mark is set
where mark is consumed
expected fallback behavior

Without this, troubleshooting becomes “why is packet 0x20?” archaeology.

Firewall-as-code before the phrase became fashionable

Strong teams treated firewall policy files as code artifacts:

version control
peer review
change history tied to intent
staged testing before production

A practical file layout:

rules/
  00-base.rules
  10-input.rules
  20-forward.rules
  30-nat.rules
  40-logging.rules
tests/
  flow-matrix.md
  expected-denies.md

This structure improved onboarding and reduced fear around change windows.

Large environment case study: branch office federation

A company with multiple branch offices standardized on Linux gateways running iptables.

Initial problems:

each branch had custom local rule hacks
central operations had no unified visibility
incident response quality varied wildly

Program:

define common baseline policy
allow branch-specific overlay section with strict ownership
central log normalization and weekly review
branch runbook standardization

Results after six months:

fewer branch-specific outages
faster cross-site incident support
measurable reduction in unknown policy exceptions

The enabling factor was not a new module. It was governance structure.

Troubleshooting matrix for common 2006 incidents

Symptom: outbound works, inbound publish broken

Check:

DNAT rule hit counters
FORWARD allow ordering
backend service listener
reverse-path routing

Symptom: only some clients can reach internet

Check:

source subnet policy scope
route to gateway on clients
NAT scope and exclusions
local DNS config divergence

Symptom: random session drops at peak load

Check:

conntrack occupancy
CPU and interrupt pressure
log flood saturation
upstream quality and packet loss

Symptom: post-reboot policy mismatch

Check:

persistence mechanism path
startup ordering
stale manual state not represented in canonical files

Most post-reboot surprises are persistence discipline failures.

Compliance posture in small and medium teams

More organizations now need evidence of network control for audits or customer expectations.

Low-overhead compliance support artifacts:

monthly ruleset snapshot archive
change log with reason and approver
service exposure list and owners
incident postmortem references

This was enough for many environments without building heavyweight process theater.

What not to do with `iptables`

do not store critical policy only in shell history
do not apply high-risk changes without rollback path
do not leave “allow any any” emergency rules undocumented
do not mix experimental and production chains in same file without boundaries

Every one of these has caused avoidable outages.

What to institutionalize

one source of truth
one validation matrix
one rollback procedure per host role
scheduled policy hygiene review
training by realistic incident scenarios

These practices matter more than specific syntax style.

Appendix A: rule-review checklist for production teams

Before approving any non-trivial firewall change, reviewers should answer:

Which traffic behavior is being changed exactly?
Which chain/table/hook point is affected?
What is expected positive behavior change?
What is expected denied behavior preservation?
What is rollback plan and trigger?
Which monitoring/log counters validate success?

If reviewers cannot answer these, the change is not ready.

Appendix B: two-host role templates

Template 1: internet-facing web node

Policy goals:

allow inbound HTTP/HTTPS
allow established return traffic
allow minimal admin access from management range
deny and log everything else

Operational controls:

strict source restrictions for admin path
explicit update/monitoring egress rules if OUTPUT restricted
monthly exposure review

Template 2: edge gateway with NAT

Policy goals:

controlled FORWARD policy
explicit NAT behavior
selective published inbound services
aggressive invalid/drop handling

Operational controls:

conntrack monitoring
deny log tuning
post-change end-to-end validation from representative client segments

These templates are not universal, but they create predictable baselines for many environments.

Appendix C: emergency change protocol

In real life, urgent changes happen during incidents.

Emergency protocol:

announce emergency change intent in incident channel
apply minimal scoped change only
verify target behavior immediately
record exact command and timestamp
open follow-up task to reconcile into source-of-truth file
remove or formalize emergency change within defined window

The key step is reconciliation.

Unreconciled emergency commands become hidden divergence and outage fuel.

Appendix D: post-incident learning loop

After every firewall-related incident:

classify failure type (policy, process, capacity, upstream)
identify one runbook improvement
identify one policy hygiene improvement
identify one monitoring improvement
schedule completion with owner

This loop prevents repeating the same outage with different ticket numbers.

Advanced practical chapter: policy for partner integrations

Partner integrations caused repeated complexity spikes:

external source ranges changed without notice
undocumented fallback endpoints appeared
old integration docs were wrong

Best approach:

maintain partner allowlists as explicit objects with owner
keep source-range update process defined
monitor hits to partner-specific rule groups
remove unused partner rules after decommission confirmation

Partner traffic is business-critical and often under-documented. Treat it as first-class policy domain.

Advanced practical chapter: staged internet exposure

When publishing a new service:

validate local service health first
expose from restricted source range only
monitor behavior and logs
widen source scope in controlled steps

This “progressive exposure” prevented many launch-day surprises and made rollback decisions easier.

Big-bang global exposure with no staged observation is unnecessary risk.

Capacity chapter: conntrack and logging under event spikes

During high-traffic events (marketing campaigns, incidents, scanning bursts), two controls often fail first:

conntrack resources
logging I/O path

Preparation checklist:

baseline peak flow rates
estimate conntrack headroom
test logging pipeline under simulated spikes
predefine temporary log-throttle actions

Teams that test spike behavior stay calm when spikes arrive.

Audit chapter: proving intended exposure

Security reviews improve when teams can produce:

current ruleset snapshot
service exposure matrix
evidence of denied unexpected probes
change history with intent and approval

This turns audit from adversarial questioning into engineering review with traceable artifacts.

Operator maturity chapter: when to reject a requested rule

Strong firewall operators know when to say “not yet.”

Reject or defer requests when:

source/destination details are missing
business owner cannot be identified
requested scope is broader than requirement
no monitoring plan exists for high-risk change

This is not obstruction. It is risk management.

Team scaling chapter: avoiding the single-firewall-wizard trap

If one person understands policy and everyone else fears touching it, your system is fragile.

Countermeasures:

mandatory peer review for significant changes
rotating on-call ownership with mentorship
quarterly tabletop drills for firewall incidents
onboarding labs with intentionally broken policy scenarios

Resilience requires distributed operational literacy.

Appendix E: environment-specific validation matrix examples

One-size validation lists are weak. We used role-based matrices.

Web edge gateway matrix

external HTTP/HTTPS reachability for public VIPs
external denied-path verification for non-published ports
internal management access from approved source only
health-check system access continuity
logging sanity for denied probes

Mail gateway matrix

inbound SMTP from internet to relay
outbound SMTP from relay to internet
internal submission path behavior
blocked unauthorized relay attempts
queue visibility unaffected by policy changes

Internal service gateway matrix

app subnet to db subnet expected paths
backup subnet to storage paths
blocked lateral traffic outside policy
monitoring path continuity

Matrixes tied validation to business services rather than generic “ping works.”

Appendix F: tabletop scenarios for firewall teams

We ran short tabletop exercises with these prompts:

“New partner integration requires urgent exposure.”
“Conntrack pressure event during seasonal traffic spike.”
“Remote-only maintenance causes admin lockout.”
“Unexpected deny flood from one region.”

Each tabletop ended with:

first five diagnostic steps
immediate containment actions
long-term fix candidate

These exercises improved incident behavior more than passive reading.

Appendix G: policy debt cleanup sprint model

Quarterly cleanup sprint tasks:

remove stale exceptions past review date
consolidate duplicate rules
align comments/owner fields with reality
update runbook examples to match current policy
rerun full validation matrix

Result:

shorter rulesets
clearer ownership
reduced migration pain during next upgrade cycles

Debt cleanup is not optional maintenance theater. It is reliability work.

Service host versus gateway host profiles

Do not use one firewall template for all hosts blindly.

Service host profile

strict INPUT policy for exposed services
minimal OUTPUT restrictions unless policy demands
no FORWARD role in most cases

Gateway profile

heavy FORWARD policy
NAT table usage
stricter log and conntrack visibility requirements

Role-specific policy prevents accidental overcomplexity.

Appendix H: policy review questions for auditors and operators

Whether the reviewer is internal security, operations, or compliance, these questions are high value:

Which services are intentionally internet-reachable right now?
Which rule enforces each exposure and who owns it?
Which temporary exceptions are overdue?
What is the tested rollback path for failed firewall deploys?
How do we prove denied traffic patterns are monitored?

Answering these consistently is a sign of operational maturity.

Appendix I: cutover day timeline template

A practical cutover timeline:

T-60 min: baseline snapshot and stakeholder confirmation
T-30 min: freeze non-essential changes
T-10 min: preload rollback artifact and access path validation
T+0: apply policy change
T+5: run validation matrix
T+15: log/counter sanity review
T+30: announce stable or execute rollback

Simple timelines reduce confusion and split-brain decision making during maintenance windows.

Appendix J: if you only improve three things

For teams overloaded and unable to do everything at once:

enforce source-of-truth policy files
enforce post-change validation matrix
enforce exception owner+expiry metadata

These three controls alone prevent a large share of recurring firewall incidents.

Appendix K: policy readability standard

We introduced a readability standard for long-lived rulesets:

each rule block starts with plain-language purpose comment
each non-obvious match has short rationale
each temporary rule includes owner and review date
each chain has one-sentence scope declaration

Readability was treated as operational requirement, not style preference. Poor readability correlated strongly with slow incident response and unsafe change windows.

Appendix L: recurring validation windows

Beyond change windows, we scheduled quarterly full validation runs across critical flows even without planned policy changes. This caught drift from upstream network changes, service relocations, and stale assumptions that static “it worked months ago” confidence misses.

Periodic validation is cheap insurance for systems that users assume are always available.

It also creates institutional confidence. When teams repeatedly verify expected allow and deny behaviors under controlled conditions, they stop treating firewall policy as fragile magic and start treating it as managed infrastructure. That confidence directly improves change velocity without sacrificing safety.

Appendix M: concise maturity model for iptables operations

We used a four-level maturity model:

Level 1: ad-hoc commands, weak rollback, minimal docs
Level 2: canonical scripts, basic validation, inconsistent ownership
Level 3: source-of-truth with reviews, repeatable deploy, clear ownership
Level 4: full lifecycle governance, routine drills, measurable continuous improvement

Most teams overestimated their level by one tier. Honest scoring helped prioritize the right investments.

One practical side effect of this model was better prioritization conversations with leadership. Instead of arguing in command-level detail, teams could explain maturity gaps in terms of outage risk, change safety, and auditability. That shifted investment decisions from reactive spending after incidents to planned reliability work.

At this depth, iptables stops being “firewall commands” and becomes a full operational system: policy architecture, deployment discipline, observability design, and governance rhythm. Teams that see it this way get long-term reliability. Teams that treat it as occasional command-line maintenance keep paying incident tax.

That is why this chapter is intentionally long: in real environments, iptables competency is not a single trick. It is a collection of repeatable practices that only work together.

For teams carrying legacy debt, the most useful next step is often not another feature, but a discipline sprint: consolidate ownership metadata, prune stale exceptions, rerun validation matrices, and document rollback paths. That work looks mundane and delivers outsized reliability gains. Teams that schedule this work explicitly avoid paying the same outage cost repeatedly. That is one reason mature firewall teams budget for policy hygiene as planned work, not leftover time. Planned hygiene prevents emergency hygiene.

Incident runbook: “site unreachable after firewall change”

A reliable triage order:

verify policy loaded as intended (not partial)
check counters on relevant rules (-v)
confirm service local listening state
confirm route path both directions
packet capture on ingress and egress interfaces
inspect conntrack pressure/timeouts if state anomalies suspected

Do not guess. Follow path evidence.

Incident story: accidental self-lockout

Every team has one.

Change window, remote-only access, policy reload, SSH rule ordered too low, default drop applied first. Session dies. Physical access required.

Post-incident controls:

always keep local console path ready for major firewall edits
apply temporary “keep-admin-path-open” guard rule during risky changes
use timed rollback script in remote-only scenarios

You only need one lockout to respect this forever.

Rule lifecycle governance

Temporary exceptions are unavoidable. Permanent temporary exceptions are operational rot.

Useful lifecycle policy:

every exception has owner + ticket/reference
every exception has review date
stale exceptions auto-flagged in monthly review

Firewall policy quality decays unless you run hygiene loops.

Audit and compliance without theater

Even in small teams, simple audit artifacts help:

exported rule snapshots by date
change log summary with intent
service exposure matrix
deny log trend report

This supports security posture discussion with evidence, not memory battles.

Operational patterns that aged well

From current iptables experience, these patterns hold:

design by traffic intent first
keep chain structure readable
test every change with fixed flow matrix
treat logs as signal design problem
document marks/rules/routes as one system

Tool versions evolve; these habits remain high-value.

A 2006 production starter template (conceptual)

1) Flush and set default policies.
2) Allow loopback and established/related.
3) Allow required admin channels from management ranges only.
4) Allow required public services explicitly.
5) FORWARD policy only on gateway roles.
6) NAT rules only where translation role exists.
7) Logging and final drop with rate control.
8) Persist and reboot-test.

If your team does this consistently, you are ahead of many environments with more expensive hardware.

Incident drill: conntrack pressure under peak traffic

A useful practical drill is controlled conntrack pressure, because many production incidents hide here.

Drill setup:

one gateway role host
representative client load generators
baseline rule set already validated

Drill goal:

detect early warning signs before user-facing collapse.

Typical evidence sequence:

monitor session behavior and latency trends
inspect conntrack table utilization
review drop/log patterns at choke chains
validate that emergency rollback script restores expected behavior quickly

What teams learn from this drill:

rule correctness alone is not enough at peak load
visibility quality determines recovery speed
rollback confidence must be practiced, not assumed

Strong teams also document threshold-based actions, for example:

when conntrack pressure reaches warning level, reduce non-critical published paths temporarily
when pressure reaches critical level, execute predefined emergency profile and communicate status immediately

This sounds operationally heavy and prevents panic edits when real traffic spikes hit.

Most costly outages are not caused by one bad command. They are caused by unpracticed response under pressure. Conntrack drills turn pressure into rehearsed behavior.

Why this chapter in Linux networking history matters

iptables and netfilter made Linux a credible, flexible network edge and service platform across environments that could not afford proprietary firewall stacks at scale.

It democratized serious packet policy.

But it also made one thing obvious:

powerful tooling amplifies both good and bad operational habits.

If your team is disciplined, it scales. If your team is ad-hoc, it fails faster.

Postscript: what long-lived iptables teams learned

The longer a team runs iptables, the clearer one lesson becomes: firewall reliability is mostly operational hygiene over time. The syntax can be learned in days. The discipline takes years: ownership clarity, review quality, repeatable validation, and calm rollback execution. Teams that master those habits handle growth, audits, incidents, and upgrade projects with far less friction. Teams that skip them stay trapped in reactive cycles, regardless of technical talent. That is why this section is intentionally extensive. iptables is not just a firewall tool. It is an operations maturity test.

If you need one practical takeaway from this chapter, keep this one: every firewall change should produce evidence, not just new rules. Evidence is what lets the next operator recover fast when conditions change at 02:00.

Home Router in 2003: Debian Woody, iptables and the Stuff Which Runs

Sun, 02 Mar 2003 00:00:00 +0000

Now the router is in a phase where I trust it.

This is a good feeling. It is not the first excitement feeling from the early SuSE days, and it is also not the hack-pride feeling from the D-channel/syslog trick. It is something else. The machine is simply there. It routes. It resolves. It gives leases. It proxies web. It zaps ads. It survives reboot. It is part of the flat now like the switch or the shelf.

The disk swap from the 486 into the Cyrix box worked. Debian Potato was first on that disk, but by now I moved the system further to Debian Woody. That means kernel 2.4, and now finally iptables instead of ipchains.

The move from Potato to Woody

This is not a dramatic migration like the first Debian step. This one is more calm.

The big practical reason is netfilter and iptables. I want the 2.4 generation now. I want the more modern firewall and NAT setup, and I also want to stay on a current stable Debian instead of freezing forever on Potato.

So now the stack looks like this:

Debian Woody
kernel 2.4
iptables
bind9
dhcpd
Squid
Adzapper
PPPoE on DSL

This is already much more modern feeling than the original SuSE 5.3 plus ISDN phase.

The box itself

The hardware is still the same Cyrix Cx133 box. Beige, boring, a bit dusty, absolutely fine.

With 32 MB RAM it is much happier than in the 8 MB starting phase. This is one of the reasons I am glad I did not keep the 486 as the final router. The 486 was okay for proving the install and services, but the Cyrix with more memory is simply the better place for Squid and general peace.

The Teles card is still physically there for some time after DSL. Then it becomes more and more irrelevant. I keep the old configs around for a while because deleting old working things always feels dangerous. Only much later do I stop caring about the old ISDN remains.

Local services: the boring ones and the useful ones

The router is not only a router anymore. It is the small local infrastructure box.

DHCP

dhcpd does what it should do and I mostly do not think about it anymore. Which is good.

Clients come, they get an address, gateway, DNS, and that is it. If DHCP is broken, everyone notices fast. If it works, nobody says anything. This is one of the purest sysadmin services in the world.

DNS

Now I use bind9, not the old bind8 from the Potato phase. Still forwarding, still simple. I am not suddenly becoming an authority server wizard. I still want a local cache and one place for clients to ask.

What I like is that DNS problems are easier to see now because the line is always on. In the ISDN phase one could confuse line-down issues and DNS issues very easily. With DSL that whole category of confusion is much smaller.

Squid + Adzapper

Squid remains important. Maybe less dramatic than on ISDN, because the DSL line is already much nicer. But the proxy still gives me cache, central control, and with Adzapper it still gives me a better web.

Adzapper is honestly one of my favourite small pieces in the whole setup. It is so unnecessary and so useful at the same time. Web pages are getting heavier and more stupid. Banners everywhere. Counters. Tracking garbage. The proxy says no and shows a small zapped replacement. Perfect.

iptables: finally a nicer firewall world

With Woody and kernel 2.4 I finally move to iptables.

The logic is not new. I already know what I want the firewall to do:

default deny where sensible
allow established traffic back in
let the internal network out
do masquerading on the DSL side
only open specific ports intentionally

But the framework feels cleaner now.

My base script is still very normal:

iptables -F
iptables -t nat -F
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT

This is not a firewall masterpiece. It is just a decent honest firewall for a home router.

And this is enough for me.

Things that changed since DSL

The biggest change after DSL is not only speed. It is mentality.

On ISDN I was always thinking in sessions:

line up
line down
should I bring it up now
did the first request trigger it
will this cost something stupid

On DSL this is gone. The connection is just there. That means I can think much more about service quality and less about connection state.

That is maybe why the router in 2003 feels more complete. The old uplink logic noise is gone, so the rest of the machine can come into focus.

Things that still annoy me

Not all is paradise of course.

Sometimes PPPoE feels a bit ugly. Sometimes package upgrades want a bit too much trust. Sometimes Squid config debugging is still a way to lose an evening. And sometimes I make one firewall typo and then of course I only notice it when I am on the wrong side of the router.

But these are good problems. They are now normal Linux administration problems, not existential connection problems.

Also I still keep too many old notes and backup files. The system is half clean and half archaeology. This is maybe standard student-admin style.

What I use this machine for now

The funny thing is that the router is no longer just about internet access. It is a little confidence machine.

When I want to test something network related, I have a real place for it. When I want to understand a service, I can run it there. When I want to make some small infrastructure experiment, I do not need to imagine it, I can really do it.

This maybe sounds bigger than a home router deserves, but I think many people who did such boxes know exactly this feeling. A machine at the edge of the network teaches a lot because it sits exactly where things become real.

What comes next

I do not think this box is finished. It is only stable enough that now I can be a bit more calm.

Maybe next I write more detailed notes about:

iptables rules I actually keep
Squid and Adzapper config
what I changed from Potato to Woody
maybe some monitoring because right now I still trust too much and measure too little

For now I mostly enjoy that the DSL LED is stable, Debian is on the box, the Cyrix is still alive, and all the little services come up after reboot without drama.

That alone is already very good.

Iptables on TurboVision

Linux Networking Series, Part 7: Ten Years Later - nftables in Production

What changed in daily practice

The old world we came from

Why nftables won mindshare

Example: policy expression quality

The migration trap: compatibility wrappers as comfort blanket

Atomic updates: underrated reliability win

Sets and maps: scaling policy without rule explosions

Incident story: mixed backend confusion

Operational model that works in current production

Relationship with modern routing and observability stacks

The “iptables was simpler” argument

Security posture: did nftables improve it?

Migration playbook (battle-tested)

Appendix: nftables production readiness audit

Category 1: source-of-truth integrity

Category 2: operability

Category 3: governance

Category 4: migration completeness

Appendix: standard post-deploy verification outline

Appendix: monthly improvement loop

Appendix: migration KPI set that actually helped

Appendix: decommission proof package

Appendix: realistic warning

Appendix: shift-handover checklist for firewall operations

Appendix: one-page migration retrospective

Appendix: practical maturity declaration criteria

Final operational reflection

Deep migration chapter: translating intent, not syntax

Rule-object taxonomy that improved governance

CI/CD chapter: firewall policy as release artifact

Drift control chapter

Incident chapter: partial migration pitfall

Incident chapter: set update gone wrong

Audit chapter: proving deprecation of iptables

Team design chapter: policy ownership model

Resilience chapter: recovery drills in nft-era

Documentation chapter: what should always exist

Performance chapter: where teams overfocus

Forward-looking chapter

A decade timeline: how the migration really unfolded

Phase 1 (early years): curiosity and lab adoption

Phase 2: controlled production use

Phase 3: default-by-distribution momentum

Phase 4: governance cleanup

Native nftables design patterns that scale

Translation quality: why naive conversion fails

Atomic changes in real release pipelines

Container and orchestration era interactions

Observability expectations in nft-era operations

Rule naming and policy language discipline

Case study: hosting provider edge modernization

Case study: university network with legacy exceptions

Case study: manufacturing network with strict uptime windows

Runbook upgrades for nftables operations

Compatibility deprecation strategy

Security review benefits from cleaner policy constructs

Performance and correctness tradeoffs in large sets

Organizational anti-patterns still common in 2024

What high-maturity teams do differently

Interop with eBPF-focused environments

A practical 2024 checklist for “iptables truly replaced”

Performance observations from the field

Documentation style for nft-era teams

Cultural lesson: migrations fail socially first

Where nftables sits relative to eBPF era

A hard truth from long production operation

What we should stop doing

What we should keep doing

A practical 30-day hardening plan after migration

Closing this series

Linux Networking Series, Part 5: iptables and Netfilter in Practice

The architectural shift: from command habits to packet path design

Netfilter hooks in plain language

Table responsibilities

Rule of thumb

Built-in chains and operator intent

First design principle: allow known good, deny unknown

Connection tracking changed everything

Why `nftables` won mindshare

Security posture: did `nftables` improve it?

Interaction with `iproute2` and policy routing

What not to do with `iptables`