Core CS · Computer Networks

Who is allowed across, and who is allowed to listen

Q: A packet arrives. How does the firewall decide which rule applies to it?

The rules are an ordered list read from the top, and the first rule whose constrained fields all match decides the packet. Evaluation stops there and nothing below it is consulted. A rule is an AND across the fields it constrains, and a field written as any always matches, so a rule with fewer constraints is easier to match rather than harder. Be careful not to describe this as longest prefix match: a router picks the most specific entry regardless of where it sits, a firewall picks the topmost match regardless of how specific it is, and reordering the list changes the policy.

Q: What happens to a packet that matches no rule at all?

It is refused by the implicit deny at the end of the list, which is not written anywhere in the config. On a Cisco ACL it terminates every list automatically, which is why an ACL containing only permits blocks everything else. On Linux you set it yourself as the chain policy with iptables -P INPUT DROP , and a policy left as ACCEPT turns your list of permits into decoration. That last rule is what makes the visible rules a set of exceptions rather than a set of suggestions.

Q: What can an application layer or proxy firewall do that a stateful one cannot, and what does it cost?

It terminates the connection and speaks the protocol itself, so it reads the payload rather than only the headers. That lets it block one URL rather than a whole site, permit GET while refusing PUT , block a specific SMTP command, or strip an attachment, none of which a stateful firewall can see. The costs are real: it is much slower because it reassembles and parses every conversation, it needs a separate proxy written for every protocol so anything unusual is unsupported, and to inspect HTTPS it must terminate the TLS session itself, which means its own certificate has to be installed on every client.

Q: Do you DROP or REJECT, and does it matter?

It matters. Drop discards the packet silently and sends nothing back, so the sender waits for a timeout; that slows a port scanner down and gives away less, because a filtered port becomes hard to tell from a dead host. Reject answers, with an ICMP destination unreachable message or a TCP RST, so the sender fails immediately. The usual split is to drop on internet-facing rules and reject on rules facing your own users and applications, because a connection that fails in a millisecond is far easier to debug than one that hangs for thirty seconds.

Q: IPsec transport mode versus tunnel mode, and AH versus ESP?

Transport mode encrypts the payload but keeps the original IP header, so the real addresses stay visible; it is used host to host inside one organisation. Tunnel mode encrypts the entire original packet including its header and prepends a new IPv4 header carrying the two tunnel endpoints, which is what site to site and remote access use and the only one that hides the inner addresses. As for the two protocols, AH authenticates and proves the packet was not altered but does not encrypt anything, and because it protects parts of the IP header it breaks the moment a NAT rewrites an address on the path. ESP encrypts and can authenticate as well, and it is what is actually deployed.

A firewall answers the first question with an ordered list that ends in a refusal you never wrote. A VPN answers the second by putting your packet inside another packet. Both are policy at a boundary, and both come up in the same interview.

Send a packet down a real rule list, stateless and then stateful →

A firewall starts by refusing everything, and you write the exceptions. The rules are read from the top, the first one that matches decides, evaluation stops there, and an implicit deny waits at the bottom for anything that reaches it. A VPN does not punch a hole in that boundary so much as carry it: the original packet is encrypted and wrapped inside a new packet addressed between the two tunnel endpoints, so everything in between sees only the outer header.

01 The idea

A firewall is a list that ends in no

A firewall sits at a boundary between two networks and enforces a policy on every packet that tries to cross it. Usually that boundary is where your network meets the internet, but nothing about the idea requires that. It can sit between the engineering subnet and the finance subnet, or on a single laptop deciding what that one machine will accept. What makes something a firewall is not where it is; it is that traffic has to pass through it and that it has a policy.

The policy starts from one principle, and it is the opposite of what most people assume. Default deny: anything not explicitly permitted is refused. You do not list the traffic you are afraid of and let the rest through. You list the traffic you actually want and refuse the rest. Students almost always describe it the other way round, as blocking bad things, and that instinct has a name too. Default permit, and it loses. To make default permit safe you would have to enumerate every attack that exists and every attack that will be invented next year, and you lose the moment you miss one. To make default deny safe you only have to enumerate the services you run, which is a short, finite list that you already know because you built it.

