# Designing an Enterprise Network

> How to grow from a single home router into a network that holds up: segmentation to limit blast radius, scaling and redundancy to survive load and failure, and a security edge - firewalls, DMZ, VPN, zero-trust - that keeps the inside safe.


---

# Designing an Enterprise Network

You already understand a home network: one router does everything - hands out addresses, connects every device to every other, and is the single door to the internet. That's perfect for a dozen devices and one household that trusts each other. The moment you have hundreds of machines, departments that should *not* see each other's traffic, services the public must reach, and an outage that costs real money, that one-router picture stops working - usually at the worst possible time.

This guide is about the leap: not "buy a bigger router," but the handful of design ideas that let a network hold up. How you carve it into pieces so one bad day doesn't become a bad week, how you keep it standing under load and hardware failure, and how you build an edge that lets the world reach what it should while keeping it away from what it shouldn't. You'll come out able to look at a real diagram and know why each box is where it is.

We assume you're comfortable with addresses, DNS, and ports. If any of that is fuzzy, the related guides at the bottom will steady you first.

## How to read this

- **Designing or reviewing a real network right now?** Each phase stands on its own - jump to the one you need. But the order is the *argument*: segmentation makes scaling sane, and both make the security edge possible.
- **Want it to finally make sense?** Read in order. We build one network across three phases, adding a layer of design thinking each time, and every phase ties back to the one before it.

## The phases

1. **[Segmentation](01-segmentation.md)** - why you carve one big network into pieces. Subnets and a calm take on CIDR and address planning, VLANs for separating departments on shared hardware, and the real prize: a problem in one zone stays *in* that zone.
2. **[Scaling & Reliability](02-scaling-and-reliability.md)** - keeping it up under load. Load balancers that spread traffic, redundancy so no single cable or box can take you down, and the quiet infrastructure services (DHCP, internal DNS) every real network leans on.
3. **[Security & the Edge](03-security-and-the-edge.md)** - the perimeter and beyond. Firewalls and stateful filtering, the DMZ that holds public-facing services apart from your insides, VPNs for secure remote access, and a nod to zero-trust - the modern admission that the perimeter alone was never enough.

> Deliberately deferred to follow-up guides: routing protocols (OSPF, BGP), spanning-tree and switch-loop mechanics, SD-WAN, and vendor-specific configuration. This guide gives you the *design model*; those guides give you the machinery.

## Related guides

- [The TCP/IP Model](/guides/tcp-ip-model) - the layered model every device on this network speaks.
- [Your Home Network](/guides/your-home-network) - the one-router starting point we're scaling up from.
- [IP, DNS, and Ports](/guides/ip-dns-and-ports) - addresses, names, and the ports services listen on.


---

# Segmentation

Keeping a growing network flat - one address range, every device able to reach every other - feels simple. It's also the source of nearly every scaling pain ahead: broadcast chatter that grows with every device, the printer in accounting reachable from guest Wi-Fi, one compromised laptop that can knock on every server's door.

Segmentation fixes all three: **a network you can't divide is a network you can't contain.** Split one big network into deliberate zones, and a problem in one zone - a traffic flood, a misconfigured host, an attacker's foothold - stays there instead of becoming everyone's problem.

## Why a flat network stops scaling

Every device on a flat network shares one **broadcast domain** - a region where a message addressed "to everyone here" reaches every device. Broadcasts are how devices find each other (ARP asking "who has this address?", DHCP discovery). Fine with twenty devices; with two thousand, everyone is constantly interrupted by traffic meant for someone else, and everyone is, by default, reachable by everyone else.

📝 **Terminology.** *Broadcast domain* = the set of devices that receive each other's broadcast traffic. *Blast radius* = how far damage spreads when something goes wrong - segmentation exists to shrink it.

Two costs grow together on a flat network: **contention** (shared broadcast traffic and bandwidth slow everyone down) and **exposure** (flat means reachable, and reachable means attackable - one foothold sees the entire estate). You don't fix either with faster hardware. You fix them by dividing the network.

