first version of the knowledge base :)

2026-03-14 11:41:54 +01:00
commit 27965301ad
47 changed files with 4356 additions and 0 deletions
--- a/Knowledge/networking/homelab-network-segmentation.md
+++ b/Knowledge/networking/homelab-network-segmentation.md
@@ -0,0 +1,131 @@
+---
+title: Network Segmentation for Homelabs
+description: Practical network segmentation patterns for separating trust zones in a homelab
+tags:
+  - networking
+  - security
+  - homelab
+category: networking
+created: 2026-03-14
+updated: 2026-03-14
+---
+
+# Network Segmentation for Homelabs
+
+## Introduction
+
+Network segmentation reduces blast radius by separating devices and services into smaller trust zones. In a homelab, this helps isolate management systems, user devices, public services, and less trusted endpoints such as IoT equipment.
+
+## Purpose
+
+Segmentation is useful for:
+
+- Limiting lateral movement after a compromise
+- Keeping management interfaces off general user networks
+- Isolating noisy or untrusted devices
+- Applying different routing, DNS, and firewall policies per zone
+
+## Architecture Overview
+
+A practical homelab usually benefits from separate L3 segments or VLANs for at least the following areas:
+
+- Management: hypervisors, switches, storage admin interfaces
+- Servers: application VMs, container hosts, databases
+- Clients: laptops, desktops, mobile devices
+- IoT: cameras, media devices, printers, controllers
+- Guest: devices that should only reach the internet
+- Storage or backup: optional dedicated replication path
+
+Example layout:
+
+```text
+VLAN 10  Management   192.168.10.0/24
+VLAN 20  Servers      192.168.20.0/24
+VLAN 30  Clients      192.168.30.0/24
+VLAN 40  IoT          192.168.40.0/24
+VLAN 50  Guest        192.168.50.0/24
+```
+
+Traffic should pass through a firewall or router between zones instead of being bridged freely.
+
+## Design Guidelines
+
+### Segment by trust and function
+
+Start with simple boundaries:
+
+- High trust: management, backup, secrets infrastructure
+- Medium trust: internal application servers
+- Lower trust: personal devices, guest devices, consumer IoT
+
+### Route between zones with policy
+
+Use inter-VLAN routing with explicit firewall rules. Default deny between segments is easier to reason about than a flat network with ad hoc exceptions.
+
+### Use DNS intentionally
+
+- Give internal services stable names
+- Avoid exposing management DNS records to guest or IoT segments
+- Consider split DNS for remote access through Tailscale or another VPN
+
+### Minimize overlap
+
+Use clean RFC 1918 address plans and document them. Overlapping subnets complicate VPN routing, container networking, and future site expansion.
+
+## Configuration Example
+
+Example policy intent for a firewall:
+
+```text
+Allow Clients -> Servers : TCP 80,443
+Allow Management -> Servers : any
+Allow Servers -> Storage : TCP 2049,445,3260 as needed
+Deny IoT -> Management : any
+Deny Guest -> Internal RFC1918 ranges : any
+```
+
+Example address planning notes:
+
+```text
+192.168.10.0/24  Management
+192.168.20.0/24  Server workloads
+192.168.30.0/24  User devices
+192.168.40.0/24  IoT
+192.168.50.0/24  Guest
+fd00:10::/64     IPv6 management ULA
+```
+
+## Troubleshooting Tips
+
+### Service works from one VLAN but not another
+
+- Check the inter-VLAN firewall rule order
+- Confirm DNS resolves to the intended internal address
+- Verify the destination service is listening on the right interface
+
+### VPN users can reach too much
+
+- Review ACLs or firewall policy for routed VPN traffic
+- Publish only the required subnets through subnet routers
+- Avoid combining management and user services in the same routed segment
+
+### Broadcast-dependent services break across segments
+
+- Use unicast DNS or service discovery where possible
+- For mDNS-dependent workflows, consider a reflector only where justified
+- Do not flatten the network just to support one legacy discovery method
+
+## Best Practices
+
+- Keep management on its own segment from the beginning
+- Treat IoT and guest networks as untrusted
+- Document every VLAN, subnet, DHCP scope, and routing rule
+- Prefer L3 policy enforcement over broad L2 access
+- Revisit segmentation when new services expose public endpoints or remote admin paths
+
+## References
+
+- [RFC 1918: Address Allocation for Private Internets](https://www.rfc-editor.org/rfc/rfc1918)
+- [RFC 4193: Unique Local IPv6 Unicast Addresses](https://www.rfc-editor.org/rfc/rfc4193)
+- [Tailscale: Subnet routers](https://tailscale.com/kb/1019/subnets)
+- [Tailscale: Access controls](https://tailscale.com/kb/1018/acls)