Guided buildadvanced7 steps~25 min6 devices

A DMZ behind a firewall

Stand a firewall between three zones so the public reaches one server and nothing else.

What you'll be able to do: Strangers on the internet can reach the public web server and are stopped cold at the office; the office still browses out freely; and a DMZ server that gets taken over has no path back to a desk.

Start this build in the lab 6 devices — needs any paid plan (the free canvas fits 5).

Topics: Firewalls · DMZ design · Extended ACLs · Default deny

What you'll build

Guard — a firewall, the edge firewall that stands between all three zones
SW-Office — a switch, the switch the office workstations plug into
PC-Staff — a pc, a workstation on the office LAN
PC-Finance — a pc, a second office workstation in the same protected subnet
WEB1 — a server, the public web server that lives in the DMZ
Outsider — a server, a host out on the public internet

Step by step

1. Place the firewall and read the policy it came with
Drag a firewall onto the canvas and name it. A NetForge firewall is a router that filters: it forwards between its four legs like any router, and on top of that it checks an access list against traffic arriving on a leg you have bound one to. It ships with a list already written and already bound — so before changing anything, read the policy you have inherited.
On Guard — Enter privileged mode, name the box, then read the shipped access list
```
enable
configure terminal
hostname Guard
end
show ip access-lists
```
Check: run show ip access-lists on Guard and look for 20 permit ip any any.
Why: A security device's defaults are a policy you did not write, and you are responsible for them from the moment the box is in your network. Reading the shipped list first turns an assumption into a fact: one deny for telnet followed by `permit ip any any` means this box allows by default.
2. Turn three legs into three zones
A DMZ design is three levels of trust, and on this box each one is a physical port: Gi0/0 faces the office you trust, Gi0/1 faces the internet you trust not at all, and Gi0/2 faces the public server you trust somewhere in between. Three zones means three separate subnets — put the public server on the office subnet and there is nothing for the firewall to stand between. Descriptions cost nothing and are how you avoid hardening the wrong port at 2am.
On Guard — Address and label the inside, outside and DMZ legs
```
enable
configure terminal
interface Gi0/0
description INSIDE-OFFICE
ip address 192.168.20.1 255.255.255.0
no shutdown
exit
interface Gi0/1
description OUTSIDE-INTERNET
ip address 203.0.113.1 255.255.255.0
no shutdown
exit
interface Gi0/2
description DMZ-PUBLIC
ip address 172.16.50.1 255.255.255.0
no shutdown
exit
end
```
Check: run show ip interface brief on Guard and look for Gi0/1 203.0.113.1 YES manual down down.
Why: Zones are defined by trust, not by function: for each leg the question is how far you believe what arrives on it, and that decides how strict its inbound policy must be. The untrusted outside gets the strictest filter, and traffic from the trusted inside the least scrutiny.
3. Build the office behind the inside leg
Drop in a switch and two workstations, cable them up, and point both PCs at 192.168.20.1 — the firewall's inside leg is their default gateway, so everything leaving the office passes through it. Two workstations rather than one matters later: the policy you write will cover the whole 192.168.20.0/24 subnet rather than one address, and two hosts are how you prove that.
- Cable SW-Office Gi0/1 ↔ Guard Gi0/0
- Cable PC-Staff Eth0 ↔ SW-Office Fa0/1
- Cable PC-Finance Eth0 ↔ SW-Office Fa0/2
On SW-Office — Name the switch and bring up the uplink and the two desk ports
```
enable
configure terminal
hostname SW-Office
interface Gi0/1
switchport mode access
no shutdown
exit
interface Fa0/1
switchport mode access
no shutdown
exit
interface Fa0/2
switchport mode access
no shutdown
exit
end
```
On PC-Staff — Name the first workstation and point it at the firewall
```
hostname PC-Staff
ipconfig Eth0 192.168.20.10 255.255.255.0 192.168.20.1
```
On PC-Finance — Name the second workstation and put it in the same subnet
```
hostname PC-Finance
ipconfig Eth0 192.168.20.11 255.255.255.0 192.168.20.1
```
Check: run show ip route on Guard and look for C 192.168.20.0/24 is directly connected, Gi0/0.
Why: A firewall that is not the only way out of a zone can simply be walked around, so firewall design starts with the topology — one gateway per zone and no second cable that skips it — before a single rule is written.
4. Put the public server on a leg of its own
A DMZ exists so the one machine strangers are invited to talk to is not sitting on the same wire as payroll. Cable WEB1 to Gi0/2 and give it 172.16.50.10 with the firewall as its gateway — a server that only ever answers still needs one, because the engine checks the return path and will tell you the server has nowhere to send its reply. The office can reach it from the moment it is addressed, and that stays true for the rest of the build.
- Cable Guard Gi0/2 ↔ WEB1 Eth0
On WEB1 — Name the public server and address it in the DMZ subnet
```
hostname WEB1
ipconfig Eth0 172.16.50.10 255.255.255.0 172.16.50.1
```
Check: run show ip route on Guard and look for C 172.16.50.0/24 is directly connected, Gi0/2.
Why: The machine you expose to strangers is the one most likely to be compromised, so a DMZ design assumes it will be. Putting it on its own segment means that if it is, the attacker lands in a subnet the firewall still stands between, rather than on the same wire as the office, where no filter could intervene.
5. Plug in the internet, and see what you just exposed
Add a host on the outside leg — it stands in for the whole internet — then ping the office from it. 192.168.20.10 answers, and so does 192.168.20.11. The shipped OUTSIDE-IN list blocks telnet and then ends with `permit ip any any`, so every packet that is not telnet is waved through, a desk in the accounts office included. This is the hole the rest of the build closes.
- Cable Guard Gi0/1 ↔ Outsider Eth0
On Outsider — Name the outside host, address it, and knock on the office door
```
hostname Outsider
ipconfig Eth0 203.0.113.10 255.255.255.0 203.0.113.1
ping 192.168.20.10
ping 192.168.20.11
```
Check: run show ip route on Guard and look for C 203.0.113.0/24 is directly connected, Gi0/1.
Why: A deny-list protects only against what its author anticipated. The shipped list anticipated telnet and nothing else, so everything else the outside can send — pings included — reaches any address the firewall can route to, and each new service behind it is exposed the day it is switched on.
6. Swap permit-by-default for deny-by-default
The obvious fix is to append a deny for the office — type it first and watch it change nothing, because a named list only appends and your new rule lands underneath the `permit ip any any` that already matched. Re-ordering means deleting the whole list and retyping it, and since the delete also unbinds it, `ip access-group` has to go back on afterwards or the leg ends up with no policy at all. What you retype is the real answer: permit exactly what the public is allowed to reach, and let everything else fall off the end into the implicit deny.
On Guard — The naive fix — append a deny and watch it land in the wrong place
```
enable
configure terminal
ip access-list extended OUTSIDE-IN
deny ip any 192.168.20.0 0.0.0.255
exit
end
show ip access-lists
```
On Guard — Delete the list, retype it in priority order, and re-bind it to the outside leg
```
enable
configure terminal
no ip access-list extended OUTSIDE-IN
ip access-list extended OUTSIDE-IN
permit tcp any host 172.16.50.10 eq 80
permit tcp any host 172.16.50.10 eq 443
permit icmp any host 172.16.50.10
exit
interface Gi0/1
ip access-group OUTSIDE-IN in
exit
end
```
On Outsider — Test from outside — the web server answers, the office does not
```
ping 172.16.50.10
ping 192.168.20.10
```
On PC-Staff — Test from inside — nothing you just did touches traffic on its way out
```
ping 203.0.113.10
```
Check: run show ip access-lists on Guard and look for 30 permit icmp any host 172.16.50.10.
Why: Deny-by-default is least privilege applied to traffic: the outside may reach exactly the services listed, and anything nobody decided to allow is refused by the implicit deny. A new host behind the firewall is then protected the day it is plugged in, instead of the day someone remembers to write a rule for it.
7. Close the DMZ's back door
OUTSIDE-IN only inspects packets arriving on Gi0/1, so it has nothing to say about the DMZ: WEB1 can still reach every desk in the office, which is precisely the path an attacker takes after taking over a public server. Bind a second list inbound on Gi0/2 that denies anything aimed at the office and permits the rest, and the DMZ becomes what it is meant to be — a room with a door to the internet and no door to you. The office can still open connections into the DMZ, because that traffic arrives on Gi0/0 and never meets a list.
On Guard — Write a DMZ policy and bind it to the leg the DMZ arrives on
```
enable
configure terminal
ip access-list extended DMZ-IN
deny ip any 192.168.20.0 0.0.0.255
permit ip any any
exit
interface Gi0/2
ip access-group DMZ-IN in
exit
end
```
On WEB1 — Test from the DMZ — the internet is fine, the office is gone
```
ping 203.0.113.10
ping 192.168.20.10
```
Check: run show ip access-lists on Guard and look for Extended IP access list DMZ-IN.
Why: Filtering each zone where it enters the firewall gives every zone an independent policy: the list on Gi0/2 judges only what the DMZ sends, so tightening it cannot change what the internet may reach, and a mistake in one list cannot open another. A server's only door is its leg of the firewall, which makes that leg the natural place to contain it.

The theory behind it

Standard and Extended ACLs

One jack, one PC: port security — Lock the reception wall jack to one PC with sticky port security, watch a visitor's laptop err-disable it, recover the port, then switch to restrict so the next intruder is dropped without taking reception offline.
Guard the server with an ACL — Let one workstation reach the server, stop the guest laptop, and learn what the implicit deny does to everyone else.
Two routers, one gateway — Give a LAN a gateway that survives a router failure: two routers share one virtual address with VRRP, and the hosts never notice the handover.

Build it for real

The lab walks you through these steps and ticks each one off as your network starts working.

Open in the lab

What you'll build

Step by step

1. Place the firewall and read the policy it came with

2. Turn three legs into three zones

3. Build the office behind the inside leg

4. Put the public server on a leg of its own

5. Plug in the internet, and see what you just exposed

6. Swap permit-by-default for deny-by-default

7. Close the DMZ's back door

The theory behind it

More in Security & resilience

Build it for real