## Subnets - dividing by address

A **subnet** is a slice of address space the network treats as one group: carve a large IP range into smaller ranges, and each becomes its own logical network. Traffic *within* a subnet flows directly; traffic *between* subnets goes through a router - exactly the choke point where you decide "can sales reach finance? no."

📝 **Terminology.** *Subnet* = a logically subdivided range of an IP network. *Router* = forwards traffic *between* networks, unlike a switch, which forwards *within* one.

You'll see subnets written like `10.20.0.0/24`. That `/24` is **CIDR notation**, answering one question: how many leading bits are fixed as the network identity, leaving the rest for hosts? An address is 32 bits; the number after the slash names how many belong to the network, the remainder to devices.

```text
   10.20.0.0/24   →  first 24 bits = network, last 8 bits = hosts
                     ┌──────────────────────────┬──────────┐
                     │   network: 10.20.0        │ host: .x │
                     └──────────────────────────┴──────────┘
                     usable host addresses: .1 through .254   (256 minus network + broadcast)

   smaller /26     →  26 network bits, 6 host bits  →  62 usable hosts per subnet
   larger  /16     →  16 network bits, 16 host bits →  ~65,000 hosts (usually too big to want)
```

Rule of thumb: **a bigger number after the slash means a smaller subnet.** A `/24` gives 254 usable addresses - comfortable for one department. The two reserved addresses are the network address itself (all host bits `0`) and the broadcast address (all host bits `1`).

A Linux host can tell you which subnet it considers itself part of:

```console
$ ip -4 addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...
    inet 10.20.0.37/24 brd 10.20.0.255 scope global eth0
```

*What just happened:* this host is `10.20.0.37`, and `/24` tells it everything from `10.20.0.1` to `10.20.0.254` is local - reachable directly. Anything outside that range (say `10.30.0.5`) has to go through the router. `brd 10.20.0.255` is this subnet's broadcast address.

**Address planning - the part people skip and regret.** Decide a scheme for the *whole* organization before assigning a single subnet; renumbering later is painful once devices, firewall rules, and DNS entries depend on the old ranges. A scheme that reads at a glance pays off for years:

```text
   10.<site>.<purpose>.0/24

   10.10.10.0/24   site 10 (HQ),  purpose 10 = user workstations
   10.10.20.0/24   site 10 (HQ),  purpose 20 = servers
   10.10.30.0/24   site 10 (HQ),  purpose 30 = printers / IoT
   10.20.10.0/24   site 20 (branch), purpose 10 = user workstations
```

Now an address tells you what it is - `10.20.30.x`? Branch site, printers. That legibility beats squeezing addresses tightly, so leave room to grow: the private ranges (`10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`) are generous. Plan for the company you'll be.

With this in place, keeping finance unreachable from guests is one rule at the router between two subnets, not a per-device chore.

## VLANs - dividing without rewiring

Subnets divide by *address*. But in a real building, the accountant and the engineer often plug into the same switch, sometimes the same row of ports - you can't run separate cabling for every group.

A **VLAN** (Virtual LAN) lets one physical switch behave as several separate switches. Tag each port or device as belonging to a VLAN, and the switch refuses to let traffic cross between VLANs on its own, even though every cable runs into the same box.

📝 **Terminology.** *VLAN* = a logical LAN segment defined in switch configuration rather than physical wiring. *Tag* = an 802.1Q label added to a frame identifying its VLAN, surviving across switches.

Map each VLAN to a subnet - VLAN 10 carries `10.10.10.0/24` (workstations), VLAN 20 carries `10.10.20.0/24` (servers) - and both ride the same hardware without mixing. Traffic that does need to cross is forced up to a router, where you decide.

