Firewall basics

In Firewalls you met the firewall as a device: the security desk between your network and the internet. This lesson opens the security desk's rule book. You will learn how rules are written, how the firewall checks a packet against them, and the most important idea of all: how a stateful firewall lets replies back in without letting strangers in.

💡 In simple terms: the firewall has a list of "who may go where". It reads the list from the top, does what the first matching line says, and turns away anyone who is not on the list. It also keeps a guest book of conversations already in progress, so people coming back to a conversation don't need to be checked again.

What a firewall policy is

A firewall policy (also called a rule base or rule table) is the ordered list of rules a firewall follows. Each rule describes some traffic and says what to do with it. A rule normally has these parts:

The firewall takes these facts from the packet's headers: the addresses from the IP header and the ports from the TCP or UDP header (see Port numbers and sockets).

Why rules are needed

A router forwards any packet it has a route for. It never asks whether the packet should be delivered. Rules add that question. They let an organisation write down, in a form a machine can enforce, which conversations are part of normal business and which are not. The goal is to allow the traffic people need and nothing more. This is the idea of least privilege, explained in Basic network security.

An example rule table

Here is a small office firewall. The inside network is 192.168.10.0/24, and a public web server sits in a DMZ (a separate zone for public-facing servers) at 172.16.1.10. Remember it: every example below uses it.

Notice there is no rule for the replies from websites or from the DNS server. On a stateful firewall you don't need one. That is the subject of the second half of this lesson.

How a firewall checks a packet, step by step

First match wins

Most firewalls stop at the first rule that matches, not the best or most specific one. So the order of rules is part of the policy. Imagine someone adds "Deny inside → any, any service" as a new rule at the top of the table. Rules 1 and 2 are still there, but no packet ever reaches them. Every user loses the internet, even though the "allow web" rule looks fine.

💡 A good habit: specific rules at the top, broad rules at the bottom, and the implicit deny last of all.

Implicit deny

Below the last rule you wrote is one you didn't write: deny everything. It is called the implicit deny (or default deny). It means a firewall starts from "nothing is allowed", and every rule is an exception. This is much safer than the opposite approach ("allow everything, block the bad things"), because nobody can list every bad thing in advance.

⚠️ Some firewalls hide the implicit deny from the rule list, and many don't log it unless you ask. If you can't find the rule that blocked something, it was probably the implicit deny. Many administrators add an explicit "deny any any, log" as their last rule just to see these drops.

Allowed and denied traffic: worked examples

Run some packets through the rule table above. Each line is the first packet of a new conversation.

Rule 5 is interesting. Without it, SMTP would still be blocked by the implicit deny. The explicit deny exists so that every attempt is logged: a PC trying to send email directly is a strong hint that it is infected.

Sessions: the firewall's memory

A session (or connection) is one conversation between two programs, such as your browser talking to a web server. It is identified by five facts, the 5-tuple: source IP, destination IP, protocol, source port and destination port. A stateful firewall keeps a state table (also called a session table or connection table) with one line per session it has allowed.

For TCP, the firewall follows the real connection states: it sees the SYN, SYN-ACK and ACK, and removes the entry after the FIN or RST that closes the connection. UDP has no connection, so the firewall pretends it does: it pairs a request with its reply by address and port, and forgets the pair after a short idle timeout. Timeouts above are typical values; every vendor picks its own.

Stateless vs. stateful inspection

This is the key difference between an old-style packet filter and a modern firewall. Both use rule tables. What differs is how they deal with return traffic: the replies to a conversation that started inside.

Stateless (packet filtering)

A stateless firewall has no memory. It checks every packet against the rules as if it had never seen anything before. A reply from a web server is just another packet arriving from the internet, so it is blocked unless a rule allows it.

1. The PC 192.168.10.11 sends a SYN from port 51514 to 203.0.113.10:443. Rule 1 allows it.
2. The web server replies from 203.0.113.10:443 to 192.168.10.11:51514.
3. The firewall checks the reply against the rules. No rule allows traffic from the internet to the inside. The implicit deny drops it.
4. The website never loads.

To fix this, the administrator must add a reverse rule like "allow TCP from any address, source port 443, to the inside, ports 1024–65535". That is the range the PC might pick its temporary source port from. Now the reply gets in, but so does any packet an attacker sends from source port 443 to almost any port on any inside PC. The firewall can't tell a real reply from a fake one, because it doesn't remember what was sent.

Stateless filters are still used where speed matters more than detail, for example simple access lists on routers and switches. Some can check the TCP flags ("only allow inbound packets with the ACK flag set"), which helps a little, but they still cannot match a reply to a real request.

Stateful inspection

A stateful firewall remembers. When it allows the first packet of a conversation, it writes a line in its state table. Every later packet is checked against that table first.

Putting the two side by side:

Zones: inside, outside and DMZ

Writing rules for individual interfaces gets messy. Most firewalls group interfaces into zones and write rules between zones. Each zone has a trust level, and a sensible default policy for each direction:

Zones are the firewall's side of a wider design idea: splitting a network into parts with different trust levels. That is covered fully in Network segmentation.

Host firewalls and network firewalls

Everything above applies to both kinds. A network firewall is a device on the path that protects everything behind it. A host firewall is software on one computer (Windows Defender Firewall, ufw or nftables on Linux, the macOS application firewall) that protects only that computer, but does so wherever it goes. Host firewalls are stateful too, and most default to "deny incoming, allow outgoing".

A packet must be allowed by every firewall on its path. That is a common cause of confusion: the network team opens a port, and it still fails because of the host firewall on the server.

Drop or reject?

A deny rule can do one of two things:

• Drop: silently throw the packet away. The sender waits, retries and finally times out. Scanners learn nothing.
• Reject: throw it away and answer: a TCP RST, or an ICMP "destination unreachable (administratively prohibited)" message (see ICMP). The sender fails at once.

Internet-facing rules usually drop. Internal rules sometimes reject, so that users get a quick error instead of a long wait.

Logging

A firewall can write a log entry for allowed connections, denied packets, or both. Logs answer two questions: "why doesn't this work?" and "who tried to get in?". A log entry normally holds the time, the action, the 5-tuple, the interface or zone, and the rule that matched.

$ sudo grep 'UFW BLOCK' /var/log/ufw.log | tail -2
Oct  5 09:14:02 web1 kernel: [86412.553201] [UFW BLOCK] IN=eth0 OUT= MAC=02:00:00:00:00:aa:02:00:00:00:00:01:08:00 SRC=198.51.100.66 DST=172.16.1.10 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=40312 DF PROTO=TCP SPT=50122 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0
Oct  5 09:14:05 web1 kernel: [86415.561877] [UFW BLOCK] IN=eth0 OUT= MAC=02:00:00:00:00:aa:02:00:00:00:00:01:08:00 SRC=198.51.100.66 DST=172.16.1.10 LEN=60 TOS=0x00 PREC=0x00 TTL=52 ID=40313 DF PROTO=TCP SPT=50123 DPT=3389 WINDOW=64240 RES=0x00 SYN URGP=0

💡 Logging every allowed packet would fill the disk quickly. A common balance is: log denied traffic, log new connections on important rules (like rule 3 and rule 4), and send the logs to a central server with Syslog so they survive if the firewall is attacked. Correct time from NTP matters too: logs from different devices can only be compared if their clocks agree.

What happens when the firewall gets it wrong

Troubleshooting and useful commands

1. Test the exact port, not just ping. Ping uses ICMP and tells you nothing about TCP 443.
2. Check the logs on every firewall on the path, including the host firewall on the destination.
3. Find the rule that should match, and check nothing above it matches first.
4. Look at the state table to see whether the session was created at all.

PS C:\> Test-NetConnection 172.16.1.10 -Port 443
ComputerName     : 172.16.1.10
RemoteAddress    : 172.16.1.10
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.10.11
TcpTestSucceeded : True

C:\> netsh advfirewall firewall show rule name="Remote Desktop - User Mode (TCP-In)"
Rule Name:                            Remote Desktop - User Mode (TCP-In)
----------------------------------------------------------------------
Enabled:                              No
Direction:                            In
Profiles:                             Domain,Private,Public
Grouping:                             Remote Desktop
LocalIP:                              Any
RemoteIP:                             Any
Protocol:                             TCP
LocalPort:                            3389
RemotePort:                           Any
Edge traversal:                       No
Action:                               Allow
Ok.

$ sudo conntrack -L -p tcp --dport 443
tcp      6 431987 ESTABLISHED src=192.168.10.11 dst=203.0.113.10 sport=51514 dport=443 src=203.0.113.10 dst=192.168.10.11 sport=443 dport=51514 [ASSURED] mark=0 use=1
conntrack v1.4.6 (conntrack-tools): 1 flow entries have been shown.

From outside your network, the Port Checker shows whether a public port is reachable through your edge firewall.

Common mistakes

• Writing return rules on a stateful firewall. They aren't needed, and a broad "allow inbound from port 443" rule opens a real hole.
• Using "any" when you mean one address. Rule 4 names one IT PC, not the whole inside network.
• Forgetting rule order. A new rule added at the top can silently override everything below it.
• Not logging denies. Then nobody can tell what the implicit deny is blocking.
• Never cleaning up. Old rules for retired servers pile up; every one is a door someone might reuse.
• Assuming outbound is harmless. Malware "phones home" with outbound connections; outbound rules (like rule 5) catch some of it.

Knowledge check

Where to go next

Firewalls control who can connect. To protect data as it crosses networks you don't control, the next tool is encryption in a tunnel: VPN basics. For how zones grow into a whole network design, read Network segmentation. Edge firewalls almost always perform NAT as well, which changes the addresses you see in their logs.