Problems faced
- A flat network let a single compromised client reach servers and management interfaces.
- Home automation devices and guests shared the same network as work devices, with no isolation at all.
- Firewall rules had piled up over time without an explicit policy and were hard to verify.
- Address assignment and name resolution were handled inconsistently from one segment to another.
Implemented solution
The network is divided into five VLAN segments (management, servers, clients, home automation, and guests) distributed over 802.1Q trunks from a managed switch. The firewall is the only routing point between segments and applies a restrictive default policy: only documented flows are allowed. DHCP and DNS are configured per segment, with static reservations for infrastructure devices. Management interfaces are reachable only from the dedicated segment. The address plan and the flow matrix are documented and versioned.
Results
- A compromised device in one segment has no direct visibility into the other segments.
- Guests and home automation devices are isolated from the work network and from the servers.
- The flows allowed between segments are readable in a matrix and verifiable at every change.
- The management interfaces of the switch, firewall, and hypervisor are not reachable from the client segments.
Technical description
A flat network, where every device sees all the others, turns a single compromised client into a problem for the whole infrastructure. This case study shows how to separate segments in an orderly way, controlling flows at a single point.
Architecture
The perimeter firewall connects the network to the Internet and, through an 802.1Q trunk, to a managed switch and an access point. Five segments start from here: management, servers, clients, home automation, and guests. Switch ports are in access mode for end devices and in trunk mode toward the firewall, the access point, and the hypervisor; unused ports stay disabled. On Wi-Fi, each network (SSID) is mapped to a VLAN.
Routing between segments happens only on the firewall: every flow between different VLANs crosses a point where it can be filtered and logged.
Components and choices
- Restrictive default policy: whatever is not explicitly allowed is blocked. Exceptions are few, justified, and recorded in a flow matrix.
- Isolated management: the administrative interfaces of the switch, firewall, and hypervisor are reachable only from the management segment.
- Guests and home automation: guests get Internet access only; home automation devices do not initiate connections to the other segments.
- DHCP and DNS per segment, with static reservations for infrastructure. Discovery services such as mDNS, which do not cross VLANs, are forwarded only where needed.
On Proxmox VE, the VLAN-aware bridge lets you assign the segment directly to each virtual machine's network card:
auto vmbr0
iface vmbr0 inet static
address 192.0.2.10/24
gateway 192.0.2.1
bridge-ports eno1
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094Important
Before changing ports or management VLANs, set up emergency access, such as a console or an out-of-band port: a tagging mistake can cut off access to the switch and firewall.
Testing and acceptance
After every change I verify the flow matrix: from each segment I check that the allowed connections work and that the forbidden ones are blocked, comparing the results with the firewall logs. I also check DHCP lease issuance, per-segment DNS resolution, and tag consistency on both sides of every trunk. Switch and firewall configurations are saved after every change.
Possible next steps
Possible developments include: remote access through a VPN, limited to the segments that are needed, as described in WireGuard: remote access and site-to-site VPN without the complications; 802.1X authentication on ports; centralized collection of firewall logs. For a deeper look, see the article Segmenting the network with VLANs: a reference design for a homelab.