The second idea is that a firewall can only enforce a rule about a field it can actually read. That single sentence orders the whole family of firewall types. A device that reads only the IP and TCP headers can block a port; it cannot block a word inside a request. A device that reads the payload can block the word, but it has to reconstruct the whole conversation to do it, and that costs speed. Every difference in section 03 comes back to what the device is able to see.

Then the second half of the lesson, which sounds unrelated and is not. Two offices need to exchange private traffic, or one remote worker needs to reach the office network from a hotel. The path between them runs across a network nobody involved controls, and on that path the packets can be read and altered by anyone who handles them. A VPN, a virtual private network, makes that public path behave like a private one. The mechanism is tunnelling, which is encapsulation again, the same idea you met when a segment became the payload of a datagram. The original packet is encrypted and then placed inside a brand new packet whose header carries only the addresses of the two tunnel endpoints. An observer in the middle sees a conversation between two gateways and nothing else. Not the real source, not the real destination, not the port, not the payload.

So the two halves are one idea seen twice. A firewall controls who is allowed to cross a boundary you own. A tunnel extends that boundary across ground you do not own. The firewall decides; the tunnel carries the decision somewhere else.

Default deny is the starting position and the rule list is the set of exceptions to it, read from the top, first match wins, evaluation stops on the match, and an implicit deny catches everything that falls off the end. Tunnelling is the same boundary carried across a network you do not control: encrypt the original packet, wrap it in a new one addressed gateway to gateway, and only the outer header is visible on the way.

Default denyThe position every firewall policy starts from: anything not explicitly permitted is refused. You enumerate the services you run, not the attacks you fear, because the first list is finite and known and the second is neither. The refusal is real even when no rule says so.

First match winsRules are an ordered list read from the top. The first rule whose constrained fields all match the packet decides it, and evaluation stops there. Nothing below is consulted, so the order of the rules is part of the policy, not a formatting choice.

TunnellingEncapsulation used to cross a network you do not control. The original packet becomes the payload of a new packet whose header names only the two tunnel endpoints. Encrypt that payload first and the inner header, with the real addresses in it, is hidden as well.

02 Worked example

One packet, five rules, and the first one that matches

One small office, one rule list, and one packet, and it is the same office and the same list for the rest of the lesson. The inside network is 192.168.1.0/24. The office also runs a public web server at 203.0.113.10. One laptop, 192.168.1.66, has been found with malware on it and the administrator wants it cut off. The five rules that implement all of that are in section 03; here we watch a single packet meet them.

The packet: the quarantined laptop 192.168.1.66 is trying to open an SSH session to an outside host. Source 192.168.1.66, source port 51000, destination 198.51.100.23, destination port 22, protocol TCP. Those five values are the five tuple. A packet filter reads them and the TCP flags, and nothing else at all. Read left to right.

The packet arrivesFive values, and no history. 192.168.1.66:51000 to 198.51.100.23:22, TCP. Evaluation begins at rule 1 and there is nowhere else it could begin.

→

1. ALLOW, and it failsRule 1 permits 192.168.1.0/24 to any destination on TCP 443. The source is inside that block, the protocol is TCP, but the destination port must be 443 and it is 22. One field failing is enough. Move down.

→

2. ALLOW, and it failsRule 2 permits 192.168.1.0/24 on UDP 53. Source still matches. The protocol must be UDP and this packet is TCP, so the rule fails on its second field. Move down.

→

3. DENY, and it matchesRule 3 constrains only the source address: 192.168.1.66, everything else any. That one field matches exactly, and a field left as any cannot fail. Every constrained field matches, so the rule matches. Verdict DENY, and evaluation stops on this line.

→

