What Is a Firewall? Types, Functions, and How They Protect You

A firewall is a network security device or software that monitors and controls incoming and outgoing network traffic based on predetermined security rules. It acts as a barrier between a trusted internal network and untrusted external networks (like the internet).

Think of it as a security guard at a building entrance — it checks every person (packet) trying to enter or leave and decides whether to allow or block them based on a set of rules. Firewalls are one of the most fundamental and essential components of network security.

Firewalls examine network traffic and apply rules to determine what to allow through. These rules can be based on:

• IP addresses: Allow or block traffic from specific source or destination IPs.
• Port numbers: Allow web traffic on port 80/443 but block everything else.
• Protocols: Allow TCP and UDP but block ICMP (ping).
• Application data: Deep packet inspection can examine the actual content of packets.
• Connection state: Track whether a packet is part of an established connection or a new, unsolicited request.

Firewall rules are processed in order. When a packet matches a rule, the associated action (allow, deny, or drop) is applied. If no rule matches, a default policy decides the outcome — most firewalls default to "deny all" (block everything not explicitly allowed).

Packet Filtering Firewalls: The simplest type. They inspect each packet individually and compare it against rules based on IP address, port, and protocol. They're fast but don't track connection state, making them vulnerable to certain attacks.

Stateful Inspection Firewalls: These track the state of active connections. A packet is only allowed in if it belongs to an established, legitimate connection. This is much more secure than basic packet filtering and is the standard for most modern firewalls.

Proxy Firewalls (Application-Level Gateways): These act as an intermediary between the user and the internet. All traffic passes through the proxy, which can inspect and filter application-layer data. They provide strong security but can introduce latency.

Next-Generation Firewalls (NGFW): Combine traditional firewall capabilities with advanced features like deep packet inspection, intrusion prevention (IPS), TLS/SSL inspection, application awareness, and threat intelligence feeds. Products from Palo Alto, Fortinet, and Cisco fall into this category.

Web Application Firewalls (WAF): Specifically designed to protect web applications by filtering HTTP/HTTPS traffic. They protect against SQL injection, cross-site scripting (XSS), and other web attacks. Cloudflare, AWS WAF, and ModSecurity are popular examples.

Hardware firewalls are dedicated physical appliances that sit between your network and the internet. They're used by businesses to protect entire networks. Examples include Cisco ASA, Fortinet FortiGate, and Palo Alto Networks devices.

Software firewalls run on individual computers or servers. Your operating system includes one: Windows Firewall, macOS's application firewall, and Linux's iptables/nftables. They protect the specific device they run on.

Cloud firewalls are firewall-as-a-service solutions that protect cloud infrastructure. AWS Security Groups, Azure Network Security Groups, and Google Cloud Firewall Rules are examples.

For home users, your router's built-in firewall combined with your OS software firewall provides adequate protection. Businesses typically use a combination of hardware firewalls at the network perimeter and software firewalls on individual servers.

• Default deny policy: Block all traffic by default and only allow what's explicitly needed. This is more secure than allowing everything and trying to block specific threats.
• Keep rules minimal and clean: Remove unused rules regularly. Complex rulesets lead to misconfigurations and security gaps.
• Enable logging: Log all blocked and allowed traffic for security monitoring and incident investigation.
• Segment your network: Use firewalls to separate different parts of your network (e.g., isolate your database servers from public-facing web servers).
• Keep firmware updated: Firewall vendors regularly patch security vulnerabilities in their software.
• Test your firewall: Use port scanning tools like LookMyIP's Port Checker to verify that only intended ports are open and accessible.

Firewall theory is straightforward. Firewall practice is a series of specific mistakes that everyone makes once.

Default deny, then permit what you need. A ruleset that ends in "allow everything not explicitly denied" is a list of things you happened to think of. Reverse it: deny by default and enumerate what is permitted. The ruleset becomes a positive statement of what the machine is for.

A minimal, correct ufw configuration for a web server:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80,443/tcp
sudo ufw enable

Note the order. Adding the SSH rule before enabling the firewall is the difference between a working server and a locked-out one. Locking yourself out of a remote machine with a firewall rule is close to a rite of passage; do the rules in the right order and it does not happen.

Restrict management ports by source. SSH open to the entire internet will receive thousands of brute-force attempts daily. Even with key-only authentication, restricting the source is free:

sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp

Do not block all ICMP. The reflex to "block ping" causes more problems than it prevents. ICMP type 3 code 4 carries Path MTU Discovery, and blocking it produces connections that establish normally and then hang when a large response arrives — a failure mode that takes days to diagnose. On IPv6, blocking ICMPv6 breaks address resolution outright. Rate-limit echo requests if you must; do not drop the protocol.

