# Screened subnet

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/screened-subnet

## Quick definition

A screened subnet is a network setup that adds an extra layer of security by placing a middle network between your safe internal network and the dangerous internet. Two firewalls control what traffic can move between these zones. This middle network is often called a DMZ, and it holds public-facing services like web servers. The design makes it much harder for attackers to reach your private data.

## Simple meaning

Imagine your home has a front door and a back door. A simple firewall is like having just one strong lock on the front door. That is better than nothing, but if someone picks that lock, they are inside your whole house. Now imagine you build a secure vestibule or mudroom between your front door and the rest of your house. You lock the outside door, and you also lock the inside door. If a delivery person needs to drop off a package, they can only enter the mudroom, not your living room. The screened subnet is that mudroom. It is a separate, isolated network zone that sits between the internet (outside) and your internal network (inside). Public-facing servers, like your company's website or email server, live inside this screened subnet. If an attacker compromises the web server, they are only in the mudroom. They still have to get past a second firewall to reach your internal network, which contains databases, employee computers, and sensitive data. This two-layer defense is the core idea. The screened subnet uses two firewalls. The external firewall connects to the internet and only allows traffic to the screened subnet for specific services, like web traffic to a web server. The internal firewall connects the screened subnet to the internal network and only allows traffic that has been authorized, perhaps a web server requesting data from an internal database. There are variations. Some architectures use a single firewall with three network interfaces: one for the internet, one for the screened subnet, and one for the internal network. This is called a three-legged firewall. But the principle is the same. You never allow direct traffic from the internet to the internal network. All traffic must stop in the screened subnet first, where it can be inspected and filtered. This design is foundational for securing corporate networks, cloud environments, and any system that must provide services to the public while protecting private assets.

Think of it like airport security. The terminal is the internal network. The security checkpoint is the external firewall. Passengers (data packets) arrive from the parking lot (internet) and must pass through security. They go into the sterile zone (screened subnet) where they can shop or wait at gates. That sterile zone is monitored. To board the plane (access the internal network), they must show a boarding pass and pass through another gate agent (internal firewall). The sterile zone is not the plane. It is a controlled buffer. This is why the screened subnet is also called a DMZ, or demilitarized zone, borrowing a military term for a neutral buffer area between two opposing forces. The screened subnet concept is especially important for IT certification learners because it appears in multiple exams, from CompTIA Network+ to AWS Solutions Architect. Understanding it means understanding how multiple layers of defense work together, which is a core principle of security architecture.

## Technical definition

A screened subnet is a network security architecture that implements a layered defense by creating a perimeter network segment, known as a demilitarized zone (DMZ), between an untrusted external network (typically the internet) and a trusted internal network. The architecture uses two or more packet-filtering or stateful inspection firewalls to enforce traffic policies. The external firewall, sometimes called the front-end firewall, connects directly to the internet router or border router. Its rule set is designed to allow only specific inbound traffic destined for servers within the screened subnet, such as HTTP/HTTPS (TCP ports 80 and 443) for a web server, SMTP (TCP port 25) for a mail relay, or DNS (UDP/TCP port 53) for a public DNS server. All other inbound traffic is blocked. The internal firewall, or back-end firewall, sits between the screened subnet and the internal network. Its rule set is more restrictive. It typically permits only outbound traffic initiated by servers in the screened subnet that need to reach internal resources, such as a web server querying an internal database server on a specific port (e.g., MySQL on TCP 3306) or a mail server delivering mail to an internal exchange server. Traffic from the internal network to the screened subnet may also be allowed for management purposes, but it is usually tightly controlled and often requires authentication or VPN. Crucially, no traffic from the internet is ever allowed to pass directly through to the internal network. All external traffic must terminate in the screened subnet. This design mitigates the risk of a compromised public-facing server being used as a pivot point to attack internal systems.

From a protocol and standards perspective, the screened subnet relies on IP addressing, subnetting, and routing. The screened subnet itself is a distinct IP subnet, for example, 10.0.100.0/24. The external firewall's outside interface has a public IP address, while its inside interface belongs to the screened subnet. The internal firewall's outside interface also belongs to the screened subnet, and its inside interface belongs to the internal network, for example, 10.0.10.0/24. Routing is configured so that traffic from the internet to the internal network is impossible without passing through the screened subnet. Network Address Translation (NAT) is often used on the external firewall to map public IP addresses to the private IP addresses of servers in the screened subnet. The internal firewall may also use NAT or simply route traffic. In more advanced implementations, a screened subnet can be built with a single firewall that has three or more network interfaces, known as a three-legged firewall or multi-homed firewall. In this design, the firewall itself is the only device that connects the three zones: untrusted, screened, and trusted. This reduces complexity and cost but creates a single point of failure. High-availability configurations often use firewall clusters. In cloud environments like AWS, a screened subnet architecture is implemented using Virtual Private Cloud (VPC) components. The external firewall can be a Network Access Control List (NACL) at the subnet level combined with Security Groups acting as stateful firewalls for instances. An internet gateway provides connectivity to the internet. Public subnets act as the screened subnet, hosting resources like web servers in an Auto Scaling group. Private subnets contain the internal resources, such as database servers. A NAT gateway or NAT instance in a public subnet allows private instances to initiate outbound internet traffic while preventing inbound traffic. The combination of route tables, NACLs, and Security Groups creates the same screening effect. On exam objectives for CCNA and Network+, you will see screened subnet as a key DMZ design, often compared with bastion host and dual-homed firewall architectures. The term also appears in the context of defense in depth and layered security, which are core concepts for Security+ and other security certifications. Implementation details include configuring default deny rules, enabling logging, and setting up intrusion detection or prevention systems (IDS/IPS) within the screened subnet for additional monitoring. The screened subnet is not a product, but a design pattern that scales from small offices to enterprise data centers and cloud infrastructure.