4 and 5 are never readThree rules were evaluated, not five. The two below were not consulted, were not skipped, and were not overruled. Evaluation ended, and that is the whole difference between an ordered list and a set of conditions.

Three numbers describe that run and they are the first three the console tracks: rules evaluated 3, matching rule 3, verdict DENY. Notice how a rule succeeds. It is an and across the fields it constrains, so every constrained field must match; a field written as any is not a field the rule cares about, and it always matches. That has a consequence worth saying out loud, because it feels backwards: a rule with fewer constraints is easier to match, not harder. Rule 3 constrains one field and matched. Rule 1 constrains three and failed on the third.

Check the one piece of arithmetic before going further, because the whole quarantine depends on it. Is 192.168.1.66 inside 192.168.1.0/24? The /24 says the first 24 bits are the network, so the mask is 255.255.255.0 and the host part is the last 32 − 24 = 8 bits. That block therefore holds 2⁸ = 256 addresses, from 192.168.1.0 to 192.168.1.255, of which the first is the network address and the last the broadcast address, leaving 256 − 2 = 254 usable hosts. The last octet 66 sits inside 0 to 255, so yes, the laptop is inside the block. Hold on to that, because it is about to cause the bug.

Now the highlighted node again, and the reason this example was chosen. Change one field of that packet, the destination port, from 22 to 443, and run it again. Rule 1 permits 192.168.1.0/24 to anywhere on TCP 443. The source is in the block, the protocol is TCP, the destination port is 443. All three constrained fields match, so rule 1 matches and the packet is allowed, after exactly one rule evaluation. The quarantined laptop is browsing the web, and rule 3, which was written to stop precisely that machine doing precisely anything, is never reached. It is not disabled, not wrong and not badly written. It is shadowed: an earlier, broader rule catches the traffic first, so the later rule is unreachable for that traffic and can never fire. This is a real misconfiguration, one that audits are run to find, and it is a favourite examinable trap because the rule list reads correct.

One more thing that is easy to get backwards, and the reason this section spells out the order. In the routing lesson a router matched a destination against its table using longest prefix match: of every entry that matches, the most specific one wins, and where a row physically sits in the table changes nothing. A firewall rule list is not that. It is first match wins: of every rule that matches, the topmost one wins, and specificity is irrelevant. Rule 3 in this list is far more specific than rule 1 and still loses to it, because it is written underneath. Reorder a routing table and nothing changes. Reorder a rule list and you have changed the policy.

03 Mechanics

What each kind of firewall can see, and what a tunnel hides

Three tables, in the order the questions come. First the four kinds of firewall, ordered by capability, because the answer to what are the types of firewall is worth nothing without the two columns that follow. Read the cannot decide column hardest: each row exists because the row above it could not do something.

Type	What it examines	Can decide	Cannot decide	Cost
Packet filter (stateless)	Each packet on its own: source and destination IP, protocol, source and destination port, TCP flags. No memory of any other packet.	Block a port, block a subnet, block traffic to one host, block inbound packets with SYN set and ACK clear.	Whether an arriving packet is a real reply or an unsolicited packet that merely looks like one. Both have source port 443 and the ACK bit set; nothing in either packet says which request it answers.	`fastest` one table walk per packet, no memory used
Stateful inspection	The same fields, plus a state table of the connections it has already seen and permitted.	Everything above, plus: permit this reply because the request that provoked it went out through me. One outbound rule then covers both directions.	Anything inside the payload. A permitted TCP 443 flow may be carrying a file transfer, a chat client or malware, and the firewall cannot tell.	`memory per connection` the table is finite and can be filled
Application layer (proxy)	Terminates the connection and speaks the protocol itself, so it reads the payload: URLs, HTTP methods, SMTP commands, file names.	Block one URL rather than a whole site, block PUT while allowing GET, block an SMTP command, strip an attachment, log what was actually requested.	Any protocol nobody has written a proxy for. And it cannot read encrypted traffic without terminating the TLS session itself, which means installing its certificate on every client.	`slowest` one proxy per protocol, a bottleneck and a single point of failure
Next generation (NGFW)	Stateful inspection and payload inspection in one box, plus two things neither of the rows above has: user identity pulled from the directory, so a rule can name a person or a group rather than an IP address, and an intrusion prevention engine that matches traffic against known attack signatures and drops it.

