iptables vs ufw: How They Work Together on Ubuntu

Before and After: Fighting the Firewall Beast

Before: you SSH into your Ubuntu server, start reading about iptables, get hit with words like chains and policies, and five minutes later you’re staring at a command that might lock you out of your own box.

After: you use ufw with a few simple commands, knowing it’s just talking to iptables for you, and you understand enough of what’s happening underneath that you’re not scared of breaking things.

This guide is for anyone running an Ubuntu server (like 14.04 or similar) who is wondering:

What’s the difference between iptables and ufw?
Can I do everything with ufw that I’d do with iptables?
Is it safe to mix them?

Short version based on the source: iptables is the real interface to Netfilter in the Linux kernel. ufw is a friendly front-end that talks to iptables (and its siblings) for you.

Let’s walk through it in a practical way.

Step 1: Understand the Pieces (Kernel, iptables, ufw)

First, you don’t have multiple firewalls fighting each other. You have layers talking to the same engine.

The Linux kernel has a packet filtering mechanism called Netfilter.
The iptables family of commands (iptables, ip6tables, arptables, ebtables) is the interface to Netfilter.
ufw is a front-end / wrapper around those *tables commands.

So when you run ufw allow 22, you’re not bypassing iptables.

ufw is actually generating and managing iptables rules for you. Think of it like this:

Netfilter = engine inside the car
iptables = direct access to the engine with tools and bolts
ufw = dashboard switches that move those tools for you

Knowing this already removes a lot of fear: using ufw is not a “less secure” firewall. It’s just a different way to control the same thing.

Step 2: What ufw Adds on Top of iptables

From the source, ufw isn’t magic; it’s a convenience layer with some nice quality-of-life features.

Unified rules for IPv4 and IPv6

iptables is for IPv4, ip6tables is for IPv6.

With raw commands, you’d need to:

Write a rule in iptables for IPv4
Then another rule in ip6tables for IPv6

ufw lets you write one rule, and it takes care of applying it to IPv4 and IPv6 transparently.

This is especially nice if you’re not living and breathing firewall syntax.

Built-in saving and restoring of rules

With bare iptables, if you reboot and don’t have a proper save/restore mechanism, your rules are gone.

ufw bakes in a framework for saving and restoring rules, so:

You don’t have to maintain your own iptables-save / iptables-restore scripts.
Your rules persist more cleanly across reboots.

This alone makes life easier on small servers and VPS boxes.

Application profiles (grouped rule sets)

ufw also lets applications provide their own rulesets.

That means packages can ship with named rule groups like “OpenSSH”, “Nginx Full”, etc. You can then turn an app’s access on/off as a unit, instead of juggling many individual ports.

The source mentions this explicitly:

This last bit makes it possible to manage specific sets of rules as a unit, meaning that you can turn an application’s access “on” or “off” very easily.

That’s really all that’s going on. ufw is not a separate firewall, it’s a more human-friendly control panel for the *tables commands.

Step 3: Can You Do Everything in ufw That You Can in iptables?

According to the source:

In the end, ufw is simply a wrapper for the *tables commands. You can easily use either to accomplish the same task.

So for normal server use cases:

Allow/deny ports
Limit services
Work with IPv4/IPv6
Turn groups of rules on/off (via app profiles)

…you can absolutely use ufw instead of raw iptables.

The source also says:

If you are more comfortable using ufw, you can use that. If you happen to find some strange edge-case where ufw does not have the functionality you need, an iptables rule can be used to supplement your ufw rules.

So there are rare edge cases where ufw may not expose a complex feature or special rule you want.

In that situation, the suggested pattern is:

Use ufw for 95% of your rules.
Add a specific iptables rule manually for the weird case you need.

But for most small-business servers, WordPress hosts, or personal VPS, you’ll never hit that limit.

Step 4: Safe Workflow – ufw First, iptables Only If Needed

Let’s talk about how to work with them without hurting yourself.

Even though we’re not adding extra facts beyond the source, we can outline a sane process based on what we know:

You know ufw is a wrapper over *tables.
You know both can accomplish the same tasks.
You know you can supplement ufw rules with iptables if there’s an edge case.

So a conservative workflow looks like this:

Choose one primary tool for day-to-day work.
If you like simpler commands and app profiles, make ufw your main interface.
Use ufw for all normal rules.
That’s what it’s designed for: everyday management without needing to think about per-protocol commands.
Only reach for iptables for special cases.
The source literally frames iptables in this scenario as a supplement when ufw doesn’t expose some edge functionality you need.
Avoid constantly editing both in parallel.
Since ufw is writing iptables rules for you, rewriting those same chains by hand without understanding them can cause confusion.

This way, you’re not “mixing two firewalls”, you’re just mostly using one interface (ufw) and occasionally dropping down to a lower level (iptables) when needed.

Step 5: Default Policy: ACCEPT vs DROP (Conceptual Clarity)

The source also touches on default policies, just before the conclusion, and there’s a good conceptual point there:

A chain with the default policy of ACCEPT will contain rules that explicitly drop packets. A chain that defaults to DROP will contain …

Even without the full sentence, the idea is clear:

If a chain’s default is ACCEPT, you usually add explicit DROP rules for what you don’t want.
If a chain’s default is DROP, you usually add explicit ACCEPT rules for what you do want.

This is the classic trade-off:

Default ACCEPT: let most traffic through, block the bad/known stuff.
Default DROP: block everything by default, explicitly allow the good/needed stuff.

ufw is still managing chains and policies behind the scenes via iptables.

You don’t have to write those raw rules yourself, but it helps to understand this:

When you add allow/deny rules in ufw, under the hood it’s manipulating chains and policies in the *tables world.
That’s why ufw can offer you a simple on/off and allow/deny interface while still giving you real firewall behavior.

Step 6: When to Stick to ufw vs When to Drop to iptables

Based strictly on the source, we can outline the decision like this:

Use ufw when:

You want a more approachable interface.
You like having a unified way to handle IPv4 and IPv6.
You want built-in save/restore of firewall rules.
You appreciate apps providing their own grouped firewall profiles so you can toggle them as a unit.
You’re not trying to do something extremely low-level or unusual.

Supplement with iptables when:

You hit a “strange edge-case where ufw does not have the functionality you need” (direct quote from the source).
You’re comfortable with chain/policy management and want full control for that one special case.

And the key reassurance from the source:

You can easily use either to accomplish the same task.

So you’re not missing core firewall capability by using ufw. It’s just a nicer door into the same room.

Simple Mental Model to Remember

Let’s wrap this into a quick mental model you can keep in your head when logging into an Ubuntu 14.04 server.

Netfilter (in the kernel) is the actual firewall engine.
iptables + friends (ip6tables, arptables, ebtables) are the official command-line interfaces to that engine.
ufw is a wrapper/front-end that:
Talks to those *tables commands for you
Helps apply rules to IPv4 and IPv6 without you juggling separate commands
Handles saving/restoring rules
Lets applications ship grouped rules you can toggle on/off as a unit

From the source, both paths get you to the same place: a configured firewall.

So on an Ubuntu server (14.04 included), yes, you can implement what you’d normally do in iptables using ufw for typical scenarios. If you hit some weird case, add an iptables rule as backup.

That’s it. No secret second firewall, no hidden conflict.

If this worked for you, keep CrushEdge handy for the next fix.