```mermaid
flowchart TD
  switch[One physical switch]
  switch --> v10[VLAN 10<br/>workstations]
  switch --> v20[VLAN 20<br/>servers]
  switch --> v30[VLAN 30<br/>printers / IoT]
  v10 --> router[ROUTER<br/>the only path between VLANs -<br/>and where you enforce rules]
  v20 --> router
  v30 --> router
```

⚠️ **Gotcha.** A VLAN is a *configuration*, not a physical wall. A misconfigured trunk port, a port left in the wrong VLAN, or weak switch management access can leak traffic between VLANs you believed were isolated. Treat VLAN boundaries as real security boundaries only when the switch's management plane is locked down - otherwise an attacker steps over the line by reconfiguring the switch.

When a new IoT device shows up - a smart TV, a badge reader, a camera - don't trust it on the laptops' network. Drop it on the IoT VLAN, where it reaches only what it needs. If that device turns out to have a backdoor, the blast radius is one VLAN, not the company.

## Bringing the two together

Subnets and VLANs aren't competitors - the same dividing line drawn at two layers. The VLAN separates traffic on the wire; the subnet separates addresses; map one to the other so a "zone" means the same thing at the switch port and at the IP address. The router between zones is where both lines converge, and where the next two phases hang their work.

```mermaid
flowchart TD
  ws[WORKSTATIONS<br/>VLAN 10 · 10.10.10.0/24]
  srv[SERVERS<br/>VLAN 20 · 10.10.20.0/24]
  guest[GUEST / IoT<br/>VLAN 30 · 10.10.30.0/24]
  fw[ROUTER / FIREWALL<br/>every cross-zone packet is a decision]
  ws --> fw
  srv --> fw
  guest --> fw
```

## Recap

1. A **flat network** doesn't scale: broadcast **contention** grows with every device, and flat means every host is **reachable** - and attackable - by every other.
2. **Segmentation** carves the network into zones so a failure or breach has a small **blast radius** instead of taking down everything.
3. **Subnets** divide by address; **CIDR** (`/24`, `/26`…) says how many leading bits name the network, leaving the rest for hosts. A bigger slash number means a smaller subnet.
4. **Plan addresses for the whole org up front** with a legible scheme (`10.<site>.<purpose>.0/24`) - renumbering later is painful.
5. **VLANs** divide one physical switch into several logical LANs, so you separate groups without separate cabling. Map one VLAN to one subnet per zone.
6. A VLAN is only as strong as the switch's management security - treat it as a real boundary only when the switch itself is locked down.
7. The **router between zones** is where every cross-zone decision lives - and where scaling and security build next.

Next, keeping all those zones standing when traffic surges and hardware fails: **scaling and reliability**.


---

# Scaling & Reliability

You've divided the network into clean zones. Now: what happens when one gets busy, or a piece of it dies? A home network shrugs - reboot the router, wait a minute. An enterprise can't: a traffic surge shouldn't take a service down, and one failed switch, cable, or power supply shouldn't take the business down.

The mental model: **anything you depend on, you must be able to lose.** Reliability means assuming each component will eventually fail and arranging for the network to keep working anyway - by spreading work across many things, and by having more than one of everything that matters. Underneath both sit the quiet services that make the network self-operating.

## Load balancers - spreading the work

A **load balancer** sits in front of a group of identical servers and distributes incoming requests across them. To the outside world there's one address to talk to; behind it, the balancer chooses which real server handles each request.

The common assumption is that load balancing is purely about *performance* - "too much traffic for one server, so we added a balancer." That's half of it. The bigger half is *availability*: the balancer constantly checks which backends are healthy and stops sending traffic to one that's crashed or being updated. A server can go down for maintenance at 2pm and nobody files a ticket.

📝 **Terminology.** *Backend/upstream* = one of the real servers behind the balancer. *Health check* = a periodic probe deciding whether a backend is fit for traffic. *Virtual IP (VIP)* = the single front-facing address the balancer answers on.