Why stateless filtering is not merely the weaker option. It is the only thing fast enough to run at line rate on a router with no per-connection memory at all, and it is exactly what a router access control list is. On a link carrying millions of flows there is no table big enough to hold them, so the first, cheapest filter in front of everything else is still stateless. The state table is a resource, and a resource is something an attacker can aim at.

Second, the rule list from section 02, written out in full. Five rules and a sixth that nobody typed.

#	Action	Source	Destination	Proto	Dest port	Intended meaning
1	`ALLOW`	192.168.1.0/24	any	TCP	443	Inside hosts may reach any web server over HTTPS.
2	`ALLOW`	192.168.1.0/24	any	UDP	53	Inside hosts may resolve names.
3	`DENY`	192.168.1.66	any	any	any	The quarantined laptop is cut off entirely. Intended is the word to notice.
4	`ALLOW`	any	203.0.113.10	TCP	80	The public web server may be reached from anywhere.
5	`DENY`	any	203.0.113.10	TCP	22	But nobody reaches its SSH port from outside.
6	`DENY`	any	any	any	any	Implicit. Nobody typed this row. It is the default policy, and it is what makes rows 1 to 5 a list of exceptions instead of a list of suggestions.

Rule 6 is where the marks are. It is not a rule in the file. On a Cisco IOS access list it is the implicit deny any any that terminates every ACL, whether or not you can see it, and it is why an ACL containing only deny statements blocks everything rather than permitting the rest. On Linux you write it yourself as a chain policy, iptables -P INPUT DROP or nft add chain ... policy drop, and forgetting to set it converts your careful list of permits into decoration. If you are asked what happens to a packet that matches no rule, the answer is that it is refused, and the follow-up is by what, and the answer to that is the default policy.

Shadowing, stated once so you can name it in an interview. Rule 3 is shadowed by rule 1 for TCP 443 and by rule 2 for UDP 53. Traffic from 192.168.1.66 on those two services is decided before rule 3 is reached, so the quarantine only bites on everything else. The general form: a rule is shadowed when an earlier rule matches a superset of its traffic with a different action. The fix is always ordering, never wording, and the general principle is that specific rules go above general ones, because the list will not sort them for you the way a routing table would.

DROP or REJECT, and it is a real choice. Refusing a packet has two forms. Drop discards it silently and sends nothing back, so the sender waits for a timeout; a port scanner cannot distinguish a filtered port from a dead host, which slows scanning down and gives away less. Reject answers, with an ICMP destination unreachable message or, for TCP, an RST, so the sender fails immediately. Outward facing rules usually drop; rules facing your own users usually reject, because a connection that fails in a millisecond is much easier to debug than one that hangs for thirty seconds. Answering "they are the same thing" is a lost mark.

NAT is not a firewall. Say this plainly, because the opposite is widely believed. Network address translation exists to let many private addresses share one public address; its job is rewriting headers, and it keeps a translation table only so it knows where to send replies. An unsolicited inbound packet is dropped by a NAT device for a mundane reason: the table has no entry telling it which inside host to give the packet to, so there is nowhere to send it. That is a side effect of not knowing, not an enforced policy. It applies no rules, it inspects nothing, it logs nothing, it does not stop a single thing an inside host chooses to do, and any protocol that arranges an inbound path, such as UPnP or hole punching, walks straight through it. A NAT box with a firewall in it is common; that does not make the NAT the firewall.

Third, the tunnel. A VPN comes in two deployments and the mechanism underneath is the same for both.

