Network DMZ & Firewall Architecture

What this diagram shows

This diagram shows a layered network security architecture that isolates public-facing services from internal assets using two firewalls and a demilitarized zone (DMZ). Traffic flows from the internet through an edge firewall, then into the DMZ where public services run, then through a second internal firewall to reach trusted networks. Intrusion detection systems monitor suspicious activity across boundaries, and a VPN gateway handles authenticated remote access to internal resources. This separation ensures that if an external attacker compromises a DMZ service, they cannot immediately reach backend databases, user workstations, or core infrastructure.

Key components

• Edge Firewall — Filters internet traffic before it enters the network, blocking malicious packets and enforcing initial ingress rules based on source, destination, and protocol.
• DMZ Segment — Isolated network zone hosting publicly accessible services such as web servers, mail relays, and DNS resolvers that require external connectivity.
• Internal Firewall — Second perimeter that controls traffic from the DMZ into trusted internal networks, enforcing strict allow-lists for backend communication.
• IDS/IPS Sensor — Inspects traffic flows at the network boundary to detect and optionally block exploit signatures, anomalous behaviour, and known attack patterns.
• Remote Access VPN Gateway — Authenticates and encrypts connections from external users, tunneling traffic into the internal network only after credential verification.
• Internal Network Segment — Protected trust zone containing databases, file servers, user workstations, and management interfaces separated by firewall rules from the DMZ.

When to use it

Use this architecture for any organization operating customer-facing services online. It applies to e-commerce platforms, SaaS applications, web portals, and hybrid infrastructures where external users must access some systems but not others. Mandatory for regulated industries (financial services, healthcare, government) where data isolation and audit trails are required. Also appropriate when your team has capacity to manage two firewall instances and monitor IDS alerts.

Common mistakes

• Placing internal databases or administrative consoles in the DMZ on the assumption that firewalls make them safe to expose directly.
• Failing to restrict DMZ-to-internal firewall rules, allowing any DMZ service to freely query backend systems and thus spreading breach impact.
• Not monitoring or acting on IDS alerts, leaving the detection layer as a silent logger rather than an active defence that informs incident response.

Adapting it to your system

Replace the generic DMZ services box with your actual systems: web server IP ranges, mail server hostnames, DNS servers, or load balancers. Specify the internal firewall rules by listing which DMZ hosts can reach which backend systems (for example, web tier can query database on port 3306, but not SSH). Name your VPN solution if using Cisco ASA, pfSense, or cloud-native endpoints, and indicate the identity provider it uses. Add your SOC or monitoring tool as the consumer of IDS logs. Adjust segment names to match your organization (production, development, admin).