Requests arrive at the balancer's one address; it forwards each to a healthy backend, often round-robin or by least-busy. Add a server to handle more load and you've scaled *horizontally* - across more machines - rather than *vertically* (one ever-bigger machine, which has a ceiling and is itself a single point of failure).

```mermaid
flowchart TD
  clients[clients] --> lb[load balancer]
  lb --> a[server A - up]
  lb --> b[server B - down]
  lb --> c[server C - up]
```

Here's a health-check transition in an NGINX-style upstream log:

```console
$ tail -f /var/log/lb/health.log
2026-06-19T14:02:11Z upstream backend-b (10.10.20.12:443) check ok
2026-06-19T14:02:16Z upstream backend-b (10.10.20.12:443) check FAILED (timeout)
2026-06-19T14:02:21Z upstream backend-b (10.10.20.12:443) check FAILED (timeout)
2026-06-19T14:02:21Z upstream backend-b marked DOWN, removed from rotation
2026-06-19T14:02:21Z traffic now distributed across: backend-a, backend-c
```

*What just happened:* the balancer was probing `backend-b` every few seconds. Two timeouts in a row and it **removed the server from rotation** - new requests go only to the healthy two. No human acted; no client saw an error. When `backend-b` passes checks again, it's added back in. That automatic in-and-out is the reliability payoff, not the speed.

This is why deployments stop being terrifying: take backends out of rotation one at a time, update them, put them back - a rolling update with zero downtime, instead of a midnight maintenance window.

## Redundancy - more than one of everything that matters

A load balancer spreads work across many servers - but what happens when the *load balancer itself* fails? If the answer is "everything behind it goes dark," you've just moved the single point of failure, not removed it.

📝 **Terminology.** *Single point of failure (SPOF)* = any one component whose failure takes down the whole system. Reliability work is largely hunting down SPOFs and giving each a partner.

**Redundancy** means provisioning more than one of any component you can't afford to lose, arranged so one takes over if the other fails: two internet connections, two routers, two switches, dual power supplies, multiple paths between the same two points. It comes in two flavors:

- **Active-passive (failover):** one component works, a standby takes over on failure. Simpler, but you pay for idle hardware, and the failover moment can blip.
- **Active-active:** both carry traffic at once - extra capacity *and* resilience, but harder to set up correctly.

*Single point of failure - one router, one switch; either dying takes everything down:*
```mermaid
flowchart LR
  net((internet)) --> r[1 router] --> sw[1 switch]
```
*Redundant - two of each, so losing one is survivable:*
```mermaid
flowchart LR
  A((ISP-A)) --> r1[router 1] --> sw["switches<br/>cross-linked"]
  B((ISP-B)) --> r2[router 2] --> sw
```

⚠️ **Gotcha.** Redundancy you've never tested is a guess, not a guarantee. The classic disaster: during a real outage you discover the "standby" was misconfigured, its software had drifted out of sync, or failover never triggered. Two of everything only helps if you periodically pull the plug on the primary on purpose and confirm the secondary takes over cleanly.

That's the payoff: a backhoe cuts your primary fiber - a genuinely common outage cause - and traffic quietly shifts to the second ISP. A switch's power supply dies and its partner keeps the zone alive. The failures still happen; they just stop being *events*.

## The infrastructure services a real network runs

Segmentation and redundancy shape the network; two background services make it usable without a human assigning everything by hand. Easy to overlook when healthy - impossible to overlook the day they break, because everything seems to break at once.

### DHCP - addresses without a clipboard

**DHCP** (Dynamic Host Configuration Protocol) hands a device its network settings the moment it connects - IP address, subnet mask, default gateway, DNS servers. Without it, a human assigns every one of those by hand on every device.

A laptop joins and broadcasts "I need an address." The DHCP server answers with an address from the right subnet's pool, leased for a set time. This is where the address planning from Phase 1 pays off: one DHCP scope per VLAN/subnet, and devices land automatically in the correct zone.