Kind	Who the endpoints are	What gets encrypted	What the outer header shows
Site to site	Two gateways, one per office. No software on any user machine, and no user knows the tunnel exists.	The whole original packet, including its IP header.	Gateway to gateway, for example 203.0.113.5 to 198.51.100.9. The real inside addresses are inside the encrypted part.
Remote access	One user device and one gateway. The device runs client software and is given an address on the office network.	The whole original packet, same as above.	The laptop’s public address to the gateway. To the coffee shop network it is one encrypted flow to one address.
IPsec transport mode	Encrypts the payload only and keeps the original IP header. There is no new outer header, so the real addresses are visible. Used host to host inside an organisation, where hiding the addresses is not the point.
IPsec tunnel mode	Encrypts the entire original packet, header and all, and prepends a new IPv4 header of 20 bytes carrying the two tunnel endpoints. This is what site to site and remote access use, and it is the mode that hides the inner addresses.
AH and ESP	AH, IP protocol `51`, authenticates the packet and proves it was not altered, but does not encrypt; because it also covers parts of the IP header it breaks whenever a NAT rewrites an address on the path. ESP, IP protocol `50`, encrypts and can authenticate as well, and is what is actually deployed. Key exchange runs over UDP 500, and NAT traversal wraps ESP in UDP 4500.
SSL or TLS VPN	Runs the tunnel over TLS on TCP 443, the same protocol and the same port as ordinary HTTPS. The name is a leftover: SSL itself was deprecated years ago and every one of these runs TLS. Two consequences: in its clientless form a browser is the client, so nothing has to be installed to reach web applications, and it passes through almost any restrictive network, because a network that blocks it also blocks the web. It pays TLS’s handshake cost on top of TCP’s, one round trip in TLS 1.3 and two in TLS 1.2.

Read the encapsulation as a picture, because the exam question is usually drawn. A host at 10.1.0.7 sends to 10.2.0.9. That packet, header included, is encrypted and becomes the payload of a new packet whose header reads 203.0.113.5 to 198.51.100.9. On the public path there are now two IP headers, one inside the other, and only the outer one is readable. The far gateway strips the outer header, decrypts, and puts the original packet on its own network, where it looks exactly as it did when it left. That is why the two offices behave like one network: the packet that arrives is the packet that was sent.

The cost of the extra header, in bytes. Ethernet’s MTU is 1500 bytes, and the outer IPv4 header takes 20 of them before ESP has added anything of its own. The inner packet therefore has less room than it had before the tunnel existed, and a host that keeps sending 1500-byte packets will produce tunnelled packets that must be fragmented or dropped. That is why tunnel interfaces are configured with an MTU below the physical one, and why "the VPN broke large file uploads but small requests are fine" is a symptom with a specific cause rather than a mystery.

Full tunnel and split tunnel. A remote access client that installs a default route through the tunnel sends every packet up it, including traffic bound for the public internet, which then leaves through the office link and the office firewall. That is a full tunnel. A client configured with routes only for the office prefixes sends office traffic up the tunnel and lets everything else go straight out the local link; that is a split tunnel. The difference is a routing decision on the client and nothing more, and it decides whether the office firewall sees that laptop’s general browsing at all.

Be honest about what a VPN does not do. It protects traffic in transit between the two endpoints, and it changes your apparent location, because the far end is where your traffic now appears from. It does not make you anonymous. The traffic is decrypted at the far endpoint, so whoever runs it sees everything your ISP used to see, and you have moved your trust rather than removed it. It does nothing about cookies, logins or browser fingerprinting, all of which identify you regardless of the address you arrive from. And it does not protect the endpoints themselves: a compromised laptop at one end of a perfectly encrypted tunnel is a compromised laptop with a private path into the office.

05 Cheat sheet

The firewall and VPN answers on one card

Every row is something you can be asked to state in under ten seconds. The right-hand column is the specific wrong answer that gets given, not a general caution.

