Deep Dive into Firewall Technologies: Packet Filtering, Stateful Inspection, and Application Gateways

There is a story that helps explain why firewalls exist, and it begins not with computers, but with a fire. In the 1800s, builders discovered that if they constructed a thick wall of stone or brick between sections of a building, a fire starting in one room could be stopped before it spread to the rest of the structure. The wall did not prevent the fire from starting. It simply stopped it from going further. Engineers who later worked on the early internet borrowed this idea. When they needed to describe a system that stopped dangerous traffic from spreading from the open internet into a private network, they called it a firewall. The name has stuck ever since. Today we are going to explore that concept deeply. We will look at three generations of firewall technology, understand how each one works, learn why each one was invented, and discover the specific problems each one solves. Along the way, we will return again and again to an analogy that makes this technical subject concrete and human. We will imagine that your computer network is a medieval castle, and that the various firewall technologies are different kinds of gatekeepers standing at the entrance to that castle. By the end of this lesson, you will not just understand what these technologies do. You will understand why they exist, why they matter, and how they changed the way humans protect information. Let us begin at the beginning. Before firewalls existed, computer networks were remarkably open. In the early days of the internet, which grew out of a research network called ARPANET, the people using it were mostly scientists, engineers, and academics at universities and government laboratories. Trust was the operating assumption. The network was small, the users were known to each other, and malicious attacks were not a significant concern. Data moved freely between computers, and there was no system in place to stop one computer from sending harmful instructions to another. As the internet grew through the 1980s and began connecting businesses and eventually ordinary people, this openness became a serious problem. Networks began to be attacked. Data was stolen. Systems were broken into. The people building and managing these networks realized they needed a way to separate the dangerous outside world from the valuable resources inside their own systems. They needed a gatekeeper. The first gatekeepers they invented were simple. The later ones became remarkably sophisticated. Let us meet them in the order they were created. Before we can understand any of these technologies, we need to understand a single fundamental concept: what is a data packet? When you send an email, or load a webpage, or stream a video, the information does not travel across the internet as one complete, whole piece. Instead, it is broken into small chunks called packets. Think of it this way. Suppose you want to mail a very large book to a friend in another city. Instead of trying to send the whole book in one enormous parcel, you tear out the pages, put each group of pages into a separate envelope, and number the envelopes so your friend knows the order. Your friend receives all the envelopes and reassembles the book on the other end. Data packets work on exactly this principle. Each packet has two parts. The first part is called the header. This is like the outside of the envelope. It contains addressing information, such as where the packet is coming from, where it is going, what type of content it carries, and what numbered place it holds in the larger sequence. The second part is called the payload. This is the actual content, the pages of the book inside the envelope. This distinction between the header and the payload is absolutely central to everything that follows, so keep it firmly in mind. Now, we also need to understand one more concept before we go further. Computers communicate using numbered doorways called ports. A port is not a physical thing. It is a logical, software-defined channel that a computer uses to organize different types of traffic. Your computer might be receiving email on one channel, loading a webpage on another, and listening to music on a third, all at the same time. Port numbers allow the computer to keep these conversations separate and organized. By convention, certain port numbers are associated with certain types of traffic. Port 80 is traditionally used for web browsing using a system called HTTP. Port 443 is used for secure web browsing using HTTPS. Port 25 is used for sending email. Think of port numbers like the different departments in a large post office building. Letters for the accounts department go to window seven. Letters for customer service go to window twelve. The address on the envelope tells the postal worker where to send it. With those two concepts established, packets and ports, we are ready to meet the first generation of firewalls. The first type is called a packet-filtering firewall, and it emerged in the late 1980s. Engineers at a company called Digital Equipment Corporation, commonly known as DEC, were among the first to develop and refine this approach. A researcher named Jeff Mogul contributed significantly to the early thinking in this area. The idea is elegantly simple. Every packet that tries to enter or leave the network must pass through the firewall. The firewall reads the header of each packet, the outside of the envelope, and compares what it finds there against a list of rules. This list of rules is called an Access Control List, which is often shortened to ACL. Think of an ACL as a set of instructions like this: allow packets coming from this address going to that address using this port. Deny everything else. The firewall does not read the content of the packet. It does not open the envelope and read the letter inside. It only looks at the addressing information on the outside. Based on what it sees there, it makes a single binary decision: allow this packet through, or drop it. Let us return to our castle. The packet-filtering firewall is like a guard standing at the castle gate who has been given a very specific checklist. The checklist might say: allow anyone arriving from the Kingdom of Northland, heading to the marketplace in the eastern quarter, traveling on the main road. Everyone else should be turned away. The guard does not ask the travelers what they are carrying. He does not know their faces or remember seeing them before. He checks their declared origin and their stated destination against his list, makes a decision, and moves on to the next person in line. This approach has real strengths. Because the guard is only glancing at a document and checking it against a list, he can process an enormous number of travelers very quickly. Packet-filtering firewalls are fast. They require very little computing power to operate. They are inexpensive to run. Because of these qualities, packet filtering became, and largely remains, a standard feature built into almost every network router in the world. A router is the device that directs traffic between different networks, and having basic packet filtering built into it means that even without a dedicated firewall device, a network has some baseline level of protection. However, our castle guard has serious limitations, and those limitations expose a fundamental problem with this approach. The guard has no memory. Each traveler who arrives is a stranger, regardless of whether they came through the gate five minutes ago. The guard does not remember the merchant who left the castle this morning to visit the market in the neighboring town. When that same merchant returns in the afternoon, the guard does not recognize them. He only knows whether the arriving person's stated origin and destination match the checklist. In network terms, this is called being stateless. The word stateless means the firewall has no awareness of the state or condition of ongoing conversations. It treats every single packet as an entirely independent event. It has no concept of whether this packet is part of a conversation that your own computer started, or whether it is an unsolicited, potentially hostile packet arriving out of nowhere. This creates a severe vulnerability. Consider a type of attack called IP spoofing. IP stands for Internet Protocol, and your IP address is essentially your computer's address on the internet, the equivalent of your home address on an envelope. Spoofing means faking. In an IP spoofing attack, a malicious sender fakes the return address on their packets. They make their packets appear to come from a trusted source, perhaps the address of your bank's server, or a trusted partner company's computer. Because the packet-filtering firewall only looks at the header and has no memory, it sees the trusted source address and lets the packet through, completely unaware that the address has been fabricated. Furthermore, the guard cannot know what is inside the envelope. If the rule says allow web traffic on port 80, the firewall will allow all traffic on port 80, whether that traffic is an innocent webpage or a malicious program disguised as a webpage. The content is invisible to it. These weaknesses made it clear that a smarter approach was needed. By the early 1990s, that smarter approach arrived. The second generation of firewall technology is called stateful inspection. The word stateful is the key. It means the firewall now has state, which means it has awareness and memory of what is happening in ongoing connections. It no longer treats each packet as an isolated event. Instead, it understands context. The man most directly responsible for bringing this technology to the commercial world was Gil Shwed, a co-founder of an Israeli company called Check Point Software Technologies. In 1993, his company released a product called FireWall-1, which was the first commercially successful stateful inspection firewall. Shwed's contribution was significant enough that the technology was patented. FireWall-1 changed the network security industry profoundly. Here is how stateful inspection works. The firewall maintains a special record called a state table. Think of a table as a living, constantly updated list. When your computer initiates a conversation with a server on the internet, perhaps when you type a web address into your browser, the firewall notes this outgoing request in the state table. It records the details of this conversation: which computer on your network started it, what external server it contacted, what port number was used, and the precise stage or state of the conversation. Now, when the external server sends a reply back toward your network, the firewall does not just check whether the reply's header matches the rules. It also checks the state table. It asks: is this packet a legitimate reply to a conversation that was already established? If the answer is yes, the packet is allowed through. If a packet arrives claiming to be a reply but there is no corresponding entry in the state table, the firewall knows something is wrong. Nobody inside the network started that conversation. This is suspicious, and the packet is dropped. To understand why this matters, we need to briefly understand how computers establish a connection. When two computers want to talk to each other using the most common internet communication method, called TCP (which stands for Transmission Control Protocol), they perform a ritual called a three-way handshake. Think of it as a formal greeting. Computer A sends a signal called SYN, which essentially means I want to start a conversation. The server B responds with SYN-ACK, which means I heard you, and I am ready. Then Computer A sends ACK, which means I received your confirmation, and the conversation begins. The stateful firewall tracks this handshake. It knows whether a connection is in the process of being established, fully established, or being closed down. This understanding of connection state gives it a dramatically more accurate picture of what is happening on the network. Back to our castle. Our new guard is no longer just using a checklist. He now has a logbook. When a messenger leaves the castle heading east to visit an ally, the guard writes in the logbook: messenger named Thomas departed at noon heading to Lord Bradford's estate, using the eastern road. When a rider returns claiming to bring a reply from Lord Bradford for Thomas, the guard checks the logbook. He finds Thomas's entry. The timing and details match. He opens the gate. But if a stranger arrives at midnight claiming to carry a reply for someone named Thomas, and there is no entry for Thomas in the logbook, the guard is immediately suspicious. He turns the stranger away. This approach closes the main vulnerability of packet filtering. IP spoofing attacks are far less effective against a stateful firewall because the attacker cannot easily fake being the reply to a conversation that never took place. Scanning attacks, where an attacker probes a network by sending packets to see which ports respond, are also much easier to detect and block because the firewall recognizes these unsolicited probes as having no corresponding state in its table. Stateful inspection also remains fast. It is more demanding on the computer's processor than simple packet filtering, because maintaining and checking the state table takes work. But it does not need to read the actual content of the packets, which keeps it relatively efficient. However, stateful inspection still has a critical blind spot: the payload. The content of the packets, the actual letter inside the envelope, remains invisible to it. The firewall might confirm that a packet is a legitimate part of a conversation your browser started with a trusted website. But if the content of that conversation contains a virus, or malicious code disguised as normal web data, the stateful firewall cannot see it. It watches the conversation happen without understanding what is being said. And there is another problem. The state table, the firewall's logbook, is also a vulnerability. An attacker who knows the firewall relies on its state table can try to fill that table with rubbish. This is done through an attack called a SYN flood. The attacker sends thousands or millions of SYN packets, those initial I want to start a conversation signals, from fake addresses, to the firewall. The firewall dutifully records each one in the state table, waiting for the conversation to continue. But the conversations never continue, because the source addresses are fake. The state table fills up. When legitimate users try to establish connections, the firewall has no room left to record them. The legitimate connections are refused. The firewall is effectively crippled, not by being defeated, but by being overwhelmed. This type of attack is called a Denial of Service, or DoS, attack. It does not break into your network. It simply stops your network from working. Still, stateful inspection was a massive leap forward from packet filtering, and it became the dominant firewall technology for much of the 1990s. Yet the need for even deeper understanding of traffic continued to grow, and that need brought us to the third generation. The third type is called an Application Layer Gateway, and it is also commonly called a proxy firewall. The word proxy means a person or thing acting on behalf of another. In everyday life, if you give someone your legal power to sign documents for you while you are travelling, you have given them proxy. A proxy firewall acts as the go-between, or the intermediary, in every network conversation. A fascinating figure in the history of this technology is Marcus Ranum, a pioneering computer security engineer who, in the early 1990s, developed a set of freely available software tools called the Firewall Toolkit, often abbreviated as FWTK. Ranum was a major advocate for the principle that the safest connection between a dangerous outside world and a protected inside network was no direct connection at all. Here is how a proxy firewall works. When a computer on your network, say your laptop, wants to visit a website, it does not connect directly to that website's server. Instead, it connects to the firewall. The firewall receives the request, inspects it completely, and then, if the request is legitimate and permitted, the firewall itself creates a brand new, separate connection to the external website server. The external server sends its response back to the firewall. The firewall inspects that response completely, and then, if it is safe, passes the content along to your laptop. Notice what this means. There is never a direct connection between your laptop and the outside world. The firewall sits in the middle, terminates both sides of every conversation, and acts as the sole intermediary. The external web server never even learns your laptop's actual address. It only knows the firewall's address. The castle analogy here is vivid. This is no longer just a guard with a checklist or a guard with a logbook. This is a highly educated and extremely careful chamberlain. When a merchant arrives at the castle gate with a package for the lord inside, the chamberlain takes the package from the merchant. The merchant waits outside. The chamberlain goes inside, opens the package carefully, examines every item in it, checks that nothing is hidden or dangerous, and if everything is acceptable, places the items on a clean tray and delivers them to the lord. The lord never touches anything that came directly from the merchant's hands. Everything has been received, inspected, and re-presented by the chamberlain. Because the proxy firewall operates at what is called the Application Layer, meaning it understands the specific language of applications, it can do things the other two types of firewalls cannot. Consider email, which uses a protocol called SMTP, meaning Simple Mail Transfer Protocol. An SMTP proxy can look inside the email, check attachments for viruses, verify that the sender address is not forged, inspect the content for spam, and even block emails that contain certain types of files. It does not just know that an email was sent. It understands what is inside it. Similarly, an HTTP proxy, which handles web traffic, can read the actual content of webpages and web requests. It can block requests to specific URLs. It can look at the commands being sent and block certain types of commands entirely. For example, in web communication there are different commands for different actions. A GET command retrieves a page. A PUT command uploads data. A DELETE command removes data. An HTTP proxy can be configured to block PUT and DELETE commands, limiting what users can do on certain sites even if they are allowed to view them. This level of granularity, meaning the ability to make very specific and detailed decisions, is the great power of application layer gateways. However, this power comes at a significant cost. Remember, the chamberlain must receive every package, open it, inspect it item by item, pack it again on a fresh tray, and then deliver it. This takes time and effort. In network terms, this means processing power and time. An application proxy firewall introduces noticeably more delay, or latency, into connections. It is slower. It also requires more computing resources to run. And there is a further limitation: the chamberlain is trained to handle specific types of packages. If a new kind of package arrives that the chamberlain has never been trained to inspect, perhaps an unusual foreign container, the chamberlain cannot properly evaluate it. In network terms, a proxy firewall requires a specific, purpose-built proxy program for each application protocol it needs to handle. If no proxy exists for a particular application, the firewall simply cannot process it intelligently. Often, that application must be blocked entirely. This limitation made application layer gateways less practical as the internet became increasingly complex and the number of applications multiplied. You cannot build a custom chamberlain for every new type of merchant that appears. Let us now stand back and look at all three generations together, because seeing them side by side reveals something important about the nature of security trade-offs. The packet-filtering firewall is like a fast, inexpensive basic lock. It keeps out casual intruders, costs very little, and works almost instantly. But a determined attacker can pick it. The stateful inspection firewall is like a better lock combined with a doorbell camera. It is more secure, keeps a record of who has been expected, and stops many more sophisticated attacks. It costs more and is slightly slower, but the improvement in security is substantial. The application layer gateway is like a full security check with metal detectors and bag searches. It is the most thorough and the most secure, but it takes time, requires trained staff, and may occasionally create frustration when it does not recognize a harmless but unusual item. No single approach is best in all situations. The right choice depends on what you are protecting, how much risk you face, what resources you have, and how much delay you can tolerate. Now, here is something important to understand about the modern world. In practice, when you encounter a firewall today, it is almost certainly not one of these three types in its pure original form. The firewalls that organizations use today are called Next-Generation Firewalls, which are often abbreviated as NGFW. This term was popularized around 2009 by an influential technology research company called Gartner, which produces widely-read reports about the technology industry. A Next-Generation Firewall is a combination of all three foundational technologies, plus several additional capabilities. At its core, it uses stateful inspection to track connections efficiently. On top of that, it adds a technique called Deep Packet Inspection, or DPI, which means it examines the payload, the actual content of packets, as they flow through, rather than only checking headers or requiring a full proxy connection. It typically includes an Intrusion Prevention System, often called IPS, which means it actively monitors traffic for known patterns of attack and blocks them in real time. And it adds Application Awareness, which means it can recognize specific software applications by their behavior patterns, regardless of which port number they use, and apply rules to those specific applications. For instance, a modern firewall might be configured to allow employees to use the corporate sales software but block them from accessing social media, and it can enforce this not by looking at port numbers, but by actually recognizing the signature of those applications in the network traffic. However, even the most advanced next-generation firewalls face new and growing challenges that security experts continue to debate seriously. One of the most significant challenges involves encryption. When you visit a secure website, the address begins with HTTPS rather than HTTP. The S stands for Secure. The content of your communication with that website is encrypted, which means it is scrambled in a way that only you and the website can unscramble. This is enormously important for privacy and security. It protects your banking details, your passwords, your private messages. But it also creates a problem for firewalls. If a firewall relies on reading the content of packets to identify threats, and all the content is scrambled, the firewall is blinded. Today, the vast majority of internet traffic is encrypted. This means that any firewall that wants to inspect content must first decrypt the traffic, inspect it, and then re-encrypt it before passing it along. This process, called SSL/TLS Inspection, is computationally expensive. It slows things down significantly. It also raises genuine privacy concerns, because the firewall is essentially reading everything that passes through it, including sensitive personal and financial information. Organizations must decide how to balance thorough security inspection against the privacy of their users and the performance of their network. Another profound debate involves the very concept of the network perimeter. For decades, the underlying assumption of firewall design has been that there is an inside and an outside. Your network is the inside, the castle. The internet is the outside, the dangerous world. The firewall guards the gate. But increasingly, this model does not reflect reality. Employees access company systems from home, from coffee shops, from airplanes, on personal devices. Company data lives in cloud services run by companies like Amazon, Microsoft, and Google, on servers that are physically and logically outside any castle wall. Applications that employees use daily, like email and document software, exist entirely in these external cloud environments. When your data is everywhere and your employees are everywhere, the idea of a single defensible castle wall starts to seem outdated. Many security experts argue for an approach called Zero Trust, a term that captures the idea that no device, user, or connection should be trusted simply because it is on the inside of the network. Under Zero Trust principles, every access request, whether it comes from inside the building or from a laptop in another country, must be verified and authenticated every time. Security is enforced not primarily at the network edge but at each individual application and piece of data. Defenders of traditional firewalls argue that this does not mean firewalls become irrelevant. It means they become one important layer among many, rather than the single line of defense. Most security professionals today agree that defense in depth, meaning multiple overlapping layers of security, is the most resilient approach. There is one final detail that rewards careful thought. We have spoken about attackers trying to get past firewalls. But what about threats that start inside the castle? A dishonest guard, a corrupt merchant who bribed his way in, an employee who deliberately installs malicious software from inside the network. Firewalls are designed primarily to control traffic at the boundary between networks. They are poorly suited to detecting attacks that originate from inside the network itself. This is sometimes called the insider threat problem, and it is one of the ways in which the castle analogy, useful as it is, has real limitations. A castle gate that perfectly blocks all external invaders is powerless if the treasury is being robbed by someone who already lives inside the walls. Addressing insider threats requires a different set of tools: monitoring systems, access controls, logging, behavioral analysis, and a culture of security awareness among employees. Let us now draw together everything we have covered. We began with the simple, original idea of a firewall: a barrier that separates a trusted network from an untrusted one, just as a firewall in a building separates sections so that fire cannot spread. We learned about data packets, the small chunks into which all internet data is divided, and the distinction between the header, which carries addressing information, and the payload, which carries the actual content. We explored packet-filtering firewalls, the first generation, which operate by checking the header of each packet against a fixed set of rules, called an Access Control List. They are fast, cheap, and simple, but stateless, meaning they have no memory and cannot understand context. They are vulnerable to IP spoofing and cannot inspect the content of packets. We then examined stateful inspection firewalls, which added the crucial innovation of the state table, a dynamic record of all active connections. By tracking the state of every conversation, these firewalls could detect packets that did not belong to any established, legitimate connection. Gil Shwed and Check Point's FireWall-1 brought this technology to commercial success in 1993. Stateful firewalls are more secure than packet filters but can be overwhelmed by SYN flood attacks and still cannot inspect packet payloads. We studied application layer gateways, or proxy firewalls, which operate as full intermediaries, terminating both sides of every connection and inspecting the complete content at the application level. Developed in part by figures like Marcus Ranum, they offer the highest security granularity but at the cost of significant performance overhead and limited support for newer applications. We saw how these three technologies were combined and extended into Next-Generation Firewalls, which add deep packet inspection, intrusion prevention, and application awareness to create integrated security platforms. And we considered the continuing challenges that make network security an evolving discipline rather than a solved problem: the difficulty of inspecting encrypted traffic, the changing nature of the network perimeter as cloud computing and mobile work become standard, and the inherent limitations of boundary-focused security in a world where threats can also originate from within. The history of firewalls is, at its core, a history of an arms race between those who build defenses and those who try to defeat them. Each generation of firewall technology was created because clever attackers found ways around the previous generation. And each new generation, in turn, revealed new limitations that demanded further innovation. This dynamic is not unique to network security. It is the nature of defense everywhere. The people who best understand how defenses work are always both the builders and the breakers, and that is why deep technical knowledge, of the kind you have developed in this lesson, is the indispensable foundation of good security thinking.