How Does a Firewall Work? Types, Rules & Best Practices

You spin up a fresh VPS, deploy something, and within minutes, the auth log fills with login attempts from IPs you've never heard of. That's not a targeted attack — it's just the background radiation of the public internet. Bots scan every reachable address constantly. The thing standing between that noise and your services is a firewall, and most people who run one couldn't actually explain what it does beyond "it blocks stuff."

So let's fix that. This covers how a firewall works, the types worth knowing about, how rules are evaluated, and how to pick one that matches your setup instead of whatever you saw on a vendor comparison chart.

What Is a Firewall and How Does It Work?

A firewall is a network security device that monitors incoming and outgoing network traffic and decides what to allow or block based on a set of predefined rules. It sits between your internal network and external networks — the public internet, mostly — and acts as the first line of defense, letting legitimate traffic through and dropping malicious traffic before it reaches anything that matters.

Key Mechanisms

A firewall filters traffic using one or more of these methods:

• Packet Filtering — inspects individual data packets against rules for source IP, destination IP, port, and protocol. Fast, simple, and stateless.
• Stateful Inspection — tracks the state of active connections in a state table and makes decisions based on connection context, not just isolated packets — the modern baseline.
• Proxy Service — terminates connections at the application layer (Layer 7), reading and filtering protocols like HTTP, FTP, and DNS on behalf of the internal network.
• Next-Generation Firewall (NGFW) — combines stateful inspection with deep packet inspection, application awareness, and integrated intrusion prevention.

Core Functions

Regardless of type, every firewall does three things:

• Traffic Monitoring — examines incoming and outgoing traffic against its rule set in real time.
• Access Control — permits or denies connections based on source, destination, port, and protocol.
• Content Filtering — blocks access to specific sites, services, or content categories according to policy.

Firewalls come as hardware or software. Hardware firewalls are dedicated appliances that protect an entire network at the perimeter and handle high throughput. Software firewalls (including host-based firewalls) run on individual devices and filter traffic for that one host. Most real-world setups use both — a hardware firewall at the edge, and software firewalls on each machine. On a Linux VPS, that software firewall is usually iptables or nftables fronted by ufw.

Types of Firewalls

Firewall types differ in what layer of the OSI model they operate at, how they track connections, and how deeply they inspect traffic. Here's what's actually in use.

Packet Filtering Firewall

A packet filtering firewall operates at the network layer (Layer 3) and inspects each data packet in isolation against an access control list. It filters on four parameters: source IP, destination IP addresses, ports, and protocol (TCP, UDP, ICMP). It doesn't track connection state — every packet is judged on its own, and previously accepted connections aren't remembered.

This makes packet filtering firewalls fast and cheap to run, but limited. They can't read application content, so they can't tell a legitimate HTTP request from a malicious one on the same port. Rules are maintained by hand, which is manageable on a small network and miserable on a large one.

Stateful Inspection Firewall

A stateful firewall tracks the state of every connection in a state table. When a packet arrives, the firewall checks whether it belongs to an established, related, or new connection — and decides accordingly. If you allowed an outbound request, the matching inbound reply is permitted automatically, without a separate rule.

This is the modern standard. It still filters on IP, port, and protocol as packet filtering does, but the state table means it understands traffic in context rather than packet by packet. On Linux, this is exactly what iptables -m conntrack --ctstate ESTABLISHED,RELATED does — it accepts return traffic for connections you initiated and drops unsolicited inbound traffic.

Proxy Firewall

A proxy firewall (application-layer firewall, Layer 7) sits as an intermediary between your internal network and external networks. It terminates the incoming connection, inspects the full application-layer payload — HTTP, FTP, DNS — and opens a separate connection to the destination on your behalf. Nothing talks directly to your internal hosts.

Because it reads application protocols, a proxy firewall defends against application-layer attacks that packet filtering can't see. The tradeoff is that terminating and re-establishing every connection adds latency, and occasionally it flags harmless traffic, causing delays.

Next-Generation Firewall (NGFW)

An NGFW takes traditional firewall capabilities (stateful inspection, NAT, VPN support) and layers on deep packet inspection, URL filtering, threat intelligence, and application awareness. The difference from traditional firewalls is that an NGFW can tell which application is generating traffic, not just which port it's using, and can apply policy at that level (allow Slack, block BitTorrent, both over 443).

NGFW isn't a single feature; it's a bundle of technologies under one name, designed so each component covers the others' blind spots.

Web Application Firewall (WAF)

A WAF protects a specific web application or API rather than a whole network. It inspects HTTP/HTTPS requests for application-layer attacks — SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF) — and blocks malicious payloads before they reach your application code.

