Network Consciousness - Ongoing Thoughts & Learning Log
Project Overview
Date Started: October 29, 2025 Goal: Document the journey of building a secure homelab network architecture with VLANs and advanced segmentation strategies. Status: In Progress
Session 1: Initial Architecture Design & VLAN Philosophy
Key Insights
- VLANs Are Not Magic - They’re a tool, not a
complete solution. They work best when combined with:
- Proper firewall rules (deny by default)
- Regular security audits
- Monitoring and alerting
- Employee/user education (in enterprise) or personal discipline (in homelab)
- The “Default Deny” Principle - Instead of opening
everything and closing bad traffic, we:
- Deny everything by default
- Whitelist specific allowed traffic
- This inverts the security posture from “open unless blocked” to “closed unless allowed”
- Real-World Problem: Initial flat network caused:
- No visibility into device communication patterns
- Compromised devices could reach sensitive data
- No natural boundaries between security domains
- Difficult to troubleshoot what should/shouldn’t work
Architectural Decisions Made
- 5 VLANs vs. 20+: Started simple rather than over-engineering
- pfSense Choice: Needed open-source, transparent firewall with VLAN support
- Managed Switch Requirement: Unmanaged switches can’t understand VLAN tagging
- Wireless Integration: Separate SSIDs per security domain, not one network
Concerns & Notes
- ⚠️ VLAN Hopping Risk: Double-tagging attacks possible if not defended against
- ⚠️ Configuration Complexity: One typo in firewall rule can break entire segment
- ⚠️ Performance Overhead: Minimal in homelab, but routing between VLANs adds latency
- ⚠️ Legacy Device Compatibility: Older IoT devices may not support VLAN tagging properly
Session 2: Deep Dive - Firewall Rule Philosophy
Rules Analysis
IoT VLAN (Most Restrictive): - Only DNS/NTP outbound - Why? - IoT devices often do automatic cloud updates - By restricting to DNS/NTP only, we prevent exfiltration - Control their “phone home” behavior
- Specific server access - Why?
- If IoT needs to reach services, make it explicit
- This prevents a compromised bulb from accessing your database
Server VLAN (Moderate Restriction): - Internal server-to-server communication - Why? - Kubernetes pods may need to talk to each other - Databases need client access - But external clients are restricted
- Controlled internet access - Why?
- Server updates (apt, docker pull, etc.)
- API calls to external services
- But logging/monitoring of outbound connections
Trusted VLAN (Most Permissive): - Personal devices get broad access - Why? - Users shouldn’t be constantly blocked by firewall - But still isolated from untrusted networks - Can access internet directly without restrictions
Critical Realization
The firewall rules aren’t just about blocking bad traffic—they’re about enforcing trust boundaries. Each VLAN represents a trust level, and rules enforce what that trust level can access.
Session 3: Implementation Gotchas & Solutions
Problem #1: Switch VLAN 1 Native Configuration
Issue: VLAN 1 is special—it’s the management VLAN by default Why it matters: Misconfiguring this can lock you out of device management Solution: Keep VLAN 1 unused or dedicated to device management access only
Problem #2: WiFi AP Integration
Issue: How do consumer WiFi APs handle VLANs? Solution: Not all do equally well - Enterprise APs (UniFi, Omada, Aruba): Excellent VLAN support - Consumer APs: Limited or no VLAN support - Workaround: Use AP’s guest network feature to approximate isolation
Problem #3: DHCP Scopes Per VLAN
Issue: Each VLAN needs its own DHCP scope Solution: pfSense can run DHCP for multiple VLANs - VLAN 30: 10.0.30.100-200 (IoT) - VLAN 50: 10.0.50.100-200 (Trusted) - Prevents IP conflicts, allows isolation
Problem #4: DNS Per VLAN?
Question: Should each VLAN have different DNS? Current approach: Single DNS (10.0.0.1 on firewall), but could do: - Blocklist DNS for IoT VLAN (prevent malware C&C) - Content filtering for guest network - Separate DNS for privacy-conscious VLAN
Session 4: Security Threats & Mitigations
Threat: VLAN Hopping (802.1Q Double Tagging)
How it works:
Attacker sends packet with two VLAN tags:
[outer: VLAN 30] [inner: VLAN 20]
Switch removes outer tag (still in VLAN 30)
Next device sees inner tag and processes as VLAN 20Mitigation: 1. Disable switchport trunking on access ports 2. Set access ports to specific VLAN (not trunk mode) 3. Keep firmware updated 4. Monitor for unusual VLAN transitions
Threat: ARP Spoofing Within VLAN
How it works: Attacker sends fake ARP responses to redirect traffic Mitigation: - Enable DHCP snooping - Enable Dynamic ARP Inspection (DAI) - Static ARP entries for critical devices
Threat: Rogue DHCP Server
How it works: Attacker runs DHCP server, gives clients wrong gateway Mitigation: - DHCP snooping identifies and blocks rogue DHCP - Trust only authorized DHCP ports - Monitor for unexpected DHCP activity
Threat: Legitimate Device Compromise
How it works: Attacker gains control of IoT device, uses it to scan network Mitigation: This is what VLANs actually prevent - Compromised device is trapped in its VLAN - Firewall rules prevent it from reaching other networks - Segmentation limits blast radius
Session 5: Monitoring & Visibility
What Should We Monitor?
- VLAN Transitions
- Which devices are sending/receiving on multiple VLANs?
- Should normally see only firewall devices doing this
- Alert on unexpected cross-VLAN activity
- Firewall Rule Hits
- Which rules are being triggered?
- Expected: IoT trying to reach non-whitelisted destinations
- Unexpected: Trusted devices trying to reach restricted servers
- DNS Queries
- What domains are IoT devices trying to reach?
- Can detect C&C communication
- Can optimize firewall rules based on actual usage
- Bandwidth by VLAN
- Normal patterns: Gradual increase
- Suspicious patterns: Sudden large transfers
- Indicators of data exfiltration
Tools to Use
- pfSense native: Logs in
/var/log/filter.log - Prometheus: Collect metrics from pfSense
- Grafana: Visualize network traffic patterns
- Tcpdump: Deep packet inspection when needed
Session 6: Common Mistakes to Avoid
Mistake #1: Too Many VLANs Too Soon
❌ Creating 20 VLANs for every possible use case ✅ Start with 3-5, add as needed
Why: More VLANs = more rules = more places to make mistakes
Mistake #2: Forgetting About Management Access
❌ Creating a management VLAN, then being unable to access firewall ✅ Always keep management access clear and documented
Why: You WILL get locked out if you’re not careful. Physical reset is painful.
Mistake #3: Assuming Firewall Rules “Just Work”
❌ Writing complex rules without testing ✅ Start with “allow all,” monitor, then gradually restrict
Why: Rules interact in complex ways. Test in low-impact first.
Mistake #4: Not Documenting VLAN Allocation
❌ Creating VLANs verbally, no written record ✅ Keep a spreadsheet: VLAN ID, Name, IP Range, Purpose, Rules
Why: You’ll forget by next month. Future you needs this.
Mistake #5: Ignoring Physical Security
❌ Assuming VLANs prevent physical attacks ✅ Secure physical switch access, cable management
Why: Anyone with physical access can bypass VLANs using port mirroring or ARP spoofing tools
Session 7: Cost-Benefit Analysis
Investment Required
| Component | Cost | Necessity |
|---|---|---|
| Managed Switch | $200-600 | CRITICAL |
| pfSense Hardware | $150-400 | CRITICAL |
| Enterprise WiFi AP | $100-300 | RECOMMENDED |
| Monitoring Tools | Free-$500 | OPTIONAL |
| Total | $450-1800 | High value |
Benefit: Time Saved
- Initial setup: 6-8 hours
- Monthly maintenance: 30 minutes
- Troubleshooting: Faster with clear network boundaries
Benefit: Security Improvement
- Before: One compromised device = full network access
- After: One compromised device = isolated to its VLAN, blocked from sensitive resources
Benefit: Learning
- Deep understanding of network protocols
- Practical security knowledge
- Confidence in your infrastructure
Session 8: Future Enhancements to Explore
Short-term (Next 3 months)
Medium-term (3-6 months)
Long-term (6-12 months)
Session 9: Portfolio Angle - Why This Matters
For Hiring Managers
This VLAN project demonstrates: 1. Security Thinking - Not just building, but securing 2. Systems Thinking - Understanding how components interact 3. Attention to Detail - Firewall rules require precision 4. Problem-Solving - Troubleshooting network issues 5. Documentation - Critical for production systems
For Engineers Reviewing Code
“They understand network isolation and can probably appreciate defense-in-depth in software architecture too”
For SRE/DevOps Perspective
- This person understands infrastructure isolation
- Can probably architect Kubernetes network policies well
- Thinks about security boundaries early, not as afterthought
Session 10: Lessons & Observations
What Went Well
✅ Choosing pfSense early saved switching later ✅ Starting with “default deny” principle worked great ✅ Documentation (this file!) is invaluable ✅ Testing rules individually before final deployment
What Was Harder Than Expected
❌ Figuring out DHCP scoping across VLANs ❌ Understanding VLAN switching vs. routing concepts ❌ WiFi integration (most APs have limited VLAN support) ❌ Monitoring and visibility setup
Key Takeaways
- Segmentation is about trust, not just blocking
- Documentation is as important as configuration
- Network security is a practice, not a one-time setup
- Monitoring is MORE important than firewall rules (you can’t secure what you don’t see)
- Keep it simple, then add complexity carefully
Notes for Future Self
When you’re frustrating about a firewall rule not working: 1. Check firewall logs first 2. Verify VLAN tagging on switch 3. Confirm DHCP scope for that VLAN 4. Use tcpdump to see actual traffic 5. Sleep on it, solutions come when you’re not staring at the problem
You’ve got this. The fact that you’re documenting this journey means you’re building real expertise, not just clicking buttons.
Last Updated: October 29, 2025 Next Review: November 12, 2025 (2 weeks to implement feedback)