What they ask	The answer	The trap
The default policy	`default deny: anything not explicitly permitted is refused`	`"block the bad traffic"` — that is default permit, and it loses to anything new
How a rule is selected	`ordered list, top to bottom, first match wins, then stop`	`longest prefix match` — that is the routing table, not a rule list
What decides a packet no rule mentions	`the implicit deny at the end of the list`	Assuming traffic with no rule about it is allowed through.
Is rule order significant	`yes · the order is part of the policy`	Saying the rules are "a set of conditions". Moving one row can flip a verdict.
What a stateless filter cannot do	`tell a real reply from an unsolicited packet with the same fields`	Saying it cannot see ports. It sees ports perfectly well.
What state buys you	`replies are matched to a connection, not to a rule`	`claiming it reads the payload` — that is the proxy, one row down
What a proxy firewall adds	`it terminates the connection and reads the payload`	Forgetting it must terminate TLS, and install its certificate, to see anything.
A rule that never fires	`it is shadowed by an earlier, broader rule`	Adding a deny at the bottom "to be safe". Specific goes above general.
DROP or REJECT	`drop is silent · reject answers with ICMP unreachable or a TCP RST`	`"they are the same"` — one costs the sender a timeout, the other does not
Is NAT a firewall	`no · it rewrites headers, and the inbound drop is a side effect`	Saying NAT protects you. It applies no policy and inspects nothing.
What tunnelling does to a packet	`encrypts it whole and wraps it in a new packet addressed endpoint to endpoint`	Calling a VPN "a private leased line". Nothing is reserved anywhere.
IPsec transport vs tunnel mode	`transport keeps the original IP header · tunnel adds a new 20-byte one`	`swapping them` — tunnel is the one that hides the inner addresses
AH vs ESP	`AH authenticates only, protocol 51 · ESP encrypts, protocol 50`	`"AH encrypts"` — it does not, and it also breaks through NAT
Does a VPN make you anonymous	`no · the provider now sees everything the ISP used to`	Confusing encryption in transit with anonymity. Trust moved, it did not vanish.

The order is the policyTwo lists holding exactly the same five rules in a different order are two different firewalls. Nothing sorts them for you, nothing warns you that a rule has become unreachable, and the list will keep reading correctly long after it has stopped behaving correctly.

A firewall enforces only what it can readEvery difference between a packet filter, a stateful firewall and a proxy is a difference in what the device is able to see. Decide what you need to block first, and the type you need follows from it rather than the other way round.

A tunnel moves the boundary, it does not remove itEncryption protects the packet between the two endpoints and nowhere else. At the far end it is decrypted and handed to a network with its own policy, so the question is never "is it encrypted" but "who is at the other end, and what do they see".

06 Where & why

The rule lists you will actually type

None of this is a teaching abstraction. Every system below implements first match wins and a default policy, and in two of them the stateless and stateful contrast from section 04 is a product decision you make in a dropdown.

Linux · iptables and nftables

The rule list is literally what you type

iptables -P INPUT DROP is rule 6 of section 03, set by hand. -A appends a rule to the bottom and -I inserts it at the top, and that pair of flags is first match wins turned into two commands: use the wrong one and your new deny lands underneath the allow that shadows it. The state table is one line, iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT, and it is deliberately the first rule on almost every Linux server, because most packets are replies and matching them at line 1 is the cheapest possible outcome. -j DROP and -j REJECT are the two refusals. nftables has replaced iptables as the default on Debian and RHEL; nft list ruleset prints the whole policy including the chain policy.

Cisco IOS

Access lists, and the deny you cannot see

A standard ACL matches the source address only; an extended ACL matches the full five tuple, which is why anything resembling section 03 has to be extended. You build the list, then attach it to an interface and a direction with ip access-group 101 in, and a list that is never applied filters nothing at all. Every ACL ends in an implicit deny any any that never appears in the running config, so a list containing only permits blocks everything else and a list containing only denies blocks everything. The classic exam trap is that on a numbered ACL a new statement is appended, so the deny you have added sits below the permit that shadows it and the list has to be rewritten. Named ACLs let you insert by sequence number instead.