## Real-life example

Think about a bank with a secure vault. The vault is the internal network. It holds all the money and sensitive documents. The bank's front lobby is the screened subnet. Customers (internet users) can enter the lobby to do business with a teller (public server). They cannot walk past the teller into the back office. There is a locked door separating the lobby from the back office. That door is the internal firewall. Only employees with special keys (authorized traffic) can go through. Now, picture a jewelry store. The storefront window displays expensive watches and rings. That display area is the screened subnet. Anyone walking on the sidewalk (internet) can see the display, but they cannot touch it because of the glass (external firewall). To actually access the jewelry, you must enter the store and be buzzed through a locked door (internal firewall) to the sales counter. If a thief breaks the display window, they can only grab what is in the display case, which is limited and often protected with separate alarms. They cannot immediately get to the main inventory in the back safe. This is exactly how a screened subnet works. The external firewall allows only limited interaction with the public servers, like viewing a website or sending an email. If a hacker compromises the web server, they are in the display case, not the safe.

Another analogy is a hospital emergency room. The ambulance bay (internet) brings patients. The triage nurse (external firewall) assesses each patient and decides if they can be treated in the ER waiting area (screened subnet) or if they need immediate critical care. The waiting area has its own security. Patients cannot walk into the operating rooms. There is a secure door badge system (internal firewall) that only doctors and nurses can use. Even if a patient becomes disruptive in the waiting area, they cannot cause harm in the surgery wing. The screened subnet limits the blast radius of any security incident. For a more modern example, think of a coffee shop with a patio and an indoor section. The patio is the screened subnet. It is open to the street, but it is still part of the coffee shop's property. Anyone can sit on the patio without going inside. The coffee shop has a door from the patio to the indoor area. The barista controls who enters (internal firewall). You can order and pay on the patio window (public service), but to use the restroom or access the staff area, you need to go through that door. The patio serves as a buffer, preventing random people from wandering into the private back rooms. The screened subnet in IT does exactly the same thing. It is a buffer zone that allows controlled access to certain services while protecting the internal, trusted network. This analogy makes it clear why the screened subnet is a fundamental building block of network security. It is not about making the public servers invulnerable, but about isolating them so that a breach does not become a catastrophe.

## Why it matters

The screened subnet matters because it directly implements the security principle of defense in depth, which is the practice of layering multiple defensive mechanisms so that if one fails, another is already in place. In modern IT, almost every organization provides some internet-facing services, such as a website, email, or an API. These services are by nature exposed to attacks. A single firewall between the internet and the internal network is a single point of failure. If an attacker finds a vulnerability in that firewall or in a service that the firewall must allow, the entire internal network is exposed. The screened subnet changes that calculus. By forcing all external traffic to land in a middle zone, you create a buffer. Even if a web server in the screened subnet is compromised, the attacker must still find a way to bypass the internal firewall to reach internal resources. This significantly raises the cost and difficulty of an attack. For IT professionals, understanding the screened subnet is not academic. It is a design pattern you will use when setting up corporate networks, cloud infrastructure on AWS, Azure, or GCP, and even home lab setups. When you deploy a web application on AWS, you place the web servers in a public subnet (screened subnet) and the database in a private subnet (internal network). This is the screened subnet pattern. It matters for compliance as well. Standards like PCI DSS and HIPAA require strict segmentation between public-facing systems and systems that handle sensitive data. The screened subnet is a proven way to demonstrate that segmentation.

the screened subnet matters because it is a core exam topic across multiple certification tracks. For CompTIA Network+, you need to understand DMZ architecture and the role of screened subnets. For Security+, it is central to network security and secure design. For CCNA, you must know how to configure ACLs and firewall rules that enforce this architecture. For AWS Solutions Architect, it is the basis for designing secure VPCs. For Azure Administrator, similar concepts apply with Azure Virtual Networks and Network Security Groups. In each case, the exam expects you to not just define the term, but apply it to scenario-based questions. You might be given a case where a company has a single firewall and wants to add a DMZ. You need to recommend a screened subnet architecture. Or you might be asked to identify the security flaw in a design that allows direct traffic from the internet to an internal database. The screened subnet matters because it is a universal concept that connects network engineering, security, and cloud architecture. Mastering it shows a solid grasp of how to build secure, professional-grade systems.

## Why it matters in exams

The screened subnet is a high-yield topic for several major IT certification exams, and understanding why it matters in each exam context is crucial for scoring well. For CompTIA Security+ (SY0-601 or SY0-701), the screened subnet directly maps to exam objective 3.3, which covers secure network architecture and segmentation. You will be expected to explain how a screened subnet provides isolation for public-facing servers and how it fits into a defense-in-depth strategy. Questions often present a scenario where a company needs to host a web server and an email server, and you must choose the most secure architecture from multiple choices. The screened subnet is almost always the correct answer when the goal is to protect internal resources. For CompTIA Network+ (N10-008), the screened subnet appears under network security and DMZ concepts. Objective 4.1 covers network hardening and DMZ design. You need to know the difference between a screened subnet, a bastion host, and a dual-homed firewall. Multiple-choice questions may ask which architecture uses two firewalls to create a buffer zone. The screened subnet is also relevant to understanding how to configure VLANs and subnets for security.