```console
$ journalctl -u dhcpd --no-pager | tail -n 4
dhcpd[812]: DHCPDISCOVER from 3c:22:fb:1a:9e:40 via eth0.10
dhcpd[812]: DHCPOFFER on 10.10.10.52 to 3c:22:fb:1a:9e:40 via eth0.10
dhcpd[812]: DHCPREQUEST for 10.10.10.52 from 3c:22:fb:1a:9e:40 via eth0.10
dhcpd[812]: DHCPACK on 10.10.10.52 to 3c:22:fb:1a:9e:40 via eth0.10
```

*What just happened:* the four-step handshake people call **DORA** - DISCOVER, OFFER, REQUEST, ACK. A new device arrived on VLAN 10 (`eth0.10`), the server offered `10.10.10.52` from the workstation pool, the device asked to keep it, the server confirmed. ⚠️ That first DISCOVER is a *broadcast*, and broadcasts don't cross subnets - so each segmented zone needs its own reachable DHCP service or a "DHCP relay" (ip helper) on the router forwarding those requests. This trips people up the first time they segment a previously flat network.

### Internal DNS - names for the inside

You know DNS as the internet's phone book, turning `example.com` into an address. **Internal DNS** is that same machinery pointed inward - resolving names like `fileserver.corp.internal` that the public internet neither knows nor should.

Without it, people and scripts hard-code IP addresses, and the day you renumber a server (or fail over to its redundant partner) everything referencing the raw address breaks. With internal DNS, services refer to each other by name; change the address once and every reference follows - a name can even point at a load balancer's VIP instead of any one fragile server.

⚠️ **Gotcha.** DHCP and DNS must not be single points of failure - run two of each. When DNS is down, machines can't find each other even though the network is technically fine, and "everything is broken" is wildly out of proportion to "one small service stopped." Apply this phase's own redundancy lesson to the services that make the network work.

## Recap

1. The posture: **assume every component fails eventually**, and arrange for the network to keep working when it does.
2. **Load balancers** spread requests across many backends - partly speed (scale *horizontally*), largely **availability**, since health checks pull dead backends from rotation automatically.
3. **Redundancy** gives every component you can't lose a partner, killing **single points of failure** - active-passive (standby) or active-active (both live).
4. **Untested failover is a guess** - deliberately fail the primary and confirm the secondary takes over.
5. **DHCP** hands devices their settings automatically (the **DORA** handshake), landing each in the correct subnet - but segmented zones need a DHCP service or relay per zone, because the request is a broadcast.
6. **Internal DNS** gives private systems names, so addresses can change underneath without breaking every reference.
7. Run **two of every infrastructure service** - DHCP and DNS failing looks like the whole network failing.

Next, the edge: how the network meets the outside world without letting the outside in - **security and the edge**.


---

# Security & the Edge

Everything so far has been about *shape* - dividing the network and keeping it standing. This phase is about *defense*: where your network meets the internet, and the uncomfortable realization that a single line was never going to be enough.

The old mental model was a castle: a hard wall outside, everything inside trusted because it's inside. That model has a fatal flaw: **a flat trusted interior is a breach waiting to spread.** Once an attacker is past the wall - a phished password, a compromised laptop, a vulnerable public service - a castle gives free run of everything inside. So you build a strong edge *and* stop trusting the interior blindly. The edge tools (firewall, DMZ, VPN) are the wall and its gates; zero-trust is locks on the inside doors too - exactly what Phase 1's segmentation was quietly building toward.

## Firewalls - the gate that decides

A **firewall** sits at a network boundary and decides, packet by packet, what's allowed to pass. It enforces a policy - rules saying which traffic may cross between which zones - and its default disposition, on any firewall worth the name, is *deny*: no rule permits it, it's blocked.

