DMZ architecture and purpose — the buffer zone between Internet and LAN

A DMZ (demilitarised zone) is a buffer network that sits between the Internet and the LAN. Public-facing services — web servers, mail servers, DNS, reverse proxies — live in the DMZ so that a compromise of those services does not give the attacker a path to the LAN. The firewall is the gatekeeper: it permits Internet traffic to reach specific services in the DMZ, and it denies the DMZ from reaching the LAN.

This lesson covers what a DMZ is, why it exists, the classic three-homed firewall topology that implements it, and the modern variants (reverse proxy, cloud DMZ, micro-segmentation) that have evolved as the threat landscape has changed.

The threat model

The DMZ exists because of a specific threat: a public-facing service is compromised. The compromise may be through a vulnerable application, a credential leak, a supply-chain attack, or any other vector. The question the operator must answer is: when this happens, what does the attacker get?

Without a DMZ, the answer is “everything on the same subnet as the public-facing service”. A web server on the LAN that gets compromised gives the attacker a foothold on the LAN — access to file shares, internal applications, database servers, monitoring, the firewall itself if reachable.

With a DMZ, the answer is “the DMZ and whatever the DMZ can reach by firewall rule”. The DMZ is on a separate subnet; the firewall denies the DMZ from reaching the LAN except by explicit, narrow permits. A compromised web server in the DMZ cannot directly reach the LAN; the attacker has to find a vulnerability in the firewall or a permitted flow to pivot.

The classic three-homed firewall topology

The classic implementation:

    Internet
        |
        |
   [WAN interface]
        |
        |
  +-----+-----+
  |  OPNsense |
  |  Firewall |
  +-----+-----+
        |
   [DMZ interface]
        |
        |
   +---+---+---+
   |   |   |   |
  Web Mail DNS  Bastion
   |   |   |   |
        |
   [LAN interface]
        |
   +---+---+---+
   |   |   |   |
  PCs  Servers  Storage

Three interfaces on the firewall:

• WAN. Connects to the Internet. The ISP hands the firewall a public IP (or the firewall is behind an ISP gateway with a public IP via NAT).
• DMZ. Connects to a switch that carries public-facing services. The firewall IP on the DMZ is the gateway for the DMZ subnet.
• LAN. Connects to the internal network. The firewall IP on the LAN is the gateway for the LAN subnet.

The rules:

• Internet → WAN → DMZ. Permit inbound from Internet to specific DMZ IPs on specific ports (web on 80/443, mail on 25/587, DNS on 53/udp).
• Internet → WAN → LAN. Block. The Internet cannot reach the LAN directly.
• DMZ → LAN. Block by default. Permit only specific flows (DMZ to internal logging server, DMZ to update server).
• LAN → DMZ. Permit only specific flows (LAN to DMZ monitoring, LAN to internal-facing services on DMZ).
• LAN → Internet. Permit outbound from LAN.
• DMZ → Internet. Permit outbound for updates, OCSP, and other services the DMZ needs to reach on the Internet.

The topology is the foundation of DMZ architecture. Every modern variant is a modification or refinement of it.

$ ifconfig | grep -E 'inet|UP' | grep -v 'inet6' | head -10

igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      inet 198.51.100.1 netmask 0xffffffe0 broadcast 198.51.100.31
igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      inet 192.0.2.1 netmask 0xffffff00 broadcast 192.0.2.255
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
      inet 203.0.113.1 netmask 0xffffff00 broadcast 203.0.113.255

The three interfaces each have a different subnet, and each subnet has a different purpose. The firewall’s job is to enforce the rules between them.

Modern variants

The classic three-homed topology is still the conceptual foundation, but production deployments use variants.

Variant 1: Reverse proxy DMZ

The Internet reaches a reverse proxy (HAProxy, NGINX, cloud load balancer). The reverse proxy terminates TLS, inspects requests, and forwards to back-end servers. The back-end servers may be in the DMZ, on the LAN, or in a private cloud.

Internet → Reverse Proxy → Back-end servers
                  ↑
                  DMZ (proxy is here)

The reverse proxy pattern shifts the public-facing surface from many services to one. The reverse proxy is hardened, monitored, and patched aggressively; the back-end servers are not directly reachable from the Internet.

Variant 2: Cloud DMZ

For cloud deployments, the “DMZ” is a subnet in a VPC (Virtual Private Cloud) with firewall rules (security groups, network ACLs) that permit Internet traffic to specific services. The on-premise firewall connects to the cloud DMZ via VPN or direct connect.