For the AWS Solutions Architect Associate (SAA-C03), the screened subnet is essentially the design pattern for a secure VPC. The exam objective on designing secure architectures includes implementing public and private subnets, internet gateways, and NAT gateways. You must understand that web servers go in public subnets (screened subnet) and databases go in private subnets. Questions often require you to identify a design flaw where a database is placed in a public subnet or where a security group allows inbound traffic from 0.0.0.0/0 to a database. The screened subnet concept helps you reason about the correct placement of resources. For the Cisco CCNA (200-301), the screened subnet is part of network security and ACL configuration. You might be asked to configure ACLs on a router that connects three zones: outside, DMZ, and inside. Exam objectives include understanding firewall placement and the traffic flow between zones. The screened subnet is the architecture that justifies the ACL design. For the Google Associate Cloud Engineer (ACE), the screened subnet concept appears in VPC network design, where you place a load balancer in front of instances in a public subnet and keep backend instances in a private subnet with Cloud NAT. For Microsoft Azure Administrator (AZ-104), the concept is applied using Azure Virtual Networks, subnets, and Network Security Groups. You create a DMZ subnet and use NSGs to restrict traffic. In all these exams, the question type varies. Some are straightforward multiple-choice questions asking for the definition or benefit. Others are complex scenario-based questions where you must analyze a network diagram and identify the security weakness. Many drag-and-drop questions ask you to place firewalls and servers in the correct network segments. The core takeaway is that the screened subnet is not just a term to memorize, but a design principle that you must apply. If you understand the why behind the screened subnet, you can answer any question about layer security, segmentation, or DMZ design. That is why it matters so much in exams.

## How it appears in exam questions

Screened subnet questions appear in certification exams in three main patterns: scenario-based design, configuration and troubleshooting, and concept comparison. In scenario-based design questions, you are given a company's requirements and a network diagram with missing components. For example, a question might describe an e-commerce company that needs to host a web server and a separate database server. The web server must be accessible from the internet, but the database must only be accessible from the web server. The question will show a diagram with a router connected to the internet, and you must choose where to place the firewalls and servers. The correct answer is to create a screened subnet with an external firewall, a web server in the middle, and an internal firewall protecting the database server. The distractors might include placing both servers on the same segment with one firewall, or placing the database server in the DMZ. These questions test your ability to apply the concept rather than just recall a definition.

Configuration-based questions appear more in CCNA and cloud exams. For CCNA, you might see a question like: 'An administrator is configuring ACLs on a router that connects three networks: 192.168.1.0/24 (inside), 192.168.2.0/24 (DMZ), and a connection to the ISP. Which ACL statement on the outside interface will allow web traffic to the DMZ while blocking all other inbound traffic?' You need to apply the principle that only specific ports (like 80 and 443) destined for the DMZ subnet should be permitted, and everything else denied. In AWS, a question might ask: 'A company wants to host a web application using EC2 instances and an RDS database. Which combination of VPC components implements a screened subnet architecture?' The correct answer includes a public subnet for web servers, a private subnet for RDS, an internet gateway, and a NAT gateway for outbound traffic. Another common question type is troubleshooting. A scenario describes a network that was working, but after a change, the web server is no longer accessible, or the internal network is reachable from the internet. You must identify that the internal firewall rule set was misconfigured to allow traffic from the internet directly to the internal network, or that a server was placed in the wrong subnet. These questions test your understanding of traffic flow and rule enforcement.

Concept comparison questions are common in CompTIA exams. They ask: 'Which of the following best describes a screened subnet?' with options that may describe a bastion host, a dual-homed firewall, or a screened host. The key is to remember that a screened subnet uses two firewalls or a three-legged firewall to create a separate network segment. Another variation: 'What is the primary advantage of a screened subnet over a screened host?' The answer is that a screened subnet provides a dedicated network segment for public servers, offering better isolation and security. These questions are straightforward if you have internalized the architecture. You must also be careful with terminology. Some questions use 'DMZ' interchangeably with 'screened subnet,' but they are not always identical. A DMZ can be implemented with a single firewall, while a screened subnet specifically implies two firewalls or a three-legged firewall. The exam may test this nuance. The key to answering screened subnet questions is to visualize the three zones: untrusted, screened, and trusted. Understand what traffic is allowed where, and you will handle any question pattern.

## Example scenario

A small online bookstore, 'ReadMore Books,' wants to launch a website where customers can browse and purchase books. The company also has an internal network with employee workstations and a database of customer orders and credit card information. The owner, Sarah, is concerned about security and asks her IT consultant, Mark, for advice. Mark proposes a screened subnet architecture. He sets up an external firewall connected directly to the internet service provider's modem. On the other side of that firewall, he creates a small network segment called a DMZ. He installs one web server in the DMZ. That web server runs the bookstore's website, showing book covers, prices, and a shopping cart. The external firewall is configured to allow only web traffic on ports 80 and 443 from the internet to the web server. All other traffic is blocked. Then, Mark installs a second firewall between the DMZ and the internal network. This internal firewall has a very restrictive rule set. It only allows the web server to make outbound connections to the internal database server on port 3306 (MySQL) when it needs to check inventory or record an order. It also allows the IT administrator to securely connect from the internal network to the web server for updates, but only after logging in with a VPN. The internal firewall explicitly blocks all traffic initiated from the DMZ to the internal network except for that one specific outbound rule. It also blocks all traffic from the internet that somehow slipped past the external firewall. Now, imagine a hacker tries to break into the web server. Even if they succeed, they find themselves in the DMZ. They cannot see the internal network because there is no direct route. They cannot access the customer database because the internal firewall blocks all inbound connections from the DMZ. The only thing the web server is allowed to do is query the database for legitimate order information, and the hacker cannot abuse that to extract all data because the rule is tightly scoped. Meanwhile, the internal network remains safe. Sarah's customer credit card data is protected. This scenario shows how the screened subnet provides a practical, layered defense. The bookstore can offer its services to the public without exposing its private data. The web server is like a storefront, but the real safe is in a separate building with its own lock.

