Three Legged Firewall
A three legged firewall uses three network ports to split traffic into three zones. You set up one leg for the web, one for the DMZ, and one for private systems. Network teams use this design to host public web servers while keeping backend databases isolated. If your firewall rules are too broad, an attacker in the DMZ can reach private servers. How a three legged firewall routes zone traffic This design relies on a single firewall device with three distinct network interfaces. The first leg
Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A three legged firewall uses three network ports to split traffic into three zones. You set up one leg for the web, one for the DMZ, and one for private systems. Network teams use this design to host public web servers while keeping backend databases isolated. If your firewall rules are too broad, an attacker in the DMZ can reach private servers.
How a three legged firewall routes zone traffic
This design relies on a single firewall device with three distinct network interfaces. The first leg links to the public internet through an external router. The second leg links to a DMZ subnet that holds public web or mail apps. The third leg links to the internal network where private databases and team machines run.
Admins write strict packet rules to control how traffic moves between each leg. Public users can send web requests from the outside leg into the DMZ leg. The firewall blocks those same public users from sending packets directly to the internal leg. If a DMZ web app needs data, the firewall permits one specific port into the internal zone.
All traffic between the three zones must pass through the central firewall rule engine. The firewall checks the source IP, destination IP, and port number on every packet. If a packet matches an allow rule, the firewall forwards it to the target interface. If the packet does not match a rule, the firewall drops the traffic right away.
Why network zones leave an internal command gap
A three legged firewall does a great job of blocking unauthorized network paths. It stops outside scanners from reaching private database ports on the internal network leg. It also limits how far an attacker can move if a public web server breaks. Teams rely on this layout to build a clear boundary between public and private subnets.
Still, port and IP rules only decide which machines can talk to each other. Once a developer or app opens an allowed port, the firewall steps out of the way. The firewall does not read the database queries or shell commands inside that encrypted session. A valid user on an allowed port can still run a bad query that drops a table.
Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Shared service roles and wide subnet rules make this blind spot even worse for ops teams. Many engineers log in from an internal subnet using the same database role and static key. Network logs only show that an IP address sent bytes over a database port. When an engineer runs a query that returns card numbers or emails, the firewall logs nothing about the command.
How to tighten rules across all three legs
Start by setting a default deny rule on all three interfaces of the firewall. Open only the exact ports that your DMZ apps need to talk to internal databases. Never allow the DMZ subnet to open outbound traffic back to the public internet leg. This stops a compromised DMZ host from downloading bad tools or sending stolen data out.
Next, split your internal leg into smaller subnets for user laptops and backend data stores. Do not let every internal IP address reach sensitive production ports by default. Review your firewall rule tables every month to remove old IP entries and unused ports. Pair your network zones with controls that check and log each command in flight.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What are the three zones in a three legged firewall?
The three zones are the untrusted external internet, the semi-trusted DMZ, and the trusted internal network. Each zone connects to its own physical or virtual interface on the firewall.
How does a three legged firewall differ from a dual firewall setup?
A three legged firewall uses one device with three ports to manage the DMZ and internal network. A dual firewall setup uses two separate firewall devices to place the DMZ between them.
Can a three legged firewall inspect encrypted database queries?
No, a standard network firewall only checks IP addresses, ports, and basic transport headers. It cannot read or filter specific SQL queries or shell commands inside an encrypted session.