Internet → Cloud Load Balancer → Cloud DMZ → Cloud Servers
                                       ↑
                              VPN from on-premise

The cloud DMZ is the same architectural concept as the classic DMZ — a buffer subnet with firewall rules — but implemented with cloud-native tools.

Variant 3: Micro-segmentation

Some modern estates replace the DMZ with per-service segmentation. Each service gets its own micro-segment with explicit firewall rules; there is no single “DMZ” subnet.

Internet → Per-service firewall → Service (isolated)

The micro-segmentation pattern is more flexible than the classic DMZ but more complex to operate. It is the natural extension of the VLAN segmentation patterns covered in Part XIV.

Variant 4: Zero-trust DMZ

A zero-trust DMZ assumes no implicit trust. Every flow is authenticated and authorised, regardless of source. The DMZ becomes a layer of identity-aware proxies rather than a subnet of services.

The zero-trust pattern requires identity-aware proxies (like Cloudflare Access, Pomerium, or Twingate) in front of every service. The DMZ is a logical concept, not a subnet.

Why the DMZ exists: the threat model in detail

The DMZ addresses specific threat scenarios:

• Application vulnerability. A web application has a vulnerability that allows remote code execution. The attacker compromises the web server. Without a DMZ, the attacker is on the LAN. With a DMZ, the attacker is in the DMZ and the firewall blocks lateral movement.
• Credential leak. An operator’s credentials for a public-facing service are leaked. The attacker authenticates and gains access. Without a DMZ, the credentials give access to the LAN. With a DMZ, the credentials give access only to the DMZ service.
• Supply-chain compromise. A library used by the public-facing service is compromised. The attacker gains the same access as the service. Without a DMZ, the attacker is on the LAN. With a DMZ, the attacker is in the DMZ.
• Insider threat. A malicious operator with access to the DMZ service uses that access to attack other systems. Without a DMZ, the operator can reach the LAN. With a DMZ, the operator’s reach is limited to the DMZ.

The DMZ does not eliminate these threats; it limits their blast radius. A compromised DMZ service is bad; a compromised LAN is worse.

The “transparent DMZ” anti-pattern

Some ISP gateways and consumer firewalls offer a “DMZ host” feature: a single internal IP that receives all inbound traffic from the Internet. This is sometimes called a “transparent DMZ”.

The transparent DMZ is not a DMZ. The single internal host is on the LAN; the firewall forwards all inbound traffic to it. A compromise of that host compromises the LAN. The “DMZ” label is misleading.

The correct DMZ implementation: a separate subnet, a separate firewall interface, and explicit firewall rules. The transparent DMZ is a single point of failure and a single point of compromise.

A first design

For a small estate that needs public web and mail:

VLAN 100 — DMZ         203.0.113.0/24
  Web server            203.0.113.10   (HTTPS on 443, HTTP on 80)
  Mail server           203.0.113.20   (SMTP on 25, submission on 587)
  DNS server            203.0.113.30   (DNS on 53)

Firewall interfaces:
  igb0 (WAN)            198.51.100.1/27   (ISP public IP)
  igb1 (LAN)            192.0.2.1/24      (internal)
  igb2 (DMZ)            203.0.113.1/24    (DMZ gateway)

Firewall rules (simplified):
  WAN → DMZ web     permit tcp from any to 203.0.113.10 port 80,443
  WAN → DMZ mail    permit tcp from any to 203.0.113.20 port 25,587
  WAN → DMZ DNS     permit udp from any to 203.0.113.30 port 53
  DMZ → LAN         deny all (default)
  LAN → DMZ         permit tcp from jump_host to 203.0.113.0/24 port 22 (admin SSH)
  DMZ → Internet    permit tcp from 203.0.113.0/24 to any port 80,443 (updates, OCSP)

The three-homed firewall is configured; the rules implement the threat model. The DMZ-to-LAN default deny is the foundation of the segmentation.

Summary

• A DMZ is a buffer network that sits between the Internet and the LAN. Public-facing services live in the DMZ; a compromise of those services does not give the attacker a path to the LAN.
• The classic three-homed firewall has WAN, DMZ, and LAN interfaces. The DMZ-to-LAN default deny is the foundation of the segregation.
• Modern variants include reverse proxy DMZ, cloud DMZ, micro-segmentation, and zero-trust DMZ. The concept is the same; the implementation differs.
• The biggest mistakes are DMZ-to-LAN permits for convenience, transparent DMZ (DMZ host), and treating the firewall itself as the DMZ.