## Screened Subnet Architecture and Security Principles

A screened subnet, also known as a demilitarized zone (DMZ) in many network designs, is a critical architectural pattern used to isolate publicly accessible services from internal private networks. The core concept involves placing one or more firewalls at the network perimeter to create an intermediate network segment where servers such as web servers, email gateways, and DNS resolvers reside. This segment is "screened" because traffic passing into or out of it must traverse a firewall, which enforces strict access control policies. In modern cloud environments like AWS, Azure, and Google Cloud, the screened subnet is often implemented using network access control lists (NACLs), security groups, and virtual private cloud (VPC) configurations. The primary security advantage is that even if an attacker compromises a server in the screened subnet, they cannot directly access internal resources because the internal firewall or routing rules block such traffic. This architecture is foundational for CCNA, Network+, and Security+ exams, where candidates must understand how to design a network that minimizes attack surface. For AWS SAA and Google ACE, the concept extends to designing multi-tier architectures with public and private subnets, where the public subnet acts as the screened subnet. AZ-104 candidates must configure Azure Firewall and network security groups to achieve the same isolation. The screened subnet also supports bastion hosts or jump boxes for secure administrative access, where administrators connect to the bastion in the screened subnet and then access internal resources via SSH or RDP forwarding. This layered approach ensures that management traffic is audited and controlled. A common exam topic is the difference between a screened subnet and a dual-homed firewall setup. In a screened subnet, the firewall has three interfaces: one to the internet, one to the screened subnet, and one to the internal network. Traffic from the internet can reach the screened subnet but not the internal network directly, while traffic from internal users can reach the internet or the screened subnet but only after passing through firewall rules. This three-legged design is more secure than a simple bastion host because it provides defense in depth. Another key concept is that the screened subnet can be used to host reverse proxies that inspect and filter traffic before it reaches internal application servers. Overall, the screened subnet is a staple of secure network architecture testing in certification exams.

## Implementing a Screened Subnet in AWS, Azure, and GCP

Implementing a screened subnet in cloud environments requires a solid understanding of virtual networking constructs such as subnets, routing tables, and security policies. In Amazon Web Services (AWS), the simplest approach is to create a Virtual Private Cloud (VPC) with both public and private subnets. The public subnet acts as the screened subnet, where resources like Elastic Load Balancers (ELBs) and web servers are placed. Network ACLs and security groups are configured to allow only necessary inbound traffic (e.g., HTTP/HTTPS from the internet) and to restrict outbound traffic to only required destinations. For internal resources like databases, they reside in private subnets with no direct internet access. A NAT Gateway or NAT Instance in the public subnet enables outbound internet access for private resources while keeping them unreachable from the internet. This mirrors the traditional screened subnet architecture. In Microsoft Azure, the equivalent is achieved using Virtual Networks (VNets) with subnets designated as “frontend” and “backend”. Azure Firewall or Network Security Groups (NSGs) control traffic flow, and Azure Bastion provides secure RDP/SSH access to VMs without exposing them directly. For Google Cloud Platform (GCP), VPCs support subnet creation with firewall rules that can be applied at the subnet level. Cloud NAT is used for outbound-only internet access. Key exam scenarios for AWS SAA include troubleshooting a scenario where an EC2 instance in a public subnet cannot be reached due to misconfigured security groups, or where a private subnet instance needs to download updates via a NAT Gateway. For AZ-104, questions often involve configuring Azure Firewall to allow certain traffic to the frontend subnet while blocking all inbound traffic to the backend. Google ACE candidates must understand how to use VPC firewall rules to isolate tiers. Another important implementation detail is the use of Web Application Firewalls (WAF) in front of the screened subnet to filter malicious requests. Cloud providers offer managed WAF services (AWS WAF, Azure WAF, Google Cloud Armor) that integrate with load balancers to protect the screened subnet. This layered security approach is a frequent theme in Security+ and CCNA exams. Implementing a bastion host or jump server in the screened subnet is a common pattern for secure administration. The bastion is hardened, monitored, and logs all access attempts. Overall, cloud implementation of a screened subnet emphasizes configuration of network boundaries and access control lists, which are fundamental skills tested in all these certifications.

## Troubleshooting Connectivity Issues in a Screened Subnet