AWS VPC

Both halves of section 04, sold as two products

A security group is stateful and allow-only: there is no deny rule, the absence of a permit is the deny, there is no ordering because every rule is evaluated and any match permits, and the reply to a permitted outbound flow returns with no inbound rule written for it. A network ACL is stateless: rules are numbered, evaluated in ascending order, first match wins, explicit deny exists, and because nothing remembers the outbound request you must write the return direction yourself, including the ephemeral destination port range the reply will land on. Being asked to explain why a change worked on one and not on the other is a common interview and a common outage.

WireGuard · OpenVPN

Two tunnels with opposite design goals

WireGuard has been in the mainline Linux kernel since 5.6, runs over UDP on port 51820 by convention, and identifies each peer by a public key rather than a certificate; its whole configuration is a list of peers and the addresses each is allowed to use, which is a default-deny rule list wearing different clothes. OpenVPN runs over UDP 1194 by default and can be moved onto TCP 443 instead, where it is hard to distinguish from ordinary HTTPS and therefore passes through networks that permit only web traffic. That option is an honest illustration of the whole topic: a tunnel’s job is partly to be indistinguishable, which is exactly what the proxy firewall in section 03 exists to defeat.

Both halves of this lesson are the same question asked from two sides. A firewall asks what am I willing to let across this boundary, and answers it with an ordered list that refuses by default. A VPN asks how do I keep that boundary meaningful when the path runs through somebody else’s network, and answers it by wrapping the packet so the path cannot read it. Neither one secures anything on its own: the firewall enforces only the policy you wrote, and the tunnel protects only the middle, never the two ends.

07 Interview questions

What they ask about boundaries

This pair of topics is where a networking interview turns into a security interview, and the questions escalate the same way every time: define it, then say how a rule is chosen, then say what your answer cannot do. Give the mechanism rather than the label. Anyone can say "stateful"; the mark is for saying what is in the table and who put it there.

What is a firewall, and what does default deny mean?

A firewall enforces a policy on traffic crossing a boundary between two networks, and it works only because that traffic has no other way through. Its policy starts from default deny: anything not explicitly permitted is refused, so you write down the traffic you want rather than the traffic you fear. The reason is asymmetry of effort. Under default permit you have to enumerate every attack that exists and every one invented next year and you lose the first time you miss one; under default deny you enumerate the services you actually run, which is a short list you already know.

A packet arrives. How does the firewall decide which rule applies to it?

The rules are an ordered list read from the top, and the first rule whose constrained fields all match decides the packet. Evaluation stops there and nothing below it is consulted. A rule is an AND across the fields it constrains, and a field written as any always matches, so a rule with fewer constraints is easier to match rather than harder. Be careful not to describe this as longest prefix match: a router picks the most specific entry regardless of where it sits, a firewall picks the topmost match regardless of how specific it is, and reordering the list changes the policy.

What happens to a packet that matches no rule at all?

It is refused by the implicit deny at the end of the list, which is not written anywhere in the config. On a Cisco ACL it terminates every list automatically, which is why an ACL containing only permits blocks everything else. On Linux you set it yourself as the chain policy with iptables -P INPUT DROP, and a policy left as ACCEPT turns your list of permits into decoration. That last rule is what makes the visible rules a set of exceptions rather than a set of suggestions.

Stateless packet filter versus stateful firewall. What is the actual difference?

A stateless packet filter examines each packet entirely on its own: addresses, protocol, ports, TCP flags, and no memory of any other packet. A stateful firewall keeps a state table of the connections it has already seen and permitted, so an arriving packet is first checked against that table and accepted if it belongs to a known connection. The consequence is that policy for a connection is written once, in the direction the connection was opened, and the return traffic is matched to the connection rather than to any rule. The stateless filter has no way to know whether a packet is a reply, because a genuine reply and a forged packet with the same fields are identical on the wire.

What can an application layer or proxy firewall do that a stateful one cannot, and what does it cost?

