imPC@ndo IT

Guides / networking

A DMZ that was not a DMZ: segmentation without control

Two network cards and it worked: mail flowed, Edge was reachable. Every functional test would pass. Only an architectural question exposed the gap.

Microsoft’s documentation for the Edge Transport role assumes a perimeter network already exists. It tells you what to put in it, not how to build one. So this part of the lab had no reference to follow — and the first version, built without one, turned out to be a segmented network rather than a DMZ.

It worked. That is the interesting part.

What makes a DMZ a DMZ

A demilitarised zone is a network segment hosting systems exposed to an untrusted network, separated from both that network and the internal one. The definition needs three things:

  1. Separation of the segment from the internal network.
  2. A control device — a firewall or filtering router — that all traffic to and from the segment passes through.
  3. Explicit rules defining what may pass, in which direction, to which destination.

Separation alone is not enough. A segment that is isolated but uncontrolled is an isolated segment, not a DMZ.

The first version

The Edge Transport machine had two network adapters: an internal network towards Exchange, and a NAT adapter for internet access.

BEFORE — segmentation without control
  Edge --[internal network]-- Exchange
  Edge --[hypervisor NAT]---- Internet        ← no control here

That gives segmentation. It does not give a DMZ. Traffic towards the internet went through the hypervisor’s NAT engine with no inspection, no filtering and no logging. There was no point at which anyone could say “this packet is allowed, that one is not”, and no record of what had passed.

The rebuild

Everything to and from the perimeter segment now goes through the firewall, which is the element that makes the architecture a DMZ at all.

  • pfSense gets a third interface, OPT1, dedicated to the DMZ segment, at 192.168.20.1
  • the Edge machine is connected only to that segment, at 192.168.20.10
  • the standalone NAT adapter is removed
AFTER — a real DMZ
  Edge --[OPT1 192.168.20.x]-- pfSense --+-- LAN 192.168.10.x
                                         |
                                         +-- WAN / Internet

Every packet in and out now meets an explicit rule.

The rules, read as a design document

RulePortDestinationPurpose
Allow SMTP inbound25192.168.10.20Mail flow towards the internal server
Allow LDAP389192.168.10.10Initial phase of the Edge subscription
Allow LDAPS50636192.168.10.20Encrypted EdgeSync replication
Allow SMTP outbound25anyDelivery to the internet
Allow DNS53192.168.20.1Resolution through pfSense
Allow HTTPS to the CA443192.168.10.10Certificate request
Allow ICMP—anyNetwork diagnostics

The ping that would not answer

A second, identical symptom later resolved to the destination machine being switched off.

Together they make a diagnostic point worth keeping: in a network with a firewall, the first hypothesis for “no answer” should be “it is not allowed”, followed by “it is not on”. Promiscuous mode is a fascinating hypothesis, and it is fascinating precisely because it is technically sophisticated. Sophistication is not evidence of correctness.

Name resolution across the perimeter

The perimeter segment has no direct access to Active Directory’s DNS. The solution avoids hosts files entirely and is deliberately asymmetric:

  • Outward: pfSense’s DNS Resolver gets a domain override — queries for the internal domain go to 192.168.10.10, everything else resolves normally towards the internet.
  • Inward: a forward lookup zone for the perimeter domain is created on the internal DNS, with an A record for the Edge server, so Exchange can resolve its fully qualified name as EdgeSync requires.

What this generalises to

The lesson is not about Exchange, and not really about DMZs either.

A configuration can satisfy every functional test and still fail to do the thing it exists for. Segmentation and control look identical from the outside: in both cases the traffic reaches its destination. They differ only in whether anything decided that it should.

The question that separates them takes one sentence, and it is worth asking of any architecture that claims to enforce something: where, exactly, is the policy applied? If the answer is a component you can point to, the design holds. If the answer requires a pause, it probably does not.

This chapter has no counterpart in the Microsoft documentation, which treats the perimeter network as given. The rules, the topology and the diagnosis above come from the lab.