The naive picture is a firewall as a checklist: "allow port 443, block port 23," judging each packet alone. That's **stateless**, and it's clumsy - to allow a reply to a connection you started, you'd have to permit a wide range of inbound traffic, exactly what you don't want. Real firewalls are **stateful**.

📝 **Terminology.** *Stateless filtering* = each packet judged on its own, by fixed rules, no memory. *Stateful filtering* = the firewall tracks active connections (a "state table") and judges packets in the context of the conversation they belong to.

A stateful firewall remembers the connections it has allowed. When an internal user opens a connection to a web server, the firewall notes it; the server's replies are recognized as part of a permitted flow and let back in automatically, while an unsolicited inbound packet - one matching no established conversation - is dropped. You write rules about who may *start* a conversation; return traffic takes care of itself.

```mermaid
flowchart LR
  inside[inside: start a connection<br/>to web server :443] -->|firewall records<br/>this flow| allow1([ALLOWED])
  reply[web server's reply] -->|recognized as part<br/>of the permitted flow| allow2([ALLOWED])
  rand[random inbound packet,<br/>no matching flow] -->|nobody asked for this| drop([DROPPED])
```

Firewall rules read as a top-to-bottom policy. Here's a small stateful ruleset:

```console
# policy: default deny; allow outbound web; allow established replies back in
$ sudo nft list ruleset
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept   # replies to flows we started
        ct state invalid drop                 # malformed / orphaned packets
        iif "lo" accept                       # the host's own loopback
        tcp dport 22 ip saddr 10.10.20.0/24 accept   # SSH only from the admin subnet
    }
}
```

*What just happened:* `policy drop` sets the default to **deny** - the safe starting point. `ct state established,related accept` is the stateful heart: traffic belonging to a connection already permitted is allowed back, so you never write rules for return packets. `ct state invalid drop` discards packets matching no real conversation. The last line shows segmentation and the firewall working together: SSH is permitted only when the source is the admin subnet (`10.10.20.0/24`) from Phase 1 - a rule impossible to write on a flat network where "the admin subnet" isn't a concept.

When an audit asks "what can reach the database?", the firewall policy *is* the answer, in writing. Because the default is deny, a forgotten rule fails safe: "something is blocked" (annoying) rather than "something is wide open" (catastrophic).

## The DMZ - a place for things the public must reach

Some services *have* to be reachable from the internet - a public website, a mail server, a VPN gateway. But reachable from the internet means exposed to attack. You can't put those services deep inside the trusted network (a compromise lands an attacker among your crown jewels), and you can't leave them fully outside (you still need to manage them).

A **DMZ** (demilitarized zone) is a separate, tightly-controlled segment between the internet and your internal network, holding exactly the services that must face the public. It's its own zone - its own VLAN and subnet, in Phase 1's terms - with firewall rules on *both* sides.

The firewall lets the internet reach the DMZ on specific ports (the website on 443) - that's all the internet can touch. The rules from the DMZ *into* the internal network are extremely tight: the public web server reaches the one internal database it needs, on the one port it needs, nothing else. So if that public-facing server is compromised - and public-facing servers are the likeliest to be - the attacker is stuck in the DMZ, holding a box that can't freely reach anything valuable.

```mermaid
flowchart TD
  net((INTERNET)) --> fw1[FIREWALL]
  fw1 -->|allow :443, deny everything else inbound| dmz[DMZ<br/>public web / mail / VPN gateway<br/>own VLAN+subnet, reachable from the internet]
  dmz -->|VERY TIGHT rules: only the exact port s<br/>a public service legitimately needs| fw2[FIREWALL]
  fw2 --> internal[INTERNAL NETWORK<br/>workstations, servers, databases<br/>the zones from Phase 1 -<br/>NOT directly reachable from outside]
```

⚠️ **Gotcha.** A DMZ only works if the inward rules stay tight. The slow failure is convenience creep - over months, someone needs the DMZ server to reach "just one more" internal system, then another, until the DMZ can reach half the internal network and the separation is hollow. A DMZ that can reach everything inside isn't a DMZ; it's an attacker's launchpad with extra steps. Review those inbound-to-internal rules like they matter, because they do.