Verify from the outside. A rule you believe is active and one that is actually filtering traffic are different claims. Check from an external vantage point with the open port checker, because a local ufw status tells you what the machine intends, not what the network in front of it does.

A packet arriving at a cloud server typically passes four independent filters, and troubleshooting goes badly when you are looking at the wrong one.

Provider edge / DDoS scrubbing. Some traffic never reaches your account at all.

Cloud security groups. AWS security groups, Azure NSGs and GCP firewall rules operate before the traffic reaches the instance. Security groups are stateful and allow-only — there is no deny rule, so a permission granted anywhere in an attached group wins.

Network ACLs. On AWS these sit at the subnet level, are stateless, and *do* support deny rules. Being stateless is the trap: allowing inbound traffic on port 443 is not enough, because the outbound response uses an ephemeral source port that also needs an explicit rule.

Host firewall. ufw, firewalld, iptables/nftables or Windows Defender Firewall on the machine itself.

The diagnostic sequence that saves the most time is to work outward. Confirm the service is listening at all:

sudo ss -tlnp | grep :443

If it is bound to 127.0.0.1 rather than 0.0.0.0 or ::, no firewall change will ever help — the service is only accepting local connections, and this is the single most common cause of "the port is open but nothing connects".

Then test locally, then from another host inside the network, then from the internet. The first step that fails identifies the layer at fault.

One further subtlety on containers: Docker writes its own iptables rules and publishing a port with -p 8080:80 bypasses ufw entirely. A server that appears firewalled can be exposing every published container port to the internet. Bind to localhost explicitly (-p 127.0.0.1:8080:80) when a container should not be publicly reachable.

Firewalls are a perimeter control, and perimeter controls have well-understood limits. Being clear about them prevents a false sense of security.

They do not inspect encrypted traffic. With the overwhelming majority of web traffic now over TLS, a packet filter sees a destination address and a port and nothing else. Inspecting content requires TLS interception, which means installing a certificate authority on every client and accepting the significant privacy and operational costs that come with it.

They do not stop attacks over permitted ports. SQL injection, cross-site scripting and deserialisation flaws all arrive over port 443, which your firewall must allow for the site to function. Application-layer attacks need application-layer defences — a WAF, input validation, and secure coding.

They do not stop outbound-initiated compromise. A user opening a malicious attachment establishes an outbound connection that the firewall permits by default. Nearly all modern malware is designed around this, using ordinary HTTPS to a legitimate-looking host for command and control. Outbound filtering helps, but is difficult to maintain without breaking legitimate software.

They do not help against credential theft. A stolen password used from an approved location over an approved port looks exactly like a legitimate login.

They provide no protection inside the perimeter. A flat network with a strong edge firewall gives an attacker who gets in — through a phishing email, a contractor's laptop, an exposed IoT device — free movement to everything. This is the observation that produced network segmentation and zero-trust architectures, where every connection is authenticated regardless of where it originates.

The practical conclusion is not that firewalls are unimportant. It is that a firewall is one layer, and a security posture built on that layer alone fails to the first attacker who arrives over a port you had to leave open.

Do I need a software firewall if my router has one?

For a laptop, yes — the router protects you at home and does nothing on public Wi-Fi, where the threat is other devices on the same network. For a desktop that never leaves the house, the router's NAT provides most of the practical benefit, though a host firewall still limits damage if another device on the LAN is compromised.

Is NAT a firewall?

No, though it accidentally behaves like one. NAT blocks unsolicited inbound connections because it has no translation entry to map them to, which is a side effect of address translation rather than a security policy. It applies no rules, logs nothing, and offers no protection on IPv6, where hosts have globally routable addresses and NAT is not used. Networks moving to IPv6 need an actual stateful firewall.

Should I disable the Windows firewall when installing software?

No. If an installer requires it, that is a strong signal to be suspicious. Legitimate software either works within the firewall or prompts for a specific rule. Disabling it entirely to solve one application's problem leaves every other service exposed.

What is the difference between DROP and REJECT?

REJECT sends an ICMP unreachable message, so the client fails immediately and knows the port is closed. DROP silently discards the packet, so the client waits for a timeout. DROP is marginally better against scanners because it slows enumeration; REJECT is much better for internal services because it turns a 30-second hang into an instant, comprehensible error. Use REJECT internally and DROP at the internet edge.

How do I know if my firewall is working?

Test from outside the network. Run the port checker against your public address and confirm that only the ports you intend are reachable. A local rule listing shows configuration, not effect.