A Practical Guide to Network Segmentation

When preparing for a security audit, one concept keeps surfacing:
“You need a DMZ.”

At first, it sounds simple.
Split the network:

DMZ for exposed services (e.g., web, API)
Internal for sensitive systems (e.g., DB, ERP)

But real infrastructure isn’t always that clean.

In our case, our database needed to call external APIs.
So just isolating the DB behind a firewall wasn't enough.
We had to rethink the intention behind a DMZ—not just the architecture.

🔐 Why a Dual-Firewall Structure Still Works

We implemented two firewalls for layered security:

FW1 (External Firewall) – Controls Internet ↔ DMZ
FW2 (Internal Firewall) – Controls DMZ ↔ Internal systems

This created a double barrier.
If one zone gets compromised, the core systems are still protected.

No external request can reach internal servers without passing two firewalls.

🌐 Internal Systems Need to Talk to the Internet. Now What?

Enter SNAT (Source NAT).

We wanted our internal servers (using private IPs) to safely access the Internet—
without exposing them directly.

Our solution:

Internal systems stay on 10.x.x.x
Outbound traffic is routed through FW1
FW1 applies SNAT → converts traffic to a public IP
Inbound connections remain blocked unless explicitly allowed

This gives us outbound connectivity with zero inbound exposure.

🧱 Physical DMZ Switch? Not Required.

Instead of adding another physical switch, we used VLANs to create logical zones:

VLAN 10 → DMZ
VLAN 20 → Internal
VLAN 30 → Management

With proper ACLs and firewall rules, VLANs offer solid isolation—as long as it's documented and enforced.

📐 Network Diagram

(DMZ between FW1 and FW2, SNAT applied at FW1)

✅ Summary

DMZ is not about hardware—it's about control and containment
Dual firewalls enable layered enforcement and accountability
SNAT gives you secure outbound Internet access from internal zones
VLAN-based segmentation is perfectly valid if managed properly

Do You Really Need a Physical DMZ?