Guided buildadvanced10 steps~40 min7 devices

Branch office capstone

Staff and guests on one switch: guests lease an address the moment they plug in, reach the internet, and never see a staff file.

What you'll be able to do: A visitor plugs a laptop into the meeting-room port, leases an address, and reaches a web server on the internet behind the branch's single public address — while the staff desk and the NAS keep reaching each other and stay out of the guest VLAN's reach.

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

Topics: VLANs · Trunking · Inter-VLAN routing · DHCP · ACLs · NAT/PAT

What you'll build

SW-Branch — a switch, the branch's only switch: staff desk, NAS and the meeting-room port
PC-Staff — a pc, a staff desktop
NAS-Files — a nas, the staff file store no guest may reach
BR-Edge — a router, the branch router: both gateways, the guest pool, the filter and the NAT
Laptop-Guest — a pc, a visitor's laptop in the meeting room
ISP — a router, the provider's router, standing in for the internet
WEB1 — a server, a web server out on the internet

Step by step

1. Split the branch switch into staff and guest VLANs
A branch carries two populations over one set of cables: staff, who own the files, and visitors, who own nothing here but still want the internet. Give each its own VLAN before a single device goes in — VLAN 10 for staff, VLAN 20 for guests — so the two never share a broadcast domain.
On SW-Branch — Name the switch and define the staff and guest VLANs
```
enable
configure terminal
hostname SW-Branch
vlan 10
name STAFF
exit
vlan 20
name GUEST
exit
end
```
Check: run show vlan brief on SW-Branch and look for 20 GUEST.
Why: A VLAN is a separate broadcast domain inside one switch: an ARP or DHCP broadcast in VLAN 20 is never delivered to a VLAN 10 port. The gateways, the guest pool and the filter you add later all hang off this split.
2. Plug in the staff desk and the file store
Cable the staff desktop to Fa0/1 and the NAS to Fa0/2, hand both ports to VLAN 10, and address the two by hand in 192.168.10.0/24. Staff kit here is fixed on purpose: the filter you write later names the NAS's subnet, and a file share that moves is a share nobody can find. Ping the NAS from the desk — same VLAN, same subnet, no router involved.
- Cable PC-Staff Eth0 ↔ SW-Branch Fa0/1
- Cable NAS-Files Eth0 ↔ SW-Branch Fa0/2
On SW-Branch — Put the desk and NAS ports in the staff VLAN
```
enable
configure terminal
interface Fa0/1
switchport mode access
switchport access vlan 10
exit
interface Fa0/2
switchport mode access
switchport access vlan 10
exit
end
```
On PC-Staff — Name the desktop and give it a fixed staff address
```
hostname PC-Staff
ipconfig Eth0 192.168.10.10 255.255.255.0 192.168.10.1
```
On NAS-Files — Name the NAS and give it a fixed staff address
```
hostname NAS-Files
ipconfig Eth0 192.168.10.20 255.255.255.0 192.168.10.1
```
On PC-Staff — Open the file store from the desk
```
ping 192.168.10.20
```
Check: run show vlan brief on SW-Branch and look for 10 STAFF active Fa0/1, Fa0/2.
Why: An access port carries exactly one VLAN and strips the tag, so neither device knows VLANs exist. Both sit in the same VLAN and the same subnet, so the switch alone delivers the ping.
3. One router port, two gateways
You built this in Router on a stick: one cable from BR-Edge's Gi0/0 to the switch's Gi0/1, no address on the physical port, and a dot1Q subinterface per VLAN — 192.168.10.1 for staff, 192.168.20.1 for guests. Then make Gi0/1 a trunk carrying both VLANs, because the subinterfaces only answer tagged frames.
- Cable BR-Edge Gi0/0 ↔ SW-Branch Gi0/1
On BR-Edge — Name the router, open the uplink, and add a subinterface per VLAN
```
enable
configure terminal
hostname BR-Edge
interface Gi0/0
no ip address
no shutdown
exit
interface Gi0/0.10
encapsulation dot1Q 10
ip address 192.168.10.1 255.255.255.0
exit
interface Gi0/0.20
encapsulation dot1Q 20
ip address 192.168.20.1 255.255.255.0
exit
end
```
On SW-Branch — Turn the router-facing port into a trunk carrying both VLANs
```
enable
configure terminal
interface Gi0/1
switchport mode trunk
switchport trunk allowed vlan 10,20
end
```
On PC-Staff — Reach the new staff gateway
```
ping 192.168.10.1
```
Check: run show interfaces trunk on SW-Branch and look for Gi0/1 on 802.1q trunking 1.
Why: Each subinterface accepts only frames tagged with its `encapsulation dot1Q` VLAN, and the router routes between the two connected subnets. Until the switch port is a trunk it sends untagged frames that no subinterface claims — the trunk is what makes the gateways real.
4. Hand guests an address the moment they plug in
Visitors bring laptops nobody here configured, so the guest VLAN runs DHCP. Put the meeting-room port Fa0/13 in VLAN 20, reserve .1 to .9 for infrastructure, and give BR-Edge a pool for 192.168.20.0/24 with a four-hour lease — long enough for a meeting, short enough that yesterday's visitors hand their addresses back. Then plug the laptop in and let it ask.
- Cable Laptop-Guest Eth0 ↔ SW-Branch Fa0/13
On SW-Branch — Make the meeting-room port a guest access port
```
enable
configure terminal
interface Fa0/13
switchport mode access
switchport access vlan 20
end
```
On BR-Edge — Reserve the low addresses, then serve the rest of the guest subnet
```
enable
configure terminal
ip dhcp excluded-address 192.168.20.1 192.168.20.9
ip dhcp pool GUEST
network 192.168.20.0 255.255.255.0
default-router 192.168.20.1
dns-server 9.9.9.9
lease 0 4
exit
end
```
On Laptop-Guest — Name the laptop and ask the network for an address
```
hostname Laptop-Guest
ipconfig /renew
```
Check: run show ip dhcp binding on BR-Edge and look for 192.168.20.10.
Why: The laptop's DISCOVER is a broadcast in VLAN 20. It crosses the trunk tagged 20, reaches BR-Edge, and comes back as an offer carrying an address, the mask and the `default-router` from the pool. `excluded-address` is a global command, which is why it is typed before the pool rather than inside it.
5. Look before you lock: a guest can open the staff NAS
Before writing any filter, see the problem it exists to solve. Ping the NAS at 192.168.10.20 from the guest laptop: it answers. Nothing is broken — forwarding between the networks it is connected to is a router's whole job, and BR-Edge is connected to both.
On Laptop-Guest — Try the staff file store from the guest VLAN
```
ping 192.168.10.20
```
Check: run show ip route on BR-Edge and look for C 192.168.10.0/24 is directly connected, Gi0/0.10.
Why: VLANs separate broadcast domains, not networks. The moment a router joins two VLANs, every host in one can reach every host in the other unless something on that router says no — isolation is a policy you write, not a side effect of VLANs.
6. Fence the guest VLAN off the staff VLAN
Write a named extended ACL that denies anything from the guest subnet to the staff subnet and permits the rest, then apply it inbound on Gi0/0.20 — the door guest traffic walks through into the router. Ping the NAS from the laptop again: it fails. The laptop still reaches its own gateway, and the staff side has not noticed a thing.
On BR-Edge — Deny guests to staff, permit everything else, inbound on the guest subinterface
```
enable
configure terminal
ip access-list extended GUEST-IN
deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
permit ip any any
exit
interface Gi0/0.20
ip access-group GUEST-IN in
end
```
On Laptop-Guest — The same ping, now that the filter is in place
```
ping 192.168.10.20
```
Check: run show ip interface Gi0/0.20 on BR-Edge and look for Inbound access list is GUEST-IN.
Why: An extended ACL matches source AND destination, so one line can say 'guests to staff: no' without touching 'guests to anywhere else'. Inbound on the guest subinterface is the right door: only guest traffic passes through it, and each packet is judged before the router routes it. The final `permit ip any any` is load-bearing, because every ACL ends in an invisible deny.
7. Wire the branch to the provider
Add the provider: a serial link to its router, a /30 with 203.0.113.2 on BR-Edge — the only public address this branch owns — and a web server on the provider's far LAN. In the lab you type the provider's side too, including the filter every real provider runs on a customer link: nothing sourced from a private RFC 1918 range gets in. Finish with a default route out of Se0/0/0.
- Cable BR-Edge Se0/0/0 ↔ ISP Se0/0/0 (serial)
- Cable WEB1 Eth0 ↔ ISP Gi0/0
On ISP — Stand up the provider: the customer /30, the server LAN, and the anti-spoofing filter
```
enable
configure terminal
hostname ISP
interface Se0/0/0
ip address 203.0.113.1 255.255.255.252
no shutdown
exit
interface Gi0/0
ip address 198.51.100.1 255.255.255.0
no shutdown
exit
ip access-list extended NO-PRIVATE
deny ip 192.168.0.0 0.0.255.255 any
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
permit ip any any
exit
interface Se0/0/0
ip access-group NO-PRIVATE in
end
```
On WEB1 — Address the public web server
```
hostname WEB1
ipconfig Eth0 198.51.100.50 255.255.255.0 198.51.100.1
```
On BR-Edge — Take the public end of the /30 and send everything unknown to the provider
```
enable
configure terminal
interface Se0/0/0
ip address 203.0.113.2 255.255.255.252
no shutdown
exit
ip route 0.0.0.0 0.0.0.0 203.0.113.1
end
```
Check: run show ip route on BR-Edge and look for S* 0.0.0.0/0 via 203.0.113.1, Se0/0/0.
Why: BR-Edge knows its three connected networks and nothing else in the world; the default route hands everything else to 203.0.113.1. The provider's filter matches the SOURCE address, so BR-Edge's own pings — sourced from 203.0.113.2 — pass straight through it.
8. Try the internet from inside — and get nowhere
Ping 198.51.100.50 from the staff desk and from the laptop. Both fail one hop past the building: they leave carrying 192.168.10.10 and 192.168.20.10 as their source, and the provider drops private addresses at the door. BR-Edge itself still gets answers, because its packets carry a public source.
On PC-Staff — Try the web server from the staff desk
```
ping 198.51.100.50
```
On Laptop-Guest — Try it from the guest laptop
```
ping 198.51.100.50
```
Check: run show access-lists on ISP and look for 10 deny ip 192.168.0.0 0.0.255.255 any.
Why: Private addresses are reused by millions of networks at the same moment, so no provider routes them — a reply could never find its way back to the right one. Something has to rewrite the source to a public address on the way out, and that is exactly the job NAT does.
9. Translate the staff VLAN — and only the staff VLAN
Turn on PAT: mark both subinterfaces `ip nat inside`, the serial `ip nat outside`, put the staff subnet in access-list 1, and overload the WAN address. The desk and the NAS reach the web, sharing 203.0.113.2. The laptop does not — its subinterface is inside, but its subnet is not on the list, so it still leaves with a private source and is still dropped.
On BR-Edge — Mark inside and outside, list the staff subnet, and overload the WAN address
```
enable
configure terminal
interface Gi0/0.10
ip nat inside
exit
interface Gi0/0.20
ip nat inside
exit
interface Se0/0/0
ip nat outside
exit
access-list 1 permit 192.168.10.0 0.0.0.255
ip nat inside source list 1 interface Se0/0/0 overload
end
```
On PC-Staff — The staff desk tries the web again
```
ping 198.51.100.50
```
On Laptop-Guest — And so does the guest laptop
```
ping 198.51.100.50
```
Check: run show ip nat translations on BR-Edge and look for icmp 203.0.113.2:1024 192.168.10.10:1024 198.51.100.50.
Why: Two different questions, two different settings. `ip nat inside` says where translatable traffic may come from; access-list 1 says which sources actually get translated. A packet from an inside interface that the list does not match is routed out untouched — and the provider drops it.
10. Let the guests out too — and only out
Add the guest subnet to access-list 1. Nothing else changes, and the laptop reaches the web at once, sharing the same public address as the staff side. Then ping the NAS from it one more time: still blocked. GUEST-IN decides where a guest may go; list 1 only decides whose source address gets rewritten.
On BR-Edge — Add the guest subnet to the translation list
```
enable
configure terminal
access-list 1 permit 192.168.20.0 0.0.0.255
end
```
On Laptop-Guest — The guest laptop tries the web again
```
ping 198.51.100.50
```
On Laptop-Guest — And the staff file store, which must stay out of reach
```
ping 192.168.10.20
```
Check: run show ip nat translations on BR-Edge and look for icmp 203.0.113.2:1025 192.168.20.10:1025 198.51.100.50.
Why: PAT keeps every conversation apart by port: each inside host leaves as 203.0.113.2 with its own port number, and the table maps each reply back to the right desk or laptop. The filter runs inbound on Gi0/0.20, before routing and before NAT, so being translatable never makes a guest trusted.

The theory behind it

Campus capstone — Put it all together: two wiring closets, two VLANs, DHCP for the desks, and one public address for the whole site.
Redundant campus — Double every link and box between a desk and HQ — bundled, spanning-tree protected, VRRP gateways, twin OSPF circuits — then break two of them and keep working.

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. Split the branch switch into staff and guest VLANs

2. Plug in the staff desk and the file store

3. One router port, two gateways

4. Hand guests an address the moment they plug in

5. Look before you lock: a guest can open the staff NAS

6. Fence the guest VLAN off the staff VLAN

7. Wire the branch to the provider

8. Try the internet from inside — and get nowhere

9. Translate the staff VLAN — and only the staff VLAN

10. Let the guests out too — and only out

The theory behind it

More in Capstones

Build it for real