If you run a public-facing web server or API, a WAF is effectively mandatory. A network firewall will happily pass a SQL injection attempt because, at the packet level, it's just a valid HTTPS request. The WAF is the layer that reads the request body and notices the ' OR 1=1--.

Virtual Firewall

A virtual firewall is a software firewall deployed as a virtual appliance instead of physical hardware. It runs on hypervisors like VMware ESXi, KVM, or Hyper-V, or in public cloud environments such as AWS, Azure, and GCP. It does everything a hardware firewall does (like stateful inspection and NGFW features), but scales with your virtualized infrastructure instead of being bolted to a rack.

For anyone running workloads on a VPS, this is the relevant model. is*hosting VPS plans run on KVM virtualization, so you control firewall configuration at the OS level on every node — there is no upstream filtering you can't see into.

Cloud Firewall / Cloud-Native Firewall

A cloud firewall protects traffic in cloud environments and is delivered as a managed service, often called Firewall as a Service (FWaaS). You don't manage hardware; you manage policy.

A cloud-native firewall goes further: it's built for cloud-scale operation, with automatic scaling, multi-tenant isolation, and elastic security that grows and shrinks with your traffic. When your traffic triples during a launch, a cloud-native firewall scales to match without you provisioning anything.

If you're deploying across regions, the firewall layer needs to live where your workloads do. With VPS nodes in 40+ locations, you build per-node firewall rules close to each deployment instead of routing everything through one chokepoint.

Container Firewall

A container firewall secures containerized environments — Docker and Kubernetes — at the pod and namespace level rather than the host level. Traditional firewalls assume relatively static hosts with stable IPs. Containers don't work that way; they're created and destroyed constantly, and their IPs are ephemeral.

A container firewall enforces policy based on labels, service identity, and namespaces, so a rule like "the frontend pod may talk to the API pod but nothing else" survives containers being rescheduled across nodes. For anyone running a Kubernetes cluster or a Docker Compose stack on a VPS, this is the layer that controls east-west traffic between services — something a perimeter firewall never sees.

Hardware Firewalls vs. Software Firewalls

They're layers, so don't treat them as competitors. Hardware firewalls handle the perimeter, and software firewalls handle each host. Run both for defense in depth.

Unified Threat Management (UTM)

A UTM appliance bundles stateful inspection, intrusion prevention, and antivirus into a single device with one management interface. The appeal is simplicity: one box, one console, one vendor, instead of stitching together separate products.

UTM suits small and mid-size businesses that need solid coverage without a dedicated security team. The tradeoff against an enterprise-grade NGFW is depth — UTM trades some granular control for ease of management.

How Firewalls Work: The Filtering Process

When a packet hits a firewall, it goes through an ordered process. Understanding it explains why the rule order matters so much.

1. Rule Examination. The firewall compares the packet against its rule list, top to bottom, checking source, destination, port, and protocol.
2. Methodology Application. It applies its filtering method — packet filtering, stateful lookup against the state table, or full application-layer inspection — depending on type.
3. Content Analysis. For stateful and NGFW-class firewalls, the payload is inspected; deep packet inspection reads packet contents, not just headers.
4. Decision Execution. The firewall acts on the first matching rule and stops. If the packet matches a block rule, it's dropped; if it matches an allow rule, it passes. This is why specific rules go above general ones.
5. Logging. The action is recorded. Logs are where you spot attack patterns, debug why something's being dropped, and feed audits.
6. Continuous Rule Update. Rules are revised as threats change and as you add or remove services. A firewall ruleset is never "done."

Firewall Rules and Policies

Firewall rules tell the firewall how to handle connection attempts. Every firewall, regardless of type, filters on the same core parameters.

• Source. Where the connection originates — an IP address or range.
• Destination. Where it's headed, expressed as destination IP addresses and ports.
• Contents. What the connection is trying to send (visible only to firewalls that inspect application-layer content).
• Protocol Packets. The "language" of the connection. Across the internet and within subnets, that's overwhelmingly TCP/IP.
• Ports. A sublayer of each host. Ports are how the firewall distinguishes SSH (22) from HTTP (80) from HTTPS (443) on the same IP.

Rules are evaluated in order, and the first match wins. If traffic matches the top rule, no other rule is checked. If it matches nothing, a properly configured firewall blocks it by default. So security rules go specific-first, general-last.

Worked example. You want to allow all HTTP traffic except from 100.100.1.1:

1. Block — deny HTTP from 100.100.1.1 (specific — placed first)
2. Allow — permit all HTTP (general — placed last)

Reverse the order, and the allow rule matches first, the block never fires, and 100.100.1.1 gets through.

Deep Packet Inspection

