DMZ

The two-firewall pattern

Classic DMZ architecture uses two firewalls:

Internet
   │
   ▼
┌──────────────┐
│ External FW  │  Allows internet → DMZ on specific ports (80, 443, etc.)
└──────────────┘
   │
   ▼
┌──────────────┐
│  DMZ network │  Hosts web servers, mail relays, VPN gateways
└──────────────┘
   │
   ▼
┌──────────────┐
│ Internal FW  │  Allows DMZ → internal only on specific ports (DB, etc.)
└──────────────┘
   │
   ▼
Internal network (databases, workstations, internal apps)

The two-firewall design provides defense in depth: an attacker who compromises a web server in the DMZ still cannot reach internal systems directly. They must find another exploit to cross the internal firewall.

Modern implementations often use a single firewall with multiple zones (DMZ, internal, guest) configured as separate interfaces and policy zones. This achieves the same security outcome with simpler hardware.

What goes in a DMZ

• Web servers serving public websites.
• Mail servers accepting SMTP from the internet.
• FTP and SFTP servers for file exchange with external partners.
• VPN gateways terminating remote-worker tunnels.
• Reverse proxies fronting internal applications.
• Public DNS servers serving the company's domain.
• Bastion / jump hosts for SSH access from outside.

What does NOT go in a DMZ:

• Databases holding sensitive data — accessed only from DMZ apps via tight rules.
• Active Directory / identity systems.
• Internal applications not exposed to the public.
• User workstations.
• Backup systems and management infrastructure.

Firewall rules for a DMZ

The principle is least privilege in both directions:

Internet → DMZ

Allow only specific ports to specific DMZ servers:

• TCP 80/443 to web servers.
• TCP 25 to mail relays (with SPF and other anti-spam in front).
• UDP/TCP 500/4500 to VPN gateways.
• TCP 53 to public DNS servers.
• Everything else: deny.

DMZ → Internal

Allow only the connections DMZ services genuinely need:

• Web server can reach the application's database on the specific port and IP.
• Mail relay can reach internal Exchange server on SMTP.
• VPN gateway can reach internal RADIUS / AD on authentication ports.
• Everything else: deny.

This containment limits the blast radius of a DMZ compromise.

Consumer-router DMZ feature: different thing

Many consumer routers have a "DMZ Host" setting in their administration UI. This is a simplification that confuses many users. It does not create a separate network. It just forwards all unsolicited inbound traffic to one designated internal IP — effectively disabling the firewall for that one device.

Use cases where this was historically used:

• Gaming consoles needing many inbound ports for matchmaking.
• Security cameras with poor port-forwarding behavior.
• NAS devices with extensive remote-access features.

In 2026, modern consumer-grade port forwarding (and UPnP) makes the DMZ Host feature obsolete and dangerous. Use specific port forwarding rules instead. The DMZ Host feature exposes every port on the target device to the entire internet — a high security risk.

DMZ in cloud environments

Cloud equivalents of DMZ:

• Public subnets in a VPC — host load balancers and public-facing services.
• Private subnets — host backend application servers and databases.
• Security groups control which traffic flows between subnets — same role as DMZ firewall rules.

The pattern is identical: public-facing services on one network with restricted access; private resources on another network with stricter rules. The cloud terminology is "public subnet vs private subnet" rather than "DMZ vs internal," but the conceptual architecture is the same.

Frequently Asked Questions

What is the difference between consumer-router DMZ and enterprise DMZ?

Consumer-router DMZ is a simplified feature that exposes a single internal IP to all unsolicited inbound traffic — essentially turning off the firewall for that one device. Enterprise DMZ is a separate network segment with its own subnet, firewall rules on both sides (internet-to-DMZ and DMZ-to-internal), and specific services hosted there. The consumer feature uses the DMZ name loosely; it does not actually create a separate network.

Should I use my home router's DMZ feature?

Generally no. The consumer DMZ feature exposes a device to the entire internet — every port open. If you need inbound access to a specific service (game server, security camera, NAS), use port forwarding to that specific port instead. Port forwarding is more targeted and safer. DMZ should only be a last resort when port forwarding doesn't work for some specific reason.

Why is it called a DMZ?

From the military term — a buffer zone between two opposing territories where neither side has full control. In networking, the DMZ similarly sits between the "trusted" internal network and the "untrusted" internet, with restricted movement allowed in both directions. The name has stuck despite occasional industry effort to use less militaristic terms like "perimeter network" or "exposed services network."

What services typically go in a DMZ?

Web servers, mail servers, FTP servers, VPN gateways, reverse proxies, public DNS servers, and any other service that must accept connections from the internet. The principle: anything reachable from the internet sits in the DMZ, and if it gets compromised, the attacker still cannot directly reach internal systems — they must cross another firewall to do that. Backend databases, internal applications, and user workstations stay on the internal network behind the second firewall.