A fully functional multi-VLAN campus network built in Cisco Packet Tracer, demonstrating inter-VLAN routing, router-based DHCP with relay, NAT/PAT, and layered ACL security. Designed as a realistic small-campus scenario with three user segments and a simulated internet edge.
This lab simulates a small college campus network with three logically separated user groups — Administration, Students, and IoT — connected through a central campus router. Traffic between segments is controlled, internet access goes through NAT/PAT at the edge, and a physically separate public server segment rounds out the topology.
The lab was built as an integration assignment covering the full network stack from Layer 2 VLANs up to access control policies. Every design decision reflects real-world practice: DHCP relay instead of a dedicated server, PAT for internet access, and an ACL that enforces a one-directional access policy between user segments.
| Segment | Network | Gateway |
|---|---|---|
| VLAN 10 — Administratie | 192.168.10.0/24 |
192.168.10.1 |
| VLAN 20 — Studenten | 192.168.20.0/24 |
192.168.20.1 |
| VLAN 30 — IoT | 192.168.30.0/24 |
192.168.30.1 |
| Public Server LAN | 209.165.200.0/27 |
209.165.200.1 |
| R-CAMPUS ↔ R-EDGE | 198.51.100.0/30 |
— |
| R-CAMPUS ↔ R-SRV | 10.50.0.0/30 |
— |
| R-EDGE ↔ Internet | 203.0.113.0/30 |
— |
| Router | Role |
|---|---|
| R-CAMPUS | Inter-VLAN routing (router-on-a-stick), DHCP for VLAN 10 & 20, DHCP relay for VLAN 30 |
| R-EDGE | Internet edge, NAT/PAT for all private subnets, default route to ISP |
| R-SRV | DHCP server for VLAN 30 (IoT), gateway for public server segment |
INTERNET / ISP
|
203.0.113.0/30
|
[ R-EDGE ]
|
198.51.100.0/30
|
[ R-CAMPUS ]
/ \
trunk / \ routed link
/ \
[ SW1 ] [ R-SRV ]
/ | \ |
/ | \ |
VLAN10 VLAN20 VLAN30 Public Server
ADMIN STUDENT IOT 209.165.200.2/27
| | |
PC-A PC-S PC-I
See diagrams/campus-network-topology.png for the full Packet Tracer topology screenshot.
Router-on-a-stick inter-VLAN routing
R-CAMPUS uses 802.1Q subinterfaces (g0/0.10, g0/0.20, g0/0.30) on a single trunk to SW1. Each subinterface acts as the default gateway for its respective VLAN.
Router-based DHCP with relay
VLAN 10 and VLAN 20 get leases directly from R-CAMPUS. VLAN 30 (IoT) is also terminated on R-CAMPUS, but its DHCP server runs on R-SRV. The ip helper-address 10.50.0.2 on g0/0.30 converts the broadcast DHCP Discover into a unicast forwarded to R-SRV — the only way to cross a router boundary with DHCP.
NAT/PAT at the edge
R-EDGE translates all three private subnets (192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24) to its outside interface using PAT overload. The public server segment is excluded — it's already publicly addressed in this simulation. R-EDGE deliberately holds no routes back to private subnets, so internet-side hosts cannot initiate connections inward.
Extended ACL — segment isolation
An extended named ACL (STUDENT_FILTER) is applied inbound on g0/0.20. It denies student traffic destined for the administration subnet while permitting everything else. This enforces a realistic one-directional policy: students cannot reach admin, but the reverse is allowed. A separate numbered ACL on R-EDGE (access-list 101) blocks inbound traffic from the internet side toward any private address range.
Static routing All routing is done with static routes. R-CAMPUS has a default route to R-EDGE and a specific route to the public server LAN via R-SRV. R-SRV has explicit return routes back to all three campus subnets. R-EDGE has a route to the public server LAN and a default route to the ISP — no routes to private space, by design.
-
DHCP relay is not optional when subnets span routers. DHCP broadcasts don't cross L3 boundaries. Without
ip helper-address, VLAN 30 would never receive leases from R-SRV regardless of routing being correct. This made the distinction between broadcast and unicast traffic very concrete. -
NAT and routing are separate concerns. Even with perfect static routing, PAT won't work if
ip nat insideandip nat outsideare missing or swapped, or if the ACL matched toip nat inside source listdoesn't cover the right subnets. -
ACL direction matters as much as content. An ACL applied
inon the student subinterface filters traffic as it enters the router from the student side. Applying itouton the wrong interface, or in the wrong direction, either blocks the wrong traffic or does nothing at all. -
Ping to the gateway is not a health check for the full path. Gateway reachability only confirms L2 and local L3 connectivity. It says nothing about routing beyond the first hop, NAT translations, return paths, or ACL behaviour downstream.
-
Systematic troubleshooting by layer.
show ip dhcp binding→show ip route→show ip nat translations→show access-listsis a repeatable sequence that isolates exactly which layer is failing without guessing.
.
├── configs/
│ ├── R-CAMPUS.txt
│ ├── R-EDGE.txt
│ ├── R-SRV.txt
│ └── SW1.txt
├── diagrams/
│ └── campus-network-topology.png
├── screenshots/
│ ├── tests/
│ │ ├── acl-blocks-students-to-admin.png
│ │ ├── dhcp-successful.png
│ │ └── nat-internet-reachable.png
│ └── verification/
│ ├── show-access-lists-campus.png
│ ├── show-access-lists-edge.png
│ ├── show-interfaces-trunk.png
│ ├── show-ip-dhcp-pool-and-binding-router-campus.png
│ ├── show-ip-dhcp-pool-and-binding-router-server.png
│ ├── show-ip-nat-translations-router-edge.png
│ ├── show-ip-route-campus.png
│ ├── show-ip-route-edge.png
│ ├── show-ip-route-srv.png
│ └── show-vlan-brief.png
└── README.md
- Cisco Packet Tracer
- IOS CLI (router-on-a-stick, DHCP, NAT/PAT, ACL, static routing)