A 7-week guided lecture series that bridges cloud-native architecture to bare-metal homelab infrastructure. Go from AWS VPCs to Proxmox clusters with hands-on labs every week.
Click any week to jump into the lecture content.
From copper wires to web browsers: MAC vs IP addresses, switches vs routers, ARP protocol, and hands-on CLI labs to inspect your own network stack.
VPC design, CIDR notation and subnet math, Security Groups vs NACLs, Internet Gateways, and the AWS CLI lab.
ALB vs NLB vs GLB, target groups and health checks, Auto Scaling Groups, and multi-AZ resilience.
RFC 1918 private IPs, NAT deep dive, home gateway triple-play (NAT+DHCP+DNS), double NAT, and AWS NAT options.
Type 1 vs Type 2 hypervisors, Proxmox VE installation, the Linux Bridge (vmbr0), VMs and LXC containers.
802.1Q VLAN tagging, OPNsense virtual firewall/router, VLAN-aware bridging, inter-VLAN routing rules.
Cloudflare Tunnels, DNS record types, split-horizon DNS, and the full-stack capstone architecture.
This course takes a unique approach by mirroring enterprise cloud patterns onto physical infrastructure. You'll start in the cloud with AWS VPCs, load balancers, and NAT Gateways, then translate those exact concepts to bare-metal hypervisors, OPNsense firewalls, and Cloudflare Tunnels. By the end, you'll have both a cloud VPC and a homelab running production-grade architectures.
Basic Linux CLI
Comfortable with cd, ls, ssh, and text editors (nano/vim)
AWS Free Tier Account
Sign up at aws.amazon.com — labs stay within free tier limits
A Computer for Homelab
Any x86_64 machine with 16GB+ RAM for Proxmox (Week 5+)
Curiosity & Persistence
Willingness to troubleshoot and experiment is the most important skill
From Copper Wires to Web Browsers: Landing on the Network
Welcome to Week 1! Before we spin up Virtual Private Clouds in Amazon Web Services or build Proxmox clusters on physical hardware, we have to pull back the curtain on what a network actually is. Cloud engineering and homelabbing are just software pretending to be hardware. If you don't know what a physical switch, router, or packet is, configuring them in the cloud will feel like guesswork. This week, we dismantle the mystery of how data moves from Point A to Point B.
Imagine you open your browser and type https://google.com. In less than a second, a page appears. What actually happened?
https://google.com
At its simplest, networking is just a high-speed game of telephone between two computers: your Client (the browser) and a Server (a computer sitting in a data center).
To make this happen without chaos, the tech industry relies on a conceptual blueprint called the OSI Model (Open Systems Interconnection). While the textbook model has 7 layers, as a Systems Architect, you only need to master 4 critical layers to troubleshoot 99% of infrastructure problems:
The most common point of confusion for beginners is distinguishing between Layer 2 (Local) and Layer 3 (Global). Let's break down the two distinct identities every machine on a network possesses.
Every network interface card (NIC) — whether the Wi-Fi chip in your phone or the ethernet port on a server — comes with a Media Access Control (MAC) address burned into its physical hardware at the factory.
00:1A:2B:3C:4D:5E
An Internet Protocol (IP) address is logical, not physical. It is assigned dynamically based on where your computer is currently connected.
192.168.1.50
A switch connects devices together inside the same room or building to form a Local Area Network (LAN). It only cares about MAC addresses. When a packet arrives, the switch checks its internal MAC Address Table and shoots the data down the exact physical copper cable connected to that specific device. It does not understand internet routing.
A router connects entirely different networks together (like connecting your home LAN to the global Internet WAN). Routers only care about IP addresses and determine the best highway paths to hop across the globe.
If a switch only understands MAC addresses, but your application only knows the target's IP address, how does your computer know which physical cable to send data across?
It uses ARP (Address Resolution Protocol). Think of ARP as a local roll call.
🏢 The ARP Conversation: 1. Your Laptop shouts to the whole room: "Hey! Who has the IP address 192.168.1.1? Tell me your MAC address!" (This is called an ARP Broadcast). 2. The Target Device (Your Gateway Router) replies: "That's me! My physical MAC address is 00:1A:2B:3C:4D:5E." (This is a Unicast Response). 3. Your Laptop saves this to its temporary ARP Cache memory so it doesn't have to shout every time it wants to send a packet.
Let's drop out of theory and look at your actual machine's networking stack using the Command Line Interface. Open your terminal (Linux/macOS) or Command Prompt/PowerShell (Windows).
# On Linux / macOS ip addr show # (Or 'ifconfig' on older systems) # On Windows (Command Prompt) ipconfig /all
eth0
wlan0
192.168.X.X
10.X.X.X
arp -a
# On Linux / macOS traceroute google.com # On Windows tracert google.com
1. Which layer does a MAC address operate at?
2. What protocol is used to discover a MAC address from a known IP address on a local network?
3. What is the key difference between a switch and a router?
4. What command shows the ARP cache on your machine?
ip addr
traceroute
ping
5. What does the traceroute command show?
Why Can't You Just Connect Everything to Everything?
Last week we unpacked how a single packet travels from a laptop to a web server. We learned about MAC addresses, IP addresses, switches, routers, and ARP. Now we take that same mental model and apply it to the cloud — specifically, how AWS builds virtual networks that behave exactly like the physical ones you just learned about. Cloud networking is not magic; it is just software pretending to be a switch, a router, and a cable. This week, you design a Virtual Private Cloud (VPC), master the art of subnet math, and deploy your first AWS resources.
Imagine you are the owner of an apartment complex. You own the land (the AWS Region — e.g., us-east-1 in Virginia), and you decide to build a fenced-in neighborhood on it. That fenced-in neighborhood is a VPC. Nothing gets in or out without passing through a gate that you control.
In physical networking, your neighborhood is your Local Area Network (LAN). In AWS, your LAN is a VPC. It is a logically isolated section of the AWS cloud where you launch your resources. Think of it as your own private slice of the internet that runs on AWS's physical cables, but no one else can see inside it.
💡 Key Insight: A VPC is regional — it lives inside one AWS Region (like us-east-1). You cannot stretch a VPC across regions. But you can stretch subnets across Availability Zones (AZs) within a region for high availability.
The address range for your entire VPC, e.g. 10.0.0.0/16 (65,536 addresses)
Divisions of your VPC CIDR, each in one AZ. Public or private.
The front door — allows public internet traffic into your VPC
Maps that tell traffic where to go — like street signs at every intersection
CIDR (Classless Inter-Domain Routing) is the way we tell the world how many IP addresses our network needs. Instead of saying "I need 50 IPs," we write 10.0.1.0/26 — a shorthand that means "64 addresses starting at 10.0.1.0."
10.0.1.0/26
The /26 part is called the prefix length. It tells us how many bits in the address are fixed (the network portion) versus available for hosts. The bigger the number after the slash, the smaller the network. Think of it like pizza slices: /16 is a large pizza (65,536 addresses), /24 is a personal pizza (256 addresses), and /30 is a single slice (4 addresses).
/26
/16
/24
/30
AWS reserves 5 IPs per subnet (network, gateway, 2 AWS reserved, broadcast). A /24 gives you 251 usable addresses, not 254.
⚡ Pro Tip: Use the CIDR Calculator below to practice. Try dividing 10.0.0.0/16 into 4 equal subnets. What CIDR do you use? That is right — 10.0.0.0/18, 10.0.64.0/18, 10.0.128.0/18, 10.0.192.0/18. Each gets 16,384 addresses.
10.0.0.0/16
10.0.0.0/18
10.0.64.0/18
10.0.128.0/18
10.0.192.0/18
AWS gives us two layers of security to control traffic in our VPC. Think of them like building security:
The bouncer at the door of each individual apartment. They remember who they let in, and they let that person leave and re-enter freely.
The security guard at the building entrance gate. They check every person coming in and out against a list, and have no memory of who passed before.
💡 Memory Aid: Security Groups = Smart (remembers state) • NACLs = No memory (stateless, needs explicit return rules). In practice, you use SGs 90% of the time and NACLs for broad-stroke subnet filtering.
Now we put theory into practice. You will use the AWS CLI (Command Line Interface) to create a VPC, subnets, an Internet Gateway, and route tables — all from your terminal. This is the foundation of every cloud architecture you will ever build.
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --region us-east-1 # Response includes: VpcId: vpc-0a1b2c3d4e5f6g7h8
# Replace VpcId with your actual VPC ID aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f6g7h8 --cidr-block 10.0.1.0/24 --availability-zone us-east-1a # → SubnetId: subnet-aaa aws ec2 create-subnet --vpc-id vpc-0a1b2c3d4e5f6g7h8 --cidr-block 10.0.2.0/24 --availability-zone us-east-1b # → SubnetId: subnet-bbb
aws ec2 create-internet-gateway --region us-east-1 # → InternetGatewayId: igw-xxx aws ec2 attach-internet-gateway --vpc-id vpc-0a1b2c3d4e5f6g7h8 --internet-gateway-id igw-xxx
# Create route table aws ec2 create-route-table --vpc-id vpc-0a1b2c3d4e5f6g7h8 # → RouteTableId: rtb-xxx # Add route to internet via IGW aws ec2 create-route --route-table-id rtb-xxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxx # Associate with public subnet aws ec2 associate-route-table --route-table-id rtb-xxx --subnet-id subnet-aaa
💡 What Just Happened? Your public subnet (10.0.1.0/24) now has a path to the internet via the Internet Gateway. Your private subnet (10.0.2.0/24) has no IGW route — it is truly isolated. Any EC2 instance in the private subnet cannot reach the internet (or be reached from it) without a NAT Gateway (which we cover in Week 4).
1. What is the first thing that happens when you type an IP address in your browser (before any data is sent)?
2. How many usable IP addresses does a /26 subnet provide in AWS?
3. What is the key difference between a Security Group and a Network ACL?
4. What AWS component enables a subnet to reach the internet?
5. What is the default route (0.0.0.0/0) used for?
What Happens When One Server Isn't Enough?
Last week we built a VPC with public and private subnets. We launched an EC2 instance and connected to it via SSH. But what happens when that one instance gets overwhelmed with traffic? What happens if the physical server it runs on fails? This week we learn how to distribute load across multiple servers and build systems that survive failures automatically. Think of it like a restaurant kitchen: if you only have one chef, the restaurant closes when they get sick. But with four chefs in two kitchens, and a smart hostess seating customers at the shortest line, the restaurant keeps running even during dinner rush.
A load balancer is like a receptionist at a busy office building. If everyone barged into any random office, some rooms would be overcrowded while others sat empty. The receptionist makes sure visitors are spread evenly across available offices.
In technical terms, a load balancer sits in front of your servers and distributes incoming traffic across them. Users connect to the load balancer's DNS name, not to individual servers. This gives us three superpowers: Fault Tolerance (if a server dies, traffic goes elsewhere), Scalability (add more servers behind the LB seamlessly), and Maintenance (take a server offline for updates without downtime).
The smart receptionist who reads your appointment slip. They look at the URL path (/api vs /images) and direct you to the right specialist. Best for web apps and APIs.
/api
/images
The express lane receptionist. They don't read your slip — they just look at which door you came through (IP + port) and send you to the right place instantly. Blazing fast, millions of requests per second.
The security checkpoint receptionist. They don't decide where you go — they just scan you and pass you to a security appliance (firewall, IDS/IPS) for inspection before you proceed.
A load balancer doesn't just magically know which servers are healthy. You define a Target Group — a logical grouping of your servers — and the load balancer pings each server periodically to check if it is alive. This is called a Health Check.
Imagine the receptionist calling each office every 30 seconds. If Dr. Smith's office picks up, they are healthy. If no one answers after 3 tries, they are marked "unhealthy" and no more patients are sent there. When they start answering again, patients are routed back.
A load balancer distributes traffic across servers — but what if all servers are overloaded? You need more servers. Auto Scaling Groups (ASGs) solve this by automatically adding or removing servers based on demand. Think of it like a restaurant that brings in extra chefs when the dinner line gets long, and sends them home after the rush.
The recipe card: which AMI, instance type, security group, and user data script to use when launching new instances.
Min=2 (always at least 2 servers), Desired=4 (target number), Max=10 (never exceed this).
Rules that trigger scaling: e.g., "Add 2 servers when average CPU > 70% for 5 minutes."
If AZ us-east-1a fails, the ALB sends all traffic to us-east-1b. Auto Scaling replaces lost capacity automatically.
⚡ Key Insight: Always deploy across at least 2 Availability Zones. An AZ is a physical data center (or group of buildings). If you have 4 servers all in us-east-1a and that AZ has a power outage, your entire app goes down. Spread them across us-east-1a and us-east-1b — if one AZ fails, the other still serves traffic.
1. Which load balancer type operates at Layer 7 and can route based on URL path?
2. What is the purpose of a health check?
3. What problem does deploying across multiple Availability Zones solve?
4. What is the "recipe card" that defines what an Auto Scaling Group launches?
5. What happens when an Auto Scaling Group detects an unhealthy instance?
How Does a Private Server Download Updates Without a Public IP?
In Week 2 we built a VPC with public and private subnets. We attached an Internet Gateway to the public subnet so our web servers could be reached from the internet. But what about our private servers — databases, backend APIs, application servers — that should never be directly exposed to the internet? They still need to download security updates and install packages. How? The answer is Network Address Translation (NAT). This week, we uncover how NAT works, the difference between the NAT your home router does and the NAT you need in the cloud, and why the phrase "double NAT" should make you nervous.
Look at your own home network. Your laptop, phone, and smart TV all have IP addresses like 192.168.1.101. These are private IP addresses, defined by RFC 1918. They cannot be routed on the public internet — they only work inside your own private network.
192.168.1.101
These ranges are reserved for private use. If a router on the internet sees a packet destined for 192.168.1.1, it drops it — it has no idea where that network is.
Every device in your house has a private IP like 192.168.1.101. When you visit a website, that website doesn't know about 192.168.1.101 — it only sees your public IP address (e.g., 73.45.12.89). How? NAT.
Your home router does NAT. When your laptop sends a packet to google.com, the router rewrites the "from" address (your laptop's private IP) to the router's public IP. It creates a mapping in a table so when the response comes back, it knows to forward it back to the right laptop. Without NAT, you would need a public IP for every device — and we ran out of IPv4 addresses years ago.
Step 1: Laptop wants to visit Google.com
Laptop IP: 192.168.1.101:44321 → Google IP: 142.250.80.46:80
192.168.1.101:44321
142.250.80.46:80
Step 2: Router intercepts and rewrites
Router changes source IP to its own public IP and picks a new port: 73.45.12.89:55001. It saves: 192.168.1.101:44321 ↔ 73.45.12.89:55001 in its NAT table.
73.45.12.89:55001
192.168.1.101:44321 ↔ 73.45.12.89:55001
Step 3: Google sends response
Response arrives at 73.45.12.89:55001. Router looks up its NAT table, finds the mapping, and forwards to 192.168.1.101:44321.
Your home router (whether it is a $50 TP-Link or an ISP-provided gateway) actually does three completely different jobs that are bundled into one box. As a systems architect, you need to understand each one separately because in the cloud and in enterprise environments, they are always separate services.
Converts private IPs to public IPs. Without it, your devices can't reach the internet. In AWS, the NAT Gateway does this for private subnets.
Dynamic Host Configuration Protocol — automatically assigns IP addresses to devices when they join the network. In AWS, VPC has built-in DHCP.
Translates domain names like google.com into IP addresses. In the cloud, you use Route 53 (AWS) or Cloud DNS (GCP) — separate services from NAT.
💡 Key Insight: Your home router bundles NAT + DHCP + DNS into one box. In the cloud, they are separate services: NAT Gateway, VPC DHCP options, and Route 53. When designing infrastructure, keep them separate — it makes troubleshooting, scaling, and replacing components much easier.
AWS offers a managed NAT Gateway that handles all the NAT complexity for you. It is reliable, scales automatically, and requires zero maintenance. But it costs ~$97/month (including data processing fees). For a lab or startup, that is steep.
The alternative: run a tiny EC2 NAT instance (a cheap t4g.nano) with a script that does NAT. Cost: ~$3-5/month. You trade some reliability for massive savings. In production environments with >$10k/month infrastructure, the managed NAT Gateway is worth it. In your home lab, the NAT instance wins.
Sometimes you have NAT happening twice. Picture this: you are in a hotel room. The hotel gives you one public IP for your room via their router (first NAT). You plug in your travel router (second NAT) to share that connection among your laptop, phone, and tablet. Now your traffic goes through two layers of NAT before reaching the internet. This is "Double NAT."
Double NAT causes problems for online gaming, VPN connections, and peer-to-peer apps because the inner router's NAT table is hidden from the outer router. A travel router solves this by acting as a bridge or using VPN passthrough to collapse the two NATs into one.
⚡ Real-World Application: In the cloud, "Double NAT" happens when you have a NAT Gateway in a VPC and then another NAT in a connected VPC (via peering). Traffic from VPC A → VPC B → Internet goes through two NATs, breaking many protocols. The solution: use Transit Gateway or direct VPC peering with proper route tables to avoid dual NAT.
1. What is the primary purpose of NAT?
2. Which RFC defines private IP address ranges?
3. What three services does a typical home router bundle together?
4. Why does "Double NAT" cause problems for some applications?
5. What is a cheaper alternative to a managed AWS NAT Gateway?
From the Cloud Back to Physical Hardware
For the last three weeks, everything we built was in the cloud — AWS VPCs, load balancers, NAT Gateways. These are all software simulations of hardware. Now we flip the script. We take the concepts you already learned (subnets, routing, NAT, isolation) and apply them to real physical hardware running a Type 1 hypervisor called Proxmox VE. You will learn how a hypervisor carves up one physical server into many virtual servers, and how a Linux software bridge replaces the physical switch in your rack.
A hypervisor is software that creates and runs virtual machines. Think of it as the "operating system for running operating systems." There are two types:
Runs directly on the hardware. No operating system in between. The hypervisor is the OS.
Runs on top of an existing operating system. The host OS mediates hardware access.
💡 Key Insight: When you launch an EC2 instance in AWS, you are running on a Type 1 hypervisor (AWS's proprietary Nitro hypervisor). Proxmox VE is the open-source equivalent you can run on your own hardware. The concepts are identical.
Proxmox VE is a free, open-source Type 1 hypervisor based on Debian Linux with KVM (Kernel-based Virtual Machine) for VMs and LXC for containers. It has a web-based management interface that makes VM administration simple.
Visit proxmox.com/downloads and download the latest Proxmox VE ISO Installer. Verify the SHA-256 checksum after download.
proxmox.com/downloads
Use Rufus (Windows) or balenaEtcher (macOS/Linux) to flash the ISO to a USB drive. Use DD mode if offered.
Boot from USB, select "Install Proxmox VE." Choose target disk, set hostname (e.g., pve.lab.local), management IP, and root password.
pve.lab.local
After reboot, open a browser to https://<your-ip>:8006. Login as root. Accept the self-signed certificate warning.
https://<your-ip>:8006
root
Remember in Week 1 when we talked about a switch — a device that forwards frames based on MAC addresses? Proxmox implements switching in software using a Linux Bridge. By default, Proxmox creates a bridge called vmbr0 during installation.
vmbr0
The Linux bridge is the virtual equivalent of a physical Ethernet switch. Your physical NIC (e.g., enp1s0) is plugged into the bridge like an uplink port. Each virtual machine's virtual NIC is also plugged into the bridge. The bridge learns MAC addresses and forwards frames between VMs and the physical network — exactly like a real switch.
enp1s0
auto lo iface lo inet loopback # Physical NIC — plugged into the bridge as a port auto enp1s0 iface enp1s0 inet manual # The virtual switch (Linux Bridge) — all VMs connect here auto vmbr0 iface vmbr0 inet static address 10.0.10.2/24 gateway 10.0.10.1 bridge-ports enp1s0 # Physical NIC is a "port" on the bridge bridge-stp off # Spanning Tree Protocol disabled for simplicity bridge-fd 0 # No forwarding delay # bridge-vlan-aware yes # Enable for VLAN support (Week 6)
⚡ Connection to Week 1: In Week 1, you learned that a switch forwards Ethernet frames based on MAC addresses. The Linux bridge does exactly the same thing in software. When VM-A (MAC: AA:AA) sends a frame to VM-B (MAC: BB:BB), the bridge looks at the destination MAC, checks its forwarding table, and delivers the frame to VM-B's virtual NIC. Same concept, no physical switch needed.
Full hardware virtualization. Runs any OS (Linux, Windows, FreeBSD). Higher resource overhead but maximum isolation.
qm create 100 --name ubuntu-server --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0 --scsihw virtio-scsi-pci --scsi0 rpool:32 --cdrom local:iso/ubuntu.iso qm start 100
OS-level virtualization. Lightweight, boots in seconds. Shares host kernel. Ideal for Linux services.
pveam update pveam download local debian-12-standard_12.2-1_amd64.tar.zst pct create 200 local:vztmpl/debian-12-standard_12.2-1_amd64.tar.zst --hostname lab-debian --memory 1024 --cores 1 --net0 bridge=vmbr0 --rootfs rpool:8 --unprivileged 1 pct start 200
Single-node hypervisor layout — physical hardware running Proxmox VE with ZFS storage
1. What type of hypervisor is Proxmox VE?
2. What does the Linux Bridge (vmbr0) do in Proxmox?
3. What is a key advantage of LXC containers over full VMs?
4. What port does the Proxmox web UI use?
https://<ip>:8006
5. What does the bridge-ports enp1s0 line in Proxmox config do?
bridge-ports enp1s0
bridge-ports
Splitting One Physical Network into Many Virtual Networks
Last week we built a Proxmox hypervisor with a Linux bridge (vmbr0) connecting all our VMs to the physical network. But there is a problem: all VMs are on the same flat network. That means any VM can talk to any other VM. Your database server and your public web server are on the same layer 2 domain — a security nightmare. This week we solve that with VLANs (Virtual LANs). We will split our single physical network into multiple isolated virtual networks, deploy a virtual firewall (OPNsense) to route between them, and apply the same principles you learned in AWS (Security Groups, route tables, subnet isolation) to your own hardware.
A VLAN (Virtual LAN) is a way to split a single physical network switch into multiple isolated virtual switches. Devices on different VLANs cannot talk to each other directly — they need a router to pass traffic between them. Think of it like an office building: the physical building is one switch, but different companies on different floors are separate VLANs. Company A on floor 3 cannot walk into Company B's office on floor 5 without passing through the lobby (the router).
The IEEE 802.1Q standard inserts a 4-byte tag into the Ethernet frame header. This tag contains the VLAN ID (VID), allowing switches to identify which VLAN a frame belongs to.
↑ The 802.1Q tag contains TPID (0x8100) + PCP + DEI + 12-bit VID (0-4095)
Assigned to ONE VLAN. Strips tags on egress. Used for end devices (PCs, printers, servers).
Carries MULTIPLE VLANs simultaneously. Preserves 802.1Q tags. Used between switches, routers, and hypervisors.
OPNsense is a free, open-source firewall/router based on FreeBSD. It is the open-source equivalent of pfSense but with a more modern web interface and better security defaults. In our architecture, OPNsense will:
⚡ Parallel to AWS: OPNsense is your virtual router + firewall + NAT device all in one. In AWS terms, it combines the Internet Gateway, Route Tables, NAT Gateway, Network ACLs, and Security Groups into a single software appliance that you control completely.
Download the DVD ISO (amd64) from opnsense.org/download. Upload it to Proxmox.
opnsense.org/download
NIC 1 on vmbr0 (WAN — internet facing), NIC 2 on vmbr1 (LAN — internal). Set machine type to q35.
Boot and login as installer / opnsense. Run guided installer, select ZFS. After reboot, assign WAN to the vmbr0 NIC and LAN to the vmbr1 NIC.
installer / opnsense
From a device on the LAN, browse to https://192.168.1.1. Login: root / opnsense. Complete setup wizard.
https://192.168.1.1
root / opnsense
To support VLANs, we need to tell the Linux bridge to be "VLAN-aware." This transforms vmbr0 from a simple switch into a trunk port that can carry multiple VLANs simultaneously.
auto lo iface lo inet loopback auto enp1s0 iface enp1s0 inet manual auto vmbr0 iface vmbr0 inet static address 10.0.10.2/24 gateway 10.0.10.1 bridge-ports enp1s0 bridge-stp off bridge-fd 0 bridge-vlan-aware yes # ← Enable this bridge-vids 2-4094 # ← Allow VLANs 2 through 4094
💡 How It Works: With bridge-vlan-aware yes, vmbr0 becomes a trunk port. Each VM or container's virtual NIC can be assigned a specific VLAN tag (e.g., tag=20). The bridge will tag outgoing frames and strip tags on incoming frames, isolating traffic between VLANs at Layer 2.
bridge-vlan-aware yes
tag=20
By default, OPNsense blocks all traffic between VLANs. This is the "deny by default" security principle. You create explicit allow rules to permit specific traffic between specific VLANs. This is exactly like NACLs in AWS — stateless packet filtering at the subnet boundary.
1. What standard defines VLAN tagging?
2. What is the difference between an Access port and a Trunk port?
3. In the homelab design, which VLAN should your database server be in?
4. What does bridge-vlan-aware yes do in Proxmox?
5. In OPNsense, what is the default behavior for traffic between VLANs?
Putting It All Together: From Private VPCs to Public-Facing Services
You have built cloud VPCs with subnets and security groups (Week 2). You have scaled them with load balancers and auto scaling (Week 3). You have understood how NAT connects private networks to the internet (Week 4). You have built a bare-metal hypervisor with virtual switching (Week 5). And you have segmented your network with VLANs and a virtual firewall (Week 6). Now we bring everything together. This week, we expose your internal services to the public internet securely using Cloudflare Tunnels, configure DNS so users can reach your services by name, and integrate all six previous weeks into a final capstone architecture.
Traditionally, to expose a web service to the internet, you would open a port on your firewall (e.g., port 80 for HTTP, 443 for HTTPS) and forward traffic to your internal server. This is called Port Forwarding. It works, but it is risky: every open port is a potential attack surface.
Cloudflare Tunnel (formerly Argo Tunnel) eliminates the need for open ports entirely. Instead of opening a firewall hole, you install a small daemon called cloudflared on your internal server. This daemon creates an outbound-only encrypted tunnel to Cloudflare's edge network. Users connect to your service through Cloudflare, which proxies the traffic through the tunnel to your server — without any inbound firewall rule needed.
cloudflared
curl -L https://github.com/cloudflare/cloudflared/releases/latest/... -o cloudflared sudo install cloudflared /usr/local/bin/
cloudflared tunnel login
cloudflared tunnel create my-tunnel cloudflared tunnel run --url http://localhost:8080
DNS (Domain Name System) translates human-readable domain names like app.yourlab.com into IP addresses that computers understand. Think of it as the internet's phonebook.
app.yourlab.com
Here is a common problem: You host app.yourlab.com on a server inside your home network. You set up a Cloudflare Tunnel so the public internet can reach it. The DNS record points to Cloudflare's proxy IP. This works great for users on the internet.
But what about you — sitting inside your home network? When you try to access app.yourlab.com from your laptop on the same LAN, your request goes out to the public internet (hairpin NAT), hits Cloudflare, comes back through the tunnel, and reaches your server. This is inefficient and may break.
Split-horizon DNS solves this. Your internal DNS server returns a private IP (10.0.20.x) for app.yourlab.com when queried from inside your network, while the public DNS returns Cloudflare's proxy IP for external queries. Same domain name, different answers depending on where you ask from.
Your final project integrates everything from all 7 weeks into one complete architecture. The diagram below shows how cloud VPCs and on-premise Proxmox infrastructure work together through secure tunnels and DNS.
Cloud + On-Premise Integration via Cloudflare Tunnel
1. What is the key security advantage of Cloudflare Tunnels over port forwarding?
2. What does a CNAME record do?
app.lab.com
lab.com
3. What problem does split-horizon DNS solve?
4. In the full architecture, what separates the DMZ from internal servers on the on-premise side?
5. What week's concepts map most directly to understanding how OPNsense routes between VLANs?
You have completed the Systems Architect Academy. You now have the knowledge to design, deploy, and manage infrastructure spanning cloud-native AWS environments to bare-metal homelabs with enterprise-grade networking. From VPCs and subnet math to OPNsense firewalls and Cloudflare tunnels — you can architect it all.
Architect Guide