Networking Projects
Real projects are where all the neat categories on this site start overlapping. A "VPN project" turns into a routing project, then a firewall project, then a DNS project. These are some of the common ones, how I'd approach each, and what they tend to teach you. They're not tied to any one client or employer. Think of them as the shape these projects usually take.
Remote access VPN
The problem: people need to get to internal stuff from home, safely, and it has to keep working.
How I'd approach it: a firewall like pfSense or OPNsense, with WireGuard or OpenVPN for remote users and IPsec for any site-to-site links to other offices. Put MFA on the VPN login. Give VPN users their own subnet so you can write firewall rules for them specifically, instead of dropping them straight onto the LAN.
What it teaches you: the tunnel is the easy part. The real work is DNS for remote users (split DNS gets involved fast), MTU problems that only show up on certain home Internet connections, overlapping address space when someone's home network is also 192.168.1.0/24, and deciding what VPN users should actually be allowed to reach.
Splitting up a flat network with VLANs
The problem: one big flat network where everything can talk to everything. It's slow when broadcasts pile up, and one infected laptop can reach every server.
How I'd approach it: start by looking at what's actually on the network and what talks to what. Then build VLANs around trust and function: servers, staff, voice, printers, guests, management. Route between them on a layer 3 switch or the firewall, and use ACLs or firewall rules to decide what crosses between them.
What it teaches you: the VLANs take an afternoon. Finding all the hidden dependencies takes much longer. The printer that needs to reach the file server, the badge reader nobody remembered, the app that uses broadcast discovery. Logging traffic for a while before turning on strict rules saves a lot of pain. More in Switching and VLANs.
Multihoming with BGP
The problem: a network that can't depend on one upstream provider anymore.
How I'd approach it: get an ASN and address space (or use what you have), bring up BGP with two transit providers, announce your prefixes to both, and filter strictly in both directions. Use local-pref to pick your preferred exit, and AS-path prepending or provider communities to nudge inbound traffic. Create RPKI ROAs while you're at it.
What it teaches you: inbound traffic is much harder to control than outbound, because other networks make that decision, not you. And actually test failover. Pull a link and watch what really happens instead of assuming. Details in my BGP notes.
Rolling out IPv6
The problem: IPv4 is running out, or you just want to stop having IPv6 run unmanaged on your network.
How I'd approach it: get a /48 (or whatever your ISP gives you), make an address plan that lines up with your VLANs, turn on dual stack, update firewall rules for v6 on purpose, and only add AAAA records for services you've actually tested over IPv6.
What it teaches you: the routing is usually the easy part. Firewalls, monitoring, logging, and old applications are where the surprises are. And it makes you unlearn a few IPv4 habits. See IPv6.
A redundant data center network
The problem: servers that need to stay reachable when any single switch, link, or power feed fails.
How I'd approach it: spine-leaf, with every server dual-homed to two leaf switches (MLAG or vPC), routed links between leaves and spines, and ECMP to use all the paths. Two power feeds to everything, on different circuits.
What it teaches you: redundancy you haven't tested is just a theory. Unplug things on purpose during a maintenance window and see what actually happens. That's where you find the bond that was misconfigured or the server whose second power supply was plugged into the same PDU. More in Data Center Networking.
A home lab for studying
The problem: wanting real hands-on practice for something like the CCNP without touching production.
How I'd approach it: a managed switch, a pfSense or VyOS router, and a Proxmox box running virtual routers in GNS3 or EVE-NG. VLANs for management, lab, and everything else. A GRE tunnel or two to practice site-to-site setups, and lots of OSPF and BGP to break and fix.
What it teaches you: pretty much everything. This is how I'd recommend anyone learn. See Networking Homelab.
Things every project ends up teaching
- Plan more than you think you need to. Know what you're trying to accomplish, what the limits are, and what "done" looks like before picking technologies.
- Monitor before, during, and after. If you don't know what normal looked like, you can't tell whether you made it better. Wireshark, flow data, and a monitoring system all earn their keep here.
- Write it down. Configs, decisions, and why you made them. The next person to touch it might be you, and you won't remember.
Last Modified: October 12, 2026, 11:41 am