VLAN Segmentation
Network segmentation is a foundational part of the OnyxNet architecture.
The environment has six operational VLANs, each serving a different device or infrastructure category.
The VLANs and existing firewall policies have been in production for approximately one year.
This document distinguishes deployed network segments from security-policy intentions that still require formal verification.
Operational VLAN Inventory
Section titled “Operational VLAN Inventory”| VLAN ID | Name | Purpose | Status |
|---|---|---|---|
| 10 | Valhalla | Management | Operational |
| 25 | Jotunheim | IoT | Operational |
| 50 | Helheim | Security / Cameras | Operational |
| 99 | Vanaheim | Guest | Operational |
| 100 | Midgard | Trusted Devices | Operational |
| 1000 | Asgard | Server / Data | Operational |
VLAN 10 — Valhalla
Section titled “VLAN 10 — Valhalla”Function: Infrastructure management
Valhalla is the management network used for administering network infrastructure and associated management interfaces.
The objective is to keep management functionality separate from ordinary client and guest traffic.
Management access policies are a priority for the upcoming firewall and network design review.
VLAN 25 — Jotunheim
Section titled “VLAN 25 — Jotunheim”Function: Internet of Things
Jotunheim contains smart devices and home automation-related equipment.
Some devices require controlled connectivity to internal services such as Home Assistant.
The network design must balance device usability with the risks introduced by less-trusted endpoints.
VLAN 50 — Helheim
Section titled “VLAN 50 — Helheim”Function: Security and cameras
Helheim is dedicated to camera and security equipment.
The intended security model restricts camera connectivity to necessary internal services, including network video recording.
Unnecessary Internet access should be blocked where equipment requirements permit.
The exact current firewall rules still require review and validation before those restrictions can be presented as verified guarantees.
VLAN 99 — Vanaheim
Section titled “VLAN 99 — Vanaheim”Function: Guest access
Vanaheim provides connectivity for guest devices.
The intended trust model allows guests to reach the Internet without granting broad access to management, server, or trusted-device networks.
The deployed access-control rules will be verified as part of the network policy review.
VLAN 100 — Midgard
Section titled “VLAN 100 — Midgard”Function: Trusted devices
Midgard contains trusted personal devices and client systems.
These devices may require access to selected IoT devices, infrastructure services, and applications hosted elsewhere on the network.
The long-term goal is to document these exceptions as explicit service access requirements.
VLAN 1000 — Asgard
Section titled “VLAN 1000 — Asgard”Function: Servers and data
Asgard contains server infrastructure and hosted services.
Services may need to communicate with management systems, trusted devices, storage, DNS, or application-specific endpoints.
These communications should be governed by explicit firewall policies rather than broad, unrestricted inter-VLAN access.
Firewall Policy Review
Section titled “Firewall Policy Review”The VLAN configuration is operational, but deployment status alone does not establish that every security boundary is functioning exactly as intended.
The following table records policy goals for subsequent verification.
| Source | Intended Access | Review Objective |
|---|---|---|
| Guest | Internet services | Prevent unintended access to internal networks |
| Cameras | Required recording services | Restrict unnecessary internal and external access |
| IoT | Approved automation services | Limit broad access to trusted and server networks |
| Trusted | Required internal services | Document necessary inter-VLAN exceptions |
| Management | Infrastructure administration | Limit management access to authorized systems |
| Servers | Required application dependencies | Review exposed services and cross-VLAN permissions |
Important: This is a policy-review checklist, not a validated representation of the current pfSense ruleset.
Future Validation
Section titled “Future Validation”The next firewall review should include:
- Documenting current firewall rules and aliases.
- Mapping rules to specific service requirements.
- Reviewing rule order and unintended permissions.
- Testing permitted and prohibited connectivity.
- Recording results and any exceptions.
- Updating public documentation with verified findings.
Sensitive configuration exports and internal management information should remain private.
Historical Proposal — VLAN 700
Section titled “Historical Proposal — VLAN 700”Ginnungagap
Section titled “Ginnungagap”Original status: Proposed
Current status: Superseded — Never implemented
Proposed transit network: 10.0.10.0/31
VLAN 700 was originally considered for a dedicated offsite backup connectivity design.
The proposed solution involved cross-site routing infrastructure and additional remote networking equipment.
After reconsidering the actual requirements, Tailscale was selected as the preferred approach for a future offsite backup system.
VLAN 700 is not part of the operational VLAN inventory.
The offsite backup project itself remains deferred due to budget constraints.
The complete decision is documented in ADR-001: Ginnungagap Connectivity.