Screened Subnet Firewall
You build a screened subnet firewall by placing two routers around a middle network zone. This middle zone holds public apps and blocks direct traffic to your private internal network. Engineering teams often set up this perimeter to separate web servers from backend databases. Still, teams often grant broad network permissions so developers can reach backend systems to fix bugs. When network rules allow wide subnet traffic, a single compromised host exposes every internal database. How a scre
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You build a screened subnet firewall by placing two routers around a middle network zone. This middle zone holds public apps and blocks direct traffic to your private internal network. Engineering teams often set up this perimeter to separate web servers from backend databases. Still, teams often grant broad network permissions so developers can reach backend systems to fix bugs. When network rules allow wide subnet traffic, a single compromised host exposes every internal database.
How a screened subnet firewall works
A screened subnet firewall uses three distinct network zones to control traffic flow. The outer router sits between the public internet and the middle perimeter network. This outer device filters incoming web requests and blocks known bad network traffic. Public web servers and mail relays live inside this middle perimeter zone. If an attacker compromises a public server, they remain trapped inside the middle subnet.
The inner router sits between the middle perimeter zone and the private internal network. This inner device enforces strict packet rules before any traffic enters the private zone. It only lets specific perimeter servers talk to internal databases on approved network ports. External users never get a direct network path to the private internal zone. Both routers must check and approve packets before traffic crosses the full network boundary.
What network rules solve and what they miss
This dual router setup stops outside attackers from scanning your private internal servers. It gives network teams clear boundaries for public traffic, perimeter apps, and private data. If a public web app fails, your core internal network stays isolated from direct internet scans. Network packet rules work well for stopping unauthorized hosts from opening raw network connections.
Still, network routers only check IP addresses and ports when a connection starts. Once a developer or app opens an allowed port, the firewall stays blind. The router cannot read the database queries or shell commands running inside that session. Teams still share static database keys across the inner boundary to get work done. Also, packet logs do not show who ran a destructive query or read sensitive fields. Masking rules that rewrite emails, phone numbers, card numbers, or national IDs in results cannot run at the packet level.
Managing developer sessions across internal zones
When engineers need to check production data, they must cross both router boundaries. Network teams often open wide port rules for developer VPN subnets to allow this work. Once inside the private zone, an engineer with a shared role can run any command. A simple typo can drop a production table or expose thousands of customer card numbers. Packet filters cannot stop a bad command inside an approved network path.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
To close this gap, teams need controls that inspect individual queries and commands in flight. Security must move from basic IP address checks to user identity and command checks. When you check every query, you can block destructive drops and rewrite sensitive fields in results. This keeps production data safe even when a user has an active network session.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What is the difference between a DMZ and a screened subnet?
They describe the same network pattern. The middle zone between the two routers acts as the demilitarized zone for public hosts.
Why use two routers instead of one firewall device?
Two separate routers prevent a single point of failure. An attacker must break through two distinct rule sets to reach the private network.
Does a screened subnet protect against stolen database credentials?
No, network routers only filter IP addresses and ports. If an attacker uses valid credentials over an open port, the router lets the traffic pass.
Short role checks help teams work fast. Simple rules make each review clear. Good logs keep every team safe. Scoped keys stop bad changes early.