## VPNs - letting the right people in from outside

Your people aren't always in the building - home, hotels, cafés - and need to reach internal systems that correctly aren't exposed to the public internet. The wrong fix is poking a firewall hole per remote person. The right fix is a VPN.

A **VPN** (Virtual Private Network) builds an encrypted tunnel across the untrusted internet, so a remote device behaves, network-wise, as if plugged in *inside* the network. Traffic in the tunnel is encrypted end to end, so nobody in between can read or tamper with it.

📝 **Terminology.** *Tunnel* = an encrypted connection carrying your private network's traffic across a public network. *VPN gateway / concentrator* = the edge device (often in the DMZ) that terminates remote VPN connections and authenticates the users behind them.

The remote user authenticates to the VPN gateway - ideally with more than a password (a code, a hardware key). Once the tunnel is up, their laptop gets an internal-style address and reaches internal resources *through the gateway*, subject to the same firewall and segmentation rules as anyone inside. The VPN doesn't bypass your security model; it extends the edge out to the remote user and applies the same rules.

⚠️ **Gotcha.** A VPN granting full, flat access to the entire internal network the instant someone connects re-creates the castle problem - now with the drawbridge handed to anyone who can phish one password. This is why a second authentication factor on the VPN is non-negotiable, and why a connected user's reach should still be limited by zone, not flung wide open.

## Zero-trust - locks on the inside doors

The castle model trusts the interior: get inside, and you're trusted. Every gotcha in this phase is a variation on the same wound - the breached DMZ server, the over-broad VPN, the compromised laptop - each catastrophic only *because* the interior is trusted and flat.

**Zero-trust** drops the assumption that "inside" equals "trusted." Every request to reach a resource is verified - who's asking, what device, whether they're authorized for that specific resource - regardless of where it comes from. The slogan: "never trust, always verify." There's no soft, trusting interior to exploit, because there's no interior the system trusts by default.

You don't reach zero-trust by buying a product; you reach it by taking Phase 1 to its conclusion. Segmentation already gave you zones with rules at every boundary. Zero-trust pushes further - smaller zones, verification at every hop rather than only the outer wall, identity checked per request - until "I'm inside the network" grants nothing on its own. The firewall, the DMZ, and the VPN are the strong edge; zero-trust is the recognition that the edge will eventually be crossed, and a breach should find another locked door at every step, not an open hallway.

> 💡 **The one idea to keep.** A strong perimeter is necessary and not sufficient. Build the wall - *and* assume it will be breached, and make sure the breach hits a contained zone, not the whole company. That single sentence is segmentation, scaling, and security all arguing for the same thing.

## Recap

1. The shift: a **flat trusted interior is a breach waiting to spread** - build a strong edge *and* stop trusting the inside blindly.
2. **Firewalls** enforce a default-**deny** policy at boundaries; **stateful** filtering tracks connections so replies to flows you started are allowed automatically while unsolicited inbound traffic is dropped.
3. The **DMZ** isolates public-facing services in their own zone with tight rules on both sides, so a compromise of an exposed server stays trapped - *if* you resist convenience creep on the inward rules.
4. A **VPN** extends the edge to remote users with an encrypted tunnel; demand a second authentication factor and keep their reach limited by zone, never flat-and-full.
5. **Zero-trust** drops "inside = trusted" and verifies every request - it's segmentation taken to its conclusion, so a breach meets another locked door at every hop.
6. The whole guide, in one line: **divide it, keep it standing, and assume the wall will fall - so the blast radius is one zone, not everything.**

You can now look at a real enterprise network diagram and reason about why each box sits where it does. For the machinery beneath this model - routing protocols, switch-loop prevention, and vendor configuration - see the follow-up guides noted in the overview.