Single Firewall DMZ
A single firewall dmz uses one device with three network ports to isolate public servers. This setup separates the internet, the public zone, and your private local network. Teams often choose this design to reduce hardware costs and simplify rule management. Still, broad rules between zones can expose private databases and internal servers to risk. How a single firewall dmz routes traffic This design is often called a three-legged firewall setup by network teams. The device uses at least thr
Single Sign-On (SSO) + Firewall Configuration: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
A single firewall dmz uses one device with three network ports to isolate public servers. This setup separates the internet, the public zone, and your private local network. Teams often choose this design to reduce hardware costs and simplify rule management. Still, broad rules between zones can expose private databases and internal servers to risk.
How a single firewall dmz routes traffic
This design is often called a three-legged firewall setup by network teams. The device uses at least three separate network ports to direct all traffic. One port links to the outside internet ISP line. The second port links to the public zone where web servers run. The third port links to the private network where internal data lives.
Every packet between these three zones must pass through the central rule engine. Network admins write directional rules to control which hosts can talk to each other. Outside users can reach the web servers in the public zone over web ports. Outside users cannot send traffic straight into the private zone.
If a web app needs customer data, the firewall permits a specific internal path. The public server sends a request through the device to the private database port. The firewall checks the source IP, destination IP, and port number before forwarding packets. Stateful inspection tracks active sessions and blocks unrequested inbound traffic from the internet.
What the perimeter solves and what it leaves open
A three-legged perimeter blocks unauthorized network scans from the public internet very well. It stops attackers from reaching internal hosts straight from the outside world. It also gives small teams a single place to update network block lists. You do not need to buy or maintain two separate physical firewall appliances.
Still, network rules only check IP addresses and ports when a session starts. Once a developer or app opens a valid path, the firewall steps back. It cannot read the database queries or shell commands running inside an encrypted tunnel. If an engineer logs in with a shared role, the firewall logs one IP.
Single Sign-On (SSO) + Firewall Configuration: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
A single hardware unit also creates a single point of failure for security. One bad rule change can expose the entire private zone to the public subnet. Also, broad developer access into the public or private zone creates blind spots. Network rules decide who can open a port, not what queries they run next. When a query returns emails, phone numbers, or card numbers, the firewall passes raw data.
Best practices for managing zone rules
Start with a default deny policy on every network port on the device. Only open the exact ports required for your web apps to serve traffic. Avoid using any-to-any rules when linking the public zone to the private zone. Restrict management ports so admins cannot log into the firewall from the internet.
Review your rule table every month to remove old server paths and unused ports. Group servers by function so you can read and audit policies with ease. Keep database servers in the private zone rather than placing them in the DMZ. Even with tight network rules, you still need visibility into individual user sessions.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev sits inline in the wire protocol beside those services as an open-source proxy, a sidecar for your Postgres or API. On every query an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human review.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
What is the difference between a single and dual firewall DMZ?
A single setup uses one device with three ports to divide all zones. A dual setup uses two separate firewalls placed in front and behind the DMZ. The dual approach costs more money but separates public and private rule sets.
Should databases live inside the DMZ subnet?
No, databases should stay inside the private internal zone for safety. Web apps in the DMZ should talk to the database over restricted internal ports. Placing databases in the public zone makes them an easy target during a breach.
Why are firewall rules not enough for developer database sessions?
Firewall rules only check the source IP address and the destination port number. They do not inspect the actual SQL statements or shell commands a user runs. They also cannot rewrite sensitive fields like card numbers or emails in query results.