Public services in a DMZ — what to expose and what to keep private · OPNsense

The DMZ exists to host services that the Internet must reach. Not every service is appropriate for the DMZ — some are public-facing (web, mail, DNS), and some are internal-facing (databases, internal APIs, file shares). Putting the wrong service in the DMZ puts the wrong blast radius at risk. This lesson covers the standard DMZ services, the standard port-forwarding patterns, and the production mistakes of putting internal services in the DMZ.

The DMZ is not a place for everything that the operator cannot decide where to put. The DMZ is a place for services that the Internet must reach directly. Everything else belongs on the LAN, in a server VLAN, behind a reverse proxy, or in a private cloud.

The standard DMZ services

Three service categories belong in the DMZ in a classic deployment:

Web servers. HTTP (80) and HTTPS (443) for public websites. Reverse proxies that terminate TLS for back-end services. Static content servers.
Mail servers. SMTP (25) for inbound mail from the Internet. SMTP submission (587) for outbound mail from clients. IMAPS (993) and POP3S (995) if the operator offers mailbox access directly.
DNS servers. DNS (53/udp and 53/tcp) for authoritative resolution of public domains. The DNS server hosts the zone for example.com and answers queries from Internet resolvers.

These three categories are the canonical DMZ services. Every other service category should be evaluated against the question: “does the Internet need to reach this service directly?”.

Port-forwarding patterns

Each DMZ service has a standard port-forwarding pattern from the firewall’s WAN interface.

Web: HTTP/HTTPS

A web server in the DMZ listens on TCP 80 and 443. The firewall forwards inbound TCP 80 and 443 from the WAN IP to the DMZ web server IP.

Firewall → WAN IP 198.51.100.1:80 → DMZ web server 203.0.113.10:80
Firewall → WAN IP 198.51.100.1:443 → DMZ web server 203.0.113.10:443

In OPNsense: Firewall → NAT → Port Forward. The rule:

Field	Value
Interface	WAN
Protocol	TCP
Destination	WAN IP
Destination port	80 (HTTP) or 443 (HTTPS)
Redirect target IP	203.0.113.10
Redirect target port	80 or 443
Description	“Public HTTP/HTTPS to DMZ web”

The associated firewall rule (auto-generated) permits the traffic from any source to the DMZ web server on the destination port.

Mail: SMTP/Submission

A mail server in the DMZ listens on TCP 25 (SMTP) and TCP 587 (submission). The firewall forwards inbound TCP 25 and 587 from the WAN IP to the DMZ mail server IP.

Firewall → WAN IP 198.51.100.1:25 → DMZ mail server 203.0.113.20:25
Firewall → WAN IP 198.51.100.1:587 → DMZ mail server 203.0.113.20:587

The port-forwarding rule for SMTP and submission follows the same pattern as HTTP/HTTPS. The mail server is hardened against open-relay abuse (the SMTP server should not relay mail from arbitrary sources to arbitrary destinations).

DNS: Authoritative resolution

A DNS server in the DMZ listens on UDP 53 (queries) and TCP 53 (zone transfers, large responses). The firewall forwards inbound UDP 53 and TCP 53 from the WAN IP to the DMZ DNS server IP.

Firewall → WAN IP 198.51.100.1:53/udp → DMZ DNS server 203.0.113.30:53
Firewall → WAN IP 198.51.100.1:53/tcp → DMZ DNS server 203.0.113.30:53

The DNS server hosts the zone for example.com and answers queries from Internet resolvers. The DNS server is hardened against amplification attacks (the server should not allow recursive queries from arbitrary sources — only authoritative queries for the zone it hosts).

Read-only / Safeport forwards— The PF redirection rules for a DMZ with web, mail, and DNS. Each rule forwards inbound traffic on a specific port from the WAN interface to a specific DMZ server. The (igb0) syntax refers to the WAN IP dynamically (it is replaced at runtime with the actual WAN IP). The destination port is preserved — port 80 on the firewall forwards to port 80 on the web server. If the operator wants to expose a different port externally (e.g. 8443 externally forwarding to 443 internally), the rule specifies both ports.

$ pfctl -s nat | grep -E 'rdr|198.51.100.1'