Deep packet inspection (DPI) examines the actual contents of a data packet (the payload), not just the header. Basic packet filtering reads the envelope: source, destination, and port. DPI opens the envelope and reads the letter.

That difference is what lets DPI do things packet inspection can't: detect malicious code hidden inside otherwise valid traffic, perform URL filtering, and enforce application-level control. It's the core capability behind NGFWs and the reason they can block a specific application while allowing others on the same port. The cost is processing overhead — reading every payload takes more CPU than checking a header, which is why DPI throughput is a real spec to check, not a checkbox.

Implementing Firewalls in Different Environments

The right firewall setup depends on where your network lives.

Corporate Networks

Layered by default: a hardware firewall or NGFW at the perimeter, host-based firewalls on endpoints, and often segmented internal zones so a breach in one area doesn't reach the rest.

Home Networks

Usually a single software firewall or the firewall built into the router's firmware. For most home use, antivirus plus the router firewall is enough.

Cloud Environments

In cloud environments, the firewall is software-defined and often delivered as Firewall as a Service. You define security groups and policies; the provider enforces them. The advantage is elasticity — policy scales with your instances.

Container Environments

Containerized workloads need policy at the pod and namespace level, enforced by a container firewall, because IPs are ephemeral and perimeter rules can't track services that move between nodes.

If you're standing up firewall rules on a new server, our server-side security guide walks through the first-boot hardening steps — SSH keys, ufw configuration, and locking down the defaults before anything is exposed.

Threat Intelligence and Advanced Security Features

Modern firewalls pull in live data about what's attacking the rest of the world and act on it.

Threat Intelligence

Threat intelligence feeds give a firewall real-time updates about emerging threats: malicious IPs, known-bad domains, and active exploit signatures. Instead of waiting for an attack to match a hand-written rule, the firewall blocks sources already flagged elsewhere.

Intrusion Detection and Prevention (IDPS)

An IDPS monitors the network for threat patterns, then logs and blocks them. It checks traffic against known attack signatures and watches for anomalous behavior, protecting infrastructure and sensitive data while helping meet compliance requirements.

VPN Integration

Many firewalls integrate VPN support for secure remote access. A firewall and a VPN solve different problems — the firewall controls what reaches your network, the VPN encrypts the connection and protects data in transit — and they work well together.

AI-Powered Firewalls

Newer firewalls apply machine learning to traffic analysis, flagging behavior that doesn't match a known signature but deviates from normal patterns. They're useful against novel attacks, but not a replacement for sane rule configuration.

How to Choose a Firewall for Your Business

Skip the vendor matrix. Start from your actual constraints.

Bandwidth Requirements

Your firewall has to keep up with your traffic at peak, not average. A firewall that bottlenecks at line rate is worse than useless; it becomes the slow part of your stack.

Firewall Type Selection

Match the type to the threat. Public web app? You need a WAF. Multi-region cloud deployment? Cloud-native. Kubernetes cluster? Container firewall. A single hardened VPS? Host-based stateful filtering covers most of it.

Performance and Scalability

Estimate your bandwidth needs three years out, then pick something which handles that comfortably. Replacing a firewall every other year because you guessed wrong is its own kind of expensive.

NGFW Capabilities

If you're evaluating an NGFW, the features that matter are decryption, deep packet inspection, content filtering, sandboxing, and secure remote access. Buy the ones you'll use; ignore the spec-sheet padding.

Single vs. Multi-Vendor

One vendor simplifies management and support, especially on a shared OS. Multi-vendor adds flexibility but also complexity. It's only worth it if you standardize on common APIs and open standards.

Firewall Best Practices

The firewall is only as good as its configuration. Three areas matter most.

Configuring Firewall Rules

• Default deny. Block everything, then explicitly allow only what you need. The opposite — allow-by-default — means you're patching holes forever.
• Least privilege. Grant the minimum access required for each service to function. The database doesn't need to accept connections from the public internet.
• Order rules specific-first. As shown above, the first match wins. Put exceptions above the general rules they modify.

Regular Updates and Patches

Keep firewall software patched so it can recognize and block new threats. An unpatched firewall is running on yesterday's threat picture.

Monitoring and Auditing

• Log events and review them — logs are how you spot patterns and reconstruct incidents.
• Run regular vulnerability audits.
• Use change control for rule changes, so every modification is tracked and reversible.
• Periodically prune unused rules to cut processing overhead and reduce mistakes.

If you're securing something higher-stakes (like a blockchain node) these basics are the foundation, but the exposure is different; our blockchain node security guide covers the additional hardening that workload needs.

Where the Firewall Runs

A firewall protects what you put behind it, and that starts with where your server lives. On a VPS, you own the host-level firewall — iptables, nftables, ufw, your call — with full root access and no upstream filtering you can't inspect.