How to Configure UFW Firewall on Linux: The Complete Guide

I’ve locked myself out of more servers than I care to admit. Usually at 2 AM. Usually because I enabled a firewall without allowing SSH access first. If you’ve ever stared at a dead terminal connection wondering how you’ll explain this to your boss, this guide is for you.

UFW (Uncomplicated Firewall) is the firewall tool that finally made sense to me after years of wrestling with iptables syntax. It’s built into Ubuntu and Debian systems, and it does exactly what the name suggests—makes firewall management uncomplicated. Let me show you how to use it without shooting yourself in the foot.

What is UFW and Why Should You Care?

UFW is a frontend for iptables, which means it translates simple commands into complex iptables rules behind the scenes. Think of iptables as the engine and UFW as the steering wheel—you get all the power with a much friendlier interface.

Here’s why I switched to UFW years ago: iptables syntax is brutal. A simple rule to allow SSH might look like this in iptables:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT

The equivalent UFW command? Just this:

ufw allow 22

When you’re managing multiple servers and need to make quick changes, that simplicity is a lifesaver. According to Baeldung’s firewall comparison, UFW is specifically designed for host-based firewalls and is perfect for individual servers and VPS setups.

Installing UFW on Linux

Most Ubuntu and Debian systems come with UFW pre-installed. Check if you have it:

ufw version

If you get a version number, you’re good. If not, install it:

sudo apt update
sudo apt install ufw

On other distributions like Fedora or CentOS, you might need to use firewalld instead, but the concepts are similar.

The Golden Rule: Always Allow SSH First

Listen carefully, because this is where people screw up: before you enable UFW, you must allow SSH access. If you’re connected via SSH and you enable the firewall without allowing port 22, you’ll immediately lose your connection. And unlike a local machine where you can just walk over and fix it, a remote server means you’re calling support to get console access.

Here’s the right order:

# First, allow SSH (do this BEFORE enabling UFW)
sudo ufw allow 22/tcp

# Or use the application profile (recommended)
sudo ufw allow OpenSSH

# Now it's safe to enable UFW
sudo ufw enable

If you’ve already set up SSH key authentication, you’re already ahead of the game security-wise. Combining SSH keys with a properly configured firewall is the foundation of server security.

Understanding UFW Default Policies

UFW operates on a default-deny principle, which is exactly what you want for security. Out of the box:

• All incoming connections are denied (unless you explicitly allow them)
• All outgoing connections are allowed (your server can make requests to the internet)

This means your server is locked down by default, and you selectively open only the ports you need. It’s the security equivalent of locking all the doors and only opening specific ones for expected guests.

You can check and modify these defaults:

# View current defaults
sudo ufw status verbose

# Change default policies (rarely needed)
sudo ufw default deny incoming
sudo ufw default allow outgoing

Basic UFW Commands You’ll Use Daily

Let me walk you through the commands I use most often. These cover 90% of what you’ll need.

Checking Firewall Status

Always start by checking what’s currently configured:

sudo ufw status

For more detail:

sudo ufw status verbose

This shows your rules plus the default policies. I run this constantly when troubleshooting connectivity issues, often right after checking which ports are actually listening.

Allowing Common Services

UFW includes application profiles for common services. These are cleaner than specifying port numbers:

# Web server
sudo ufw allow 'Nginx Full'
# or
sudo ufw allow 'Apache Full'

# SSH (we already covered this one)
sudo ufw allow OpenSSH

# MySQL (only if needed)
sudo ufw allow 3306/tcp

See all available application profiles with:

sudo ufw app list

Allowing Specific Ports

Sometimes you need to open a port that doesn’t have a profile:

# Allow specific port
sudo ufw allow 8080/tcp

# Allow port range
sudo ufw allow 6000:6010/tcp

# Allow UDP
sudo ufw allow 53/udp

I use port-specific rules when running custom applications or development servers. Just remember to specify TCP or UDP—they’re different protocols and need separate rules.

Advanced UFW Rules for Real-World Scenarios

Once you’ve got the basics down, you’ll need more sophisticated rules. Here’s where UFW really shines.

Allowing from Specific IP Addresses

This is crucial for securing admin panels or database access:

# Allow from specific IP
sudo ufw allow from 203.0.113.4

# Allow specific IP to specific port
sudo ufw allow from 203.0.113.4 to any port 3306

# Allow entire subnet
sudo ufw allow from 192.168.1.0/24

I use this constantly for database servers—only allow connections from the application servers that need them, not from the entire internet.

Denying Connections