It terminates the connection and speaks the protocol itself, so it reads the payload rather than only the headers. That lets it block one URL rather than a whole site, permit GET while refusing PUT, block a specific SMTP command, or strip an attachment, none of which a stateful firewall can see. The costs are real: it is much slower because it reassembles and parses every conversation, it needs a separate proxy written for every protocol so anything unusual is unsupported, and to inspect HTTPS it must terminate the TLS session itself, which means its own certificate has to be installed on every client.

What happens when a stateful firewall runs out of room in its state table?

New connections start failing while existing ones keep working, which is a confusing symptom because the device is up, the link is fine and half the traffic is normal. The table is finite memory, so it is a resource an attacker can aim at: flood it with connection attempts and legitimate users cannot get an entry. Firewalls defend with idle timeouts, and the timeouts differ by protocol because TCP has a FIN to close on while UDP has nothing, so UDP entries can only be aged out on a timer. This is exactly why a cheap stateless filter still sits in front of expensive stateful ones on a high volume link.

Do you DROP or REJECT, and does it matter?

It matters. Drop discards the packet silently and sends nothing back, so the sender waits for a timeout; that slows a port scanner down and gives away less, because a filtered port becomes hard to tell from a dead host. Reject answers, with an ICMP destination unreachable message or a TCP RST, so the sender fails immediately. The usual split is to drop on internet-facing rules and reject on rules facing your own users and applications, because a connection that fails in a millisecond is far easier to debug than one that hangs for thirty seconds.

Is NAT a firewall?

No. NAT exists so that many private addresses can share one public address, and its job is rewriting headers. It keeps a translation table only so that it knows which inside host a reply belongs to, and an unsolicited inbound packet is dropped for the mundane reason that there is no entry telling it where to send that packet. That is a side effect of not knowing, not an enforced policy: it applies no rules, inspects nothing, logs nothing, restricts nothing an inside host chooses to do, and any protocol that arranges an inbound mapping walks through it. Most home routers do contain a real firewall as well, which is where the confusion comes from.

What is a VPN, and what does tunnelling actually do to a packet?

A VPN lets two parties exchange private traffic across a network neither of them controls. The mechanism is tunnelling, which is encapsulation: the original packet is encrypted and then carried as the payload of a brand new packet whose header names only the two tunnel endpoints. Anybody handling it on the public path sees a conversation between two gateways and nothing else, and the far endpoint strips the outer header, decrypts, and puts the original packet onto its own network unchanged. That is why two offices joined this way behave like one network, and it is also why nothing is reserved anywhere. A VPN is not a leased line.

IPsec transport mode versus tunnel mode, and AH versus ESP?

Transport mode encrypts the payload but keeps the original IP header, so the real addresses stay visible; it is used host to host inside one organisation. Tunnel mode encrypts the entire original packet including its header and prepends a new IPv4 header carrying the two tunnel endpoints, which is what site to site and remote access use and the only one that hides the inner addresses. As for the two protocols, AH authenticates and proves the packet was not altered but does not encrypt anything, and because it protects parts of the IP header it breaks the moment a NAT rewrites an address on the path. ESP encrypts and can authenticate as well, and it is what is actually deployed.

Site to site or remote access, and where does an SSL or TLS VPN fit?

Hard

A remote worker connects to the office over a remote access VPN whose client installs a default route through the tunnel, and the office enforces the section 03 rule list on its internet boundary. The worker then opens a video call to a third party on the public internet. Trace where those packets travel, say which rule list they are evaluated against and how many times, then say what changes if the client is configured for split tunnelling instead, and give one security argument in favour of each configuration.

Follow-up

The two configurations differ by one entry in a routing table on the laptop, and that one entry decides whether the office firewall is a security control for this worker at all or merely a detour.

Show the hint

A tunnel is a route before it is anything else. Work out what the client’s routing table says about the video call’s destination address, and everything else in the question follows from that one answer.