rdr on igb0 inet proto tcp from any to (igb0) port = 80 -> 203.0.113.10 port 80
rdr on igb0 inet proto tcp from any to (igb0) port = 443 -> 203.0.113.10 port 443
rdr on igb0 inet proto tcp from any to (igb0) port = 25 -> 203.0.113.20 port 25
rdr on igb0 inet proto tcp from any to (igb0) port = 587 -> 203.0.113.20 port 587
rdr on igb0 inet proto tcp from any to (igb0) port = 53 -> 203.0.113.30 port 53
rdr on igb0 inet proto udp from any to (igb0) port = 53 -> 203.0.113.30 port 53

Illustrative output

Six redirection rules cover the standard DMZ services. The pattern is consistent: inbound from any source to the WAN IP on a specific port, redirected to a specific DMZ server IP on the same port (or a different port if the operator has chosen to remap).

Services that do not belong in the DMZ

A list of services that are commonly misplaced in the DMZ, and where they belong instead.

Databases

MySQL, PostgreSQL, MongoDB, Redis, Elasticsearch. These services have no reason to be reachable from the Internet. They are internal services used by application servers.

If the application server is in the DMZ, it talks to the database. The database belongs on the LAN, not the DMZ. The application server in the DMZ reaches the database via an explicit firewall rule (DMZ → LAN, narrow).

Internal APIs

APIs used by internal applications — HR systems, ERP systems, internal tooling. These APIs are not public-facing. They belong on the LAN or in a private cloud.

If an internal API must be reachable from the DMZ (because a public-facing application calls it), the API itself can be in the DMZ, or the public-facing application can call the API via an explicit firewall rule. Either way, the API’s blast radius must be considered.

File shares

NFS, SMB, AFP. File shares are inherently internal. They have no business being reachable from the Internet, and they have no business being in the DMZ.

A file share in the DMZ is a misconfiguration. A file share that is reachable from the DMZ is also a misconfiguration. File shares belong on the LAN, with explicit rules for any cross-VLAN access.

Internal monitoring endpoints

SNMP, Prometheus exporters, internal health endpoints. These are for monitoring tools, not for the Internet. They belong on the LAN.

If a DMZ service needs monitoring, the monitoring agent on the DMZ service scrapes its own metrics and exports them to a monitoring server on the LAN via an explicit rule. Or the monitoring server polls the DMZ service via an explicit rule. Either way, the monitoring traffic is narrow and explicit.

A database in the DMZ is a compromise waiting to happen

The operator puts a database in the DMZ because the web-facing application in the DMZ needs database access. The database is reachable from the web server (and possibly from other DMZ hosts). A compromise of any DMZ host now has direct access to the database.

The right pattern: keep the database on the LAN, write an explicit firewall rule permitting the DMZ web server to reach the LAN database on TCP 3306 (or 5432 for PostgreSQL). The database compromise is now constrained to “compromise a DMZ host AND find a way through the firewall rules” rather than “compromise any DMZ host”.

If the database absolutely cannot be on the LAN (compliance reasons, latency, network architecture), the alternative is a database in the DMZ that is itself hardened, monitored, and isolated from the rest of the DMZ. This is a worse trade than LAN placement but better than unrestricted DMZ placement.

The “expose only what is needed” discipline

The DMZ rule of thumb: every service that is reachable from the Internet must justify its existence. The justification is the business need — the public must be able to reach this service.

A DMZ with three services (web, mail, DNS) is the right size for most small estates. A DMZ with ten services is a sign that the operator has not been disciplined about what belongs in the DMZ.

The discipline:

List every public-facing service. Start from the public DNS records. Every A record pointing to a public IP is a candidate.
Justify each service. For each A record, the business reason. “Because someone set it up five years ago” is not a justification.
Remove unjustified services. If a service has no current business justification, decommission it. Public-facing services that are not maintained are vulnerabilities waiting to be exploited.
Document the remaining services. A network registry entry for each public-facing service: IP, port, business owner, last review date.

Hardening the DMZ service

A DMZ service is reachable from the Internet. The hardening requirements are higher than for an internal service:

Patch promptly. Critical vulnerabilities in web servers, mail servers, and DNS servers are exploited within hours of disclosure.
Run with minimal privileges. The service process should not run as root. The service should not have write access to system directories.
Use TLS everywhere. HTTP redirects to HTTPS. SMTP uses STARTTLS or implicit TLS. DNS uses DoT or DoH where possible.
Rate limit. Rate-limit inbound connections to prevent abuse. The firewall can do this; the application can do it; both is better.
Log to a remote destination. Local logs can be wiped by an attacker. Remote logging to an immutable destination (write-once storage, a separate logging server) preserves the evidence.
Monitor actively. The DMZ service should be in a monitoring system that alerts on anomalies. A compromised DMZ service that goes silent is the worst case.

Read-only / Safedmz listen sockets— The listening sockets on the DMZ servers. The web server listens on 203.0.113.10:80 and 443. The mail server listens on 203.0.113.20:25 and 587. The DNS server listens on 203.0.113.30:53. There are no other listening sockets on the DMZ — every service that is reachable from the Internet corresponds to a deliberate bind. A surprise listener (e.g. a database port that the operator forgot to bind to localhost) is an incident signal.

$ netstat -an | grep -E 'LISTEN' | grep -E '203.0.113'

tcp4   0   0  203.0.113.10.80    *.*    LISTEN
tcp4   0   0  203.0.113.10.443   *.*    LISTEN
tcp4   0   0  203.0.113.20.25    *.*    LISTEN
tcp4   0   0  203.0.113.20.587   *.*    LISTEN
tcp4   0   0  203.0.113.30.53    *.*    LISTEN

Illustrative output

The five listening sockets correspond to the five exposed services. Any other listening socket is a finding — the operator may have accidentally started a service that is not supposed to be public.

How the firewall port-forwards a packet to a DMZ server

A packet from the Internet arrives on the WAN interface destined for the firewall’s WAN IP on a forwarded port (e.g. TCP 443). The packet flow:

PF evaluates the rules on the WAN interface. The packet matches the auto-generated rule that permits the forwarded port.
PF applies the NAT redirection: the destination IP is rewritten from the firewall’s WAN IP to the DMZ server IP. The destination port is preserved (unless the operator remapped it).
PF creates state tracking both the original (WAN IP) and the rewritten (DMZ server IP) addresses.
The kernel routes the packet to the DMZ interface based on the rewritten destination IP.
The packet exits on the DMZ interface with the destination IP of the DMZ server.

For the return traffic, the state is matched, the destination IP is rewritten back to the WAN IP, and the packet leaves on the WAN interface. The DMZ server sees the original source IP (the Internet client); the Internet client sees the firewall’s WAN IP as the source. The DMZ server’s identity is not exposed to the Internet.

A design example

For a small e-commerce site:

DMZ (203.0.113.0/24):
  Web server            203.0.113.10   (HTTPS, reverse proxy)
  Application server    203.0.113.20   (HTTPS, internal API for the web)
  Database server       203.0.113.30   (NO Internet exposure, only 203.0.113.20 can reach it on 5432)

Firewall port-forwards:
  WAN:443 → 203.0.113.10:443  (HTTPS to web/reverse proxy)

Firewall rules:
  WAN → 203.0.113.10:443       permit (HTTPS)
  WAN → 203.0.113.20:443       deny
  WAN → 203.0.113.30:5432      deny
  203.0.113.20 → 203.0.113.30:5432  permit (app to DB)
  203.0.113.0/24 → LAN         deny (default)
  203.0.113.0/24 → Internet    permit (updates, OCSP)

The application server and the database are both in the DMZ. The application server is reachable from the application server only; the database is reachable from the application server only. The default deny on DMZ → LAN prevents lateral movement to internal services.

This is the “DMZ-friendly” pattern for e-commerce. The web server (reverse proxy) is the only service with Internet exposure; the application server and database are internal to the DMZ.

Summary

The DMZ holds services the Internet must reach directly: web, mail, DNS. Other services belong elsewhere.
Port-forwarding patterns: WAN:port → DMZ server:port for each public-facing service.
Databases, internal APIs, file shares, and internal monitoring endpoints do not belong in the DMZ.
The discipline is “expose only what is needed” — every public-facing service must justify its existence.
DMZ services require higher hardening: prompt patching, minimal privileges, TLS, rate limiting, remote logging, active monitoring.