Connectivity problems in a screened subnet often stem from misconfigured firewall rules, routing tables, or network segmentation. A common issue is when a server in the screened subnet cannot reach internal resources. This typically occurs because the internal firewall or network ACL is blocking outbound traffic from the screened subnet to the internal network. For example, in AWS, if a security group attached to an EC2 instance in the public subnet does not have an outbound rule allowing traffic to the private subnet’s CIDR range, the connection fails. Similarly, if the routing table for the public subnet does not have a route to the private subnet (or uses a different VPC), traffic will be dropped. In Azure, NSG rules are evaluated in order, and a deny rule might be inadvertently blocking traffic. Another frequent issue is that external users cannot access services in the screened subnet. The problem could be that the internet gateway is not attached to the VPC, or that the route table for the public subnet does not have a default route (0.0.0.0/0) pointing to the internet gateway. For CCNA and Network+ exams, understanding ARP and IP routing is crucial-if a packet reaches the firewall but the firewall has no route to the screened subnet, it will be dropped. Asymmetric routing can cause issues: if traffic enters through one path (e.g., through a load balancer) but returns via a different path that is blocked, connections will hang. In cloud exams, troubleshooting often involves checking flow logs (VPC Flow Logs in AWS, NSG flow logs in Azure, or VPC flow logs in GCP) to see if packets are being accepted or rejected. Another exam-relevant scenario is when a screened subnet server is reachable but cannot initiate connections to the internet-often due to missing NAT gateway or misconfigured egress-only internet gateway in IPv6 setups. Security+ exams also cover troubleshooting SSL/TLS handshake failures when a proxy or load balancer in the screened subnet terminates encryption but the backend server expects it. Another common problem is DNS resolution failure: if the screened subnet has a custom DNS server that cannot resolve external names, users will experience timeouts. The solution is to configure appropriate DNS forwarding or use cloud-provided DNS (e.g., Route 53 Resolver, Azure DNS, or Google Cloud DNS). In all cases, systematic troubleshooting using traceroute, ping, telnet, and netstat is essential. Examiners love to ask about the order of rule evaluation: for AWS NACLs (stateless) vs security groups (stateful) and how they affect traffic flow. Understanding stateful inspection is key-if a packet is allowed in, the return traffic is automatically allowed unless NACLs interfere. These nuances are tested repeatedly in CCNA and Network+.

## Exam Strategies: Screened Subnet Scenarios and Common Pitfalls

When tackling exam questions about screened subnets across AWS SAA, CCNA, Network+, Security+, Google ACE, and AZ-104, candidates should focus on understanding the flow of traffic and the security boundaries. One common pitfall is confusing the roles of a screened subnet versus a dedicated DMZ. In many modern architectures, the screened subnet is exactly the DMZ, but older designs may use a separate physical interface. Examiners test whether you know that a screened subnet is always between two firewalls or behind a single firewall with three interfaces (tri-homed). Another frequent scenario involves placing a web server in the screened subnet and a database server in the internal subnet. The question might ask: “Where should the database reside?” The correct answer is the internal subnet, with strict firewall rules allowing only the web server’s IP on the specific port. For cloud exams, you must know that security groups are stateful, so if you allow inbound HTTP, the return traffic is automatically allowed, but NACLs are stateless and require explicit inbound and outbound rules. A typical trap is that an examinee chooses a NACL configuration that allows inbound TCP 80 but forgets to allow ephemeral ports for outbound, causing connection failures. Another strategy is to remember that a bastion host should always be placed in the screened subnet (or a separate management subnet) and never in the internal subnet because it provides a controlled entry point. Security+ exams often include scenarios about avoiding a direct SSH from the internet to internal servers-always route through a bastion. For AZ-104, you might be asked to configure Azure Bastion to access VMs in a private subnet without public IPs-this is a direct analog of the screened subnet concept. In CCNA and Network+, you may see ACL configuration questions: “Which ACL rules would allow web traffic to the DMZ but block SQL traffic from the DMZ to the inside?” The answer involves applying inbound ACL on the inside interface of the firewall. Another pitfall is assuming that placing a server in a public subnet automatically makes it accessible-it requires both a route to the internet gateway and a security group that allows inbound traffic. Google ACE exams emphasize that firewall rules are applied at the VPC network level, not the subnet, and are stateful unless specified otherwise. Understanding these nuances can save points. Also, remember that a screened subnet is not only for web servers-it can host VPN endpoints, email relays, and reverse proxies. An exam question might present a scenario where a VPN concentrator is compromised, and the ask is to minimize the blast radius-the correct design is to isolate it in the screened subnet. Finally, always double-check the direction of traffic in rule-based questions: inbound vs outbound, source vs destination. A common mistake is applying a rule to the wrong interface. By memorizing these patterns and reviewing real-world architectures, you can confidently answer any screened subnet question across these certifications.

## Common mistakes

- **Mistake:** Thinking a screened subnet is the same as a single firewall with a DMZ port.
  - Why it is wrong: A single firewall that has three network interfaces (inside, outside, DMZ) is a three-legged firewall, not necessarily a screened subnet. The term 'screened subnet' specifically implies a separate network segment with at least two firewalls or a firewall that enforces strict segmentation. Many learners assume any DMZ is a screened subnet, but the screened subnet is a specific architecture that provides stronger isolation by having two independent filtering points.
  - Fix: Remember that a screened subnet uses two separate firewalls or a three-legged firewall, but even a three-legged firewall is a variant that still has two logical firewalls. If the DMZ is just a port on a single firewall with no additional filtering between the DMZ and the internal network, it is not a true screened subnet.
- **Mistake:** Believing that traffic from the internet can ever pass directly to the internal network in a screened subnet.
  - Why it is wrong: The entire purpose of a screened subnet is to prevent direct internet-to-internal traffic. Some learners think that because the internal firewall is present, it is okay to allow some direct traffic if it is 'secure.' But that violates the principle. All external traffic must terminate in the DMZ. If you allow traffic from the internet to the internal network, you have created a screened host architecture, not a screened subnet.
  - Fix: In a true screened subnet, the rule is simple: no traffic from the internet is ever allowed to reach the internal network directly. The DMZ is a mandatory stop. Always enforce this rule in your exam reasoning.