Sometimes you need to explicitly block something:

# Deny from specific IP
sudo ufw deny from 198.51.100.5

# Deny specific port
sudo ufw deny 23/tcp

Combine this with fail2ban for automatic blocking of brute-force attempts. As noted in DigitalOcean’s UFW essentials guide, UFW and fail2ban work excellently together for layered security.

Interface-Specific Rules

If your server has multiple network interfaces, you can write rules for specific interfaces:

# Allow on specific interface
sudo ufw allow in on eth0 to any port 80

This is particularly useful for servers with separate public and private networks.

Managing and Troubleshooting UFW Rules

Eventually you’ll need to modify or remove rules. Here’s how to stay organized.

Viewing Numbered Rules

Get a numbered list of all rules:

sudo ufw status numbered

This shows each rule with a number, which you’ll need for deletion.

Deleting Rules

Two ways to delete rules:

# By number (from numbered list)
sudo ufw delete 3

# By repeating the rule
sudo ufw delete allow 8080/tcp

I prefer the numbered method—it’s clearer and works even if you forgot the exact syntax.

Inserting Rules at Specific Positions

Rule order matters. UFW processes rules from top to bottom:

# Insert at specific position
sudo ufw insert 1 allow from 203.0.113.4

This adds the rule at position 1, making it process first. Useful when you need to prioritize certain rules.

UFW Logging and Monitoring

Enable logging to track what your firewall is doing:

sudo ufw logging on

Logs go to /var/log/ufw.log. Check them when troubleshooting connection issues:

sudo tail -f /var/log/ufw.log

I keep logging on for production servers but disabled for development machines—the logs can get noisy. When something’s not working, the logs often show you exactly which rule is blocking the connection.

Common UFW Mistakes and How to Avoid Them

I’ve made all of these mistakes so you don’t have to.

Forgetting to Enable UFW

Creating rules doesn’t automatically enable the firewall. After setting up your rules:

sudo ufw enable

Verify it’s actually running:

sudo ufw status
# Should show "Status: active"

You can also check the UFW service status with systemctl to confirm it’s enabled at boot.

Not Testing Before Disconnecting

Before disconnecting from SSH, open a second session to test your access. If your rules are wrong, you can fix them from the second session before your first one times out.

Docker Bypassing UFW Rules

This one’s sneaky: Docker modifies iptables directly, potentially bypassing your UFW rules. If you’re running Docker, you need additional configuration to ensure UFW properly controls Docker’s network access. This is beyond basic setup, but be aware it’s a gotcha.

UFW vs iptables: Which Should You Use?

I get asked this constantly. Here’s my take: UFW is iptables—it’s just a friendlier interface. As explained in this Server Fault discussion, whatever you do in UFW ends up as iptables rules.

Use UFW when:

• You want simple, maintainable firewall rules
• You’re managing host-based firewalls on servers
• You value your time and sanity

Stick with iptables when:

• You need extremely complex rule sets
• You’re working with legacy systems
• You enjoy suffering (kidding, mostly)

For 95% of server administrators, UFW is the right choice. According to Hostinger’s 2025 UFW guide, it’s become the standard for Ubuntu server security because it balances power with usability.

Essential Security Practices with UFW

A firewall is just one layer of security. Here’s how to use UFW as part of a comprehensive security strategy:

• Principle of least privilege: Only open ports that are absolutely necessary
• Use application profiles when available: They’re tested and maintained by package maintainers
• Combine with SSH keys: Firewall + key-based auth is far stronger than either alone
• Regular audits: Review your rules monthly and remove anything no longer needed
• Enable logging for production: You can’t troubleshoot what you can’t see
• Test changes in staging first: Don’t experiment on production servers

If you’re managing multiple users on your Linux system, remember that UFW rules apply at the network level, not per-user. Design your rules with that in mind.

Wrapping Up: Your First Steps with UFW

Here’s your practical action plan for setting up UFW right now:

1. Open a second SSH session (your safety net)
2. Allow SSH: sudo ufw allow OpenSSH
3. Allow your other services: sudo ufw allow 'Nginx Full' (or whatever you need)
4. Enable UFW: sudo ufw enable
5. Check status: sudo ufw status verbose
6. Test connectivity from your second session
7. Enable logging: sudo ufw logging on

Firewall management doesn’t have to be complicated or scary. UFW gives you the control you need without the complexity that causes mistakes. Start simple, test thoroughly, and gradually add rules as your needs grow. Your future self—the one who isn’t locked out at 2 AM—will thank you.