- **Mistake:** Placing the database server in the same DMZ as the web server.
  - Why it is wrong: If the database server is in the DMZ, it is exposed to the same level of risk as the web server. An attacker who compromises the web server can then easily access the database because they are on the same network segment. The whole point of the screened subnet is to provide a separate, more secure network for sensitive data.
  - Fix: Always place internal resources like databases, directory servers, and employee workstations in the internal network, behind the internal firewall. Only place resources that must be directly accessed from the internet in the DMZ.
- **Mistake:** Confusing a screened subnet with a bastion host.
  - Why it is wrong: A bastion host is a single, hardened server that is placed in the DMZ or on the perimeter to provide secure access to the internal network, often via RDP or SSH. A screened subnet is an entire network segment with multiple hosts. A bastion host can be a component within a screened subnet, but the two are not the same thing.
  - Fix: Think of the screened subnet as the whole buffer zone, and the bastion host as one specific server inside that zone that is used for administrative access. The exam may test this distinction.
- **Mistake:** Neglecting to configure the internal firewall to restrict outbound traffic from the DMZ.
  - Why it is wrong: Some learners focus only on inbound rules and forget that the internal firewall must also control outbound traffic from the DMZ to the internal network. If the DMZ server can freely initiate connections to the internal network, a compromised server can be used to attack internal systems. The internal firewall must use stateful filtering to only allow expected outbound connections, such as a web server querying a specific database port.
  - Fix: Always consider both directions. The internal firewall should be configured with a default-deny policy for traffic from the DMZ to the internal network, with explicit allow rules for only the necessary services.
- **Mistake:** Assuming that a screened subnet is only for large enterprises.
  - Why it is wrong: Many small or home office setups also benefit from a screened subnet. The architecture scales down. Even using a single router with DMZ capabilities and a separate firewall or VLAN can create a form of screened subnet. The principle is independent of scale.
  - Fix: Understand that the screened subnet is a design pattern that can be implemented with varying levels of complexity, from enterprise firewalls to cloud VPCs to home lab routers with VLANs.

## Exam trap

{"trap":"The exam presents a scenario where a company has a single firewall with three interfaces (inside, outside, DMZ) and calls it a 'screened subnet.' Learners may answer that it is not a screened subnet because it uses only one firewall.","why_learners_choose_it":"Learners memorize that a screened subnet requires two firewalls, so when they see a single device, they reject it as a valid screened subnet.","how_to_avoid_it":"A three-legged firewall is a legitimate implementation of a screened subnet. Even though it is a single hardware device, it performs the filtering functions of two separate firewalls. The exam accepts this as a valid screened subnet architecture. The key is that there are two distinct filtering points, not necessarily two separate physical devices."}

## Commonly confused with

- **Screened subnet vs Bastion host:** A bastion host is a single server that acts as a secure gateway for administrative access to an internal network. A screened subnet is an entire network segment that hosts multiple public services. The bastion host is often located inside a screened subnet but is not the same concept. The screened subnet provides a whole buffer zone, while the bastion host is a specific hardened entry point. (Example: If the screened subnet is the lobby of a building, the bastion host is the security guard desk inside the lobby where visitors must check in.)
- **Screened subnet vs Screened host architecture:** In a screened host architecture, there is a single firewall that connects to the internet, and a single host (the screened host) sits on the internal network but has a direct connection to the internet through the firewall. There is no separate DMZ network. The screened subnet uses two firewalls and a separate network segment for public servers, providing stronger isolation. (Example: A screened host is like having a single door with a guard, and the guard allows a specific person to go straight into the main office. A screened subnet is like having two doors with a waiting room in between.)
- **Screened subnet vs Dual-homed firewall:** A dual-homed firewall is a single firewall with two network interfaces, typically connecting an internal and an external network. It does not create a DMZ. A screened subnet usually involves a firewall with at least three interfaces (three-legged) or two separate firewalls. A dual-homed firewall can be part of a screened host architecture, but not a screened subnet. (Example: A dual-homed firewall is like a single door between two rooms. A three-legged firewall is like a door that opens to a hallway (DMZ) and another door at the end of the hallway to the main room.)
- **Screened subnet vs DMZ (Demilitarized Zone):** A DMZ is a broader term that refers to any network segment that is isolated from the internal network and contains public-facing services. A screened subnet is a specific type of DMZ that uses two firewalls or a three-legged firewall to enforce strict traffic control. All screened subnets are DMZs, but not all DMZs are screened subnets. A DMZ can be implemented with a single firewall and a separate VLAN, which is less secure. (Example: A DMZ is any buffer zone. A screened subnet is a fortified buffer zone with two checkpoints.)

## Step-by-step breakdown

1. **Identify the network zones** — The first step is to clearly define the three network zones: the untrusted network (internet), the screened subnet (DMZ), and the trusted internal network. Each zone must be on a different IP subnet. For example, the internet is represented by a public IP block, the DMZ uses 10.0.1.0/24, and the internal network uses 10.0.2.0/24. This logical separation is fundamental to the architecture.
2. **Place the external firewall** — Install a firewall between the internet and the DMZ. This firewall's outside interface connects to the internet router or modem, and its inside interface connects to the DMZ network. The external firewall is configured with a default-deny inbound policy. Only specific traffic types required by public services are allowed, such as HTTP, HTTPS, SMTP, or DNS. This firewall also performs Network Address Translation (NAT) to map public IPs to the private IPs of servers in the DMZ.
3. **Deploy servers in the DMZ** — Place all servers that need to be directly accessible from the internet into the DMZ. Common examples include web servers, email relays, DNS servers, and VPN concentrators. These servers are assigned private IP addresses from the DMZ subnet. They are configured with hardened operating systems, regular patch cycles, and monitoring software. They are considered untrusted because they are exposed to the internet.
4. **Place the internal firewall** — Install a second firewall between the DMZ and the internal network. This firewall's outside interface connects to the DMZ, and its inside interface connects to the internal network. The internal firewall also uses a default-deny policy, but its rules are different. It must explicitly allow only necessary traffic from the DMZ to internal resources, such as a web server querying a database. It also controls traffic from the internal network to the DMZ for management purposes.
5. **Configure internal firewall rules** — The internal firewall should allow outbound traffic from the DMZ to the internal network only for specific services and to specific hosts. For example, allow TCP port 3306 from the web server's IP to the database server's IP. Deny all other traffic. Also, allow traffic from the internal network to the DMZ for administration, such as SSH from a management workstation to the web server, but restrict it to authorized IPs and require strong authentication.
6. **Configure routing and NAT** — Ensure proper routing between the zones. The external firewall routes traffic from the internet to the DMZ. The internal firewall routes traffic between the DMZ and internal network. No route should exist that allows traffic to bypass either firewall. NAT is typically configured on the external firewall. For the internal network to access the internet (e.g., for software updates), a separate NAT gateway or proxy is set up, often in the DMZ, and traffic is routed through the external firewall.
7. **Implement monitoring and logging** — Enable logging on both firewalls to track all traffic attempts. Set up an intrusion detection or prevention system (IDS/IPS) within the DMZ to monitor for malicious activity. Regularly review logs to ensure no rule violations. Also, implement network segmentation using VLANs if physical separation is not possible, but the logical separation must still be enforced by the firewalls. Finally, document the architecture and rules for auditing and troubleshooting.

## Practical mini-lesson

In practice, designing a screened subnet requires careful planning and a deep understanding of the services you are exposing. As a network or security professional, you must first inventory all the applications that need public access. For each service, you need to know the protocol, port, and direction of traffic. The general rule is to allow the least amount of traffic necessary. For example, a web server needs inbound HTTP and HTTPS, and outbound MySQL to a database. Do not allow ICMP or other management protocols from the internet. Keep the rule set as small as possible. When you configure the external firewall, always set a default-deny rule at the end of the access control list. Then, add allow rules for the specific services. Use object groups to simplify management. For example, create a group called 'Web-Servers' with the IP address of the web server, and a service group called 'Web-Traffic' with TCP/80 and TCP/443. Then, the rule is simple: allow Web-Traffic from any to Web-Servers. On the internal firewall, the configuration is even more restrictive. Create a rule that allows the web server to talk to the database server on the specific port. Use the source IP of the web server, the destination IP of the database, and the service port. Deny everything else. Also, consider the management plane. You need to be able to update and patch the servers in the DMZ. The best practice is to set up a jump box or bastion host inside the DMZ that is accessible only via a VPN from the internal network. The internal firewall allows VPN traffic from the internal network to the bastion host. Then, from the bastion host, you can securely administer the other DMZ servers. This avoids opening direct RDP or SSH ports on the public firewall. What can go wrong? One common issue is misconfiguration of NAT. If the external firewall does not properly translate the public IP to the DMZ server's private IP, the service will be unreachable. Another issue is asymmetric routing. If traffic enters through one firewall and leaves through another, stateful firewalls may drop packets. Always ensure that all traffic to and from a service passes through the same firewall path. In cloud environments, you must be careful with Security Group rules. A common mistake is to attach a Security Group to a database instance that allows inbound traffic from 0.0.0.0/0, which defeats the purpose of the screened subnet. Instead, the database's Security Group should only allow traffic from the Security Group attached to the web servers. This is called security group linking, and it is a direct application of the screened subnet principle. Monitoring is also critical. Set up alerts for any denied traffic that appears to be malicious. Analyze logs regularly to see if any rules are too permissive. For example, you might find that the web server is generating outbound traffic to an unexpected IP, which could indicate a compromise. The screened subnet gives you time to detect and respond to such an incident before it affects internal systems. Finally, remember that the screened subnet is not a set-and-forget design. As your organization grows, you may add new public services. Always follow the same process: place the service in the DMZ, create a rule on the external firewall, and create a rule on the internal firewall if the service needs internal access. Over time, periodically review all rules and remove any that are no longer needed. This practice, known as firewall rule audit, keeps your screened subnet effective and secure.

## Commands

```
aws ec2 create-subnet --vpc-id vpc-12345678 --cidr-block 10.0.1.0/24 --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=ScreenedSubnet}]'
```
Creates a public subnet in AWS to act as a screened subnet for web servers. Use this when setting up a DMZ in a VPC.

*Exam note: AWS SAA exams test the ability to create subnets in a VPC and understand that public subnets require an internet gateway route.*

```
az network vnet subnet create --resource-group myRG --vnet-name myVnet --name BackendSubnet --address-prefixes 10.0.2.0/24 --network-security-group myNSG
```
Creates an Azure backend subnet with a network security group to isolate internal resources from the public-facing screened subnet.

*Exam note: AZ-104 exams test subnet creation and NSG association-know that backend subnets should have restrictive NSG rules.*

```
gcloud compute networks subnets create screened-subnet --network my-vpc --region us-central1 --range 10.0.1.0/24 --enable-private-ip-google-access
```
Creates a subnet in Google Cloud with private Google access enabled, useful for a screened subnet that needs to reach Google APIs without public IPs.

*Exam note: Google ACE exams test the use of --enable-private-ip-google-access for private subnets connecting to Google services.*

```
ip route add 192.168.1.0/24 via 10.0.0.1 dev eth0
```
On a Linux bastion in a screened subnet, adds a static route to the internal network so that the bastion can forward traffic to internal servers.

*Exam note: CCNA exams test static routing concepts-this command demonstrates how to configure a route from a DMZ to a private network.*

```
access-list 101 permit tcp any host 10.0.1.10 eq 80
access-list 101 deny ip any 10.0.2.0 0.0.0.255
```
Cisco ACL applied to a firewall interface: allows HTTP traffic from anywhere to a web server in the screened subnet at 10.0.1.10, but blocks all traffic to the internal subnet 10.0.2.0/24.

*Exam note: Network+ and CCNA exams test ACL syntax and order-remember that ACLs are processed top-down and the order matters.*

```
iptables -A FORWARD -i eth0 -o eth1 -s 10.0.1.0/24 -d 10.0.2.0/24 -j ACCEPT
```
On a Linux firewall with two interfaces, this iptables rule allows forwarding traffic from the screened subnet (eth0) to the internal network (eth1).

*Exam note: Security+ exams test firewall rules and packet filtering-this command shows how to control inter-zone traffic.*

```
netsh advfirewall firewall add rule name="Allow HTTP from DMZ" dir=in action=allow protocol=TCP localport=80 remoteip=10.0.1.0/24
```
On Windows Server, adds a firewall rule to allow inbound HTTP traffic from the screened subnet (DMZ) to a web server in the internal network.

*Exam note: A+ and Network+ exams test Windows firewall configuration-know that inbound rules can restrict source IPs.*

## Troubleshooting clues

- **Cannot reach web server in screened subnet from the internet** — symptom: Users outside the internal network get timeouts or connection refused when accessing the public IP of the web server.. The most common cause is missing inbound rules in the security group or firewall allowing HTTP/HTTPS traffic from 0.0.0.0/0, or the internet gateway not being attached to the VPC. (Exam clue: AWS SAA exams often present a scenario where an EC2 instance in a public subnet is unreachable. The answer is to check the security group inbound rule for port 80/443 and the route table for a default route to the internet gateway.)
- **Bastion host can SSH to internal server but session drops after a few seconds** — symptom: SSH connection establishes but drops unexpectedly, sometimes with 'connection reset by peer' errors.. This is often due to TCP keepalive settings or a firewall rule that terminates idle sessions. In a screened subnet, if the firewall is stateful, it may drop flows that are idle for too long. Also check if the internal server's firewall is blocking the source IP of the bastion. (Exam clue: Security+ and Network+ exams test understanding of TCP stateful inspection and session timeouts. The fix is to adjust idle timeout settings or use TCP keepalives.)
- **Internal database cannot be reached from web server in screened subnet** — symptom: Web application errors with 'cannot connect to database' or timeouts when trying to access the database server.. The web server's security group outbound rule may not allow traffic to the database port (e.g., 3306 for MySQL) or the database security group inbound rule does not allow the web server's private IP. Routing between subnets might be missing. (Exam clue: AWS SAA and Azure AZ-104 exams test multi-tier architecture where each tier has its own security group. The exam expects you to permit only necessary ports from the web server to the database.)
- **Outbound internet access fails from servers in screened subnet** — symptom: Servers in the screened subnet cannot download updates or resolve external DNS names.. If the subnet is a public subnet (has a route to the internet gateway), outbound access should work, but a misconfigured network ACL or security group might block outbound ephemeral ports. For private subnets, a NAT gateway or instance is required. (Exam clue: CCNA and Network+ exams test the concept of NAT and routing. The exam question might ask why an internal server cannot reach the internet, and you must identify the missing NAT device.)
- **Screened subnet server gets IP address from wrong range** — symptom: Server receives an IP address outside the planned CIDR block for the screened subnet, causing connectivity issues with other subnets.. This can happen if the DHCP server or cloud DHCP option set is not configured correctly. In cloud environments, the VPC subnet CIDR defines the IP range. If you attach the server to the wrong subnet, it will get the wrong IP. (Exam clue: A+ and Network+ exams test IP addressing and subnetting. The correct answer is to verify the subnet association or change the DHCP scope.)
- **Firewall logs show dropped packets from screened subnet to internal network** — symptom: Application logs indicate that the web server cannot connect to the backend database, and firewall logs show 'DENY' for traffic from the screened subnet IP to the internal network.. The firewall rule is correctly blocking traffic because it is designed to prevent direct access from the screened subnet to internal resources. But if the traffic is legitimate (e.g., web server to database), the firewall rule must be updated to allow that specific flow. (Exam clue: Security+ exams test firewall rule design-you must understand that by default, traffic between zones is denied. The exam expects you to create a rule that permits only the necessary service with the least privilege.)
- **Intermittent connectivity to load balancer in screened subnet** — symptom: Users experience random timeouts or errors when accessing a load balancer that distributes traffic to servers in the screened subnet.. This could be due to health check failures where the target servers are not responding correctly, or the load balancer's security group is not allowing health check traffic from the load balancer's subnet. Also, if the load balancer is cross-zone, ensure that all zones are healthy. (Exam clue: AWS SAA and Google ACE exams test load balancer configuration. A common question is why an ALB shows 'unhealthy' targets; the answer is often a misconfigured security group for health checks.)

## Memory tip

Think of three zones: Untrusted (internet), Screened (DMZ), Trusted (internal). Two firewalls mean two denials. Traffic must stop in the middle.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/screened-subnet