Network Architecture Overview

OnyxNet is a segmented, actively operated home network used for hands-on network engineering, systems administration, infrastructure automation, and operational monitoring.

This document describes the existing architecture. Proposed improvements are documented separately from deployed configurations.

Deployment Status

Status: Operational

Network segmentation: Six deployed VLANs

Network redesign: Under review; not yet implemented

The current VLAN architecture and firewall configuration have been operational for approximately one year.

The next phase of development focuses on validating and refining the existing design rather than replacing it with an entirely new network.

Physical Infrastructure

Component	Platform	Function
Internet connection	Spectrum broadband	WAN connectivity
Router / Firewall	pfSense on AWOW AK34 mini PC	Routing and firewall policy
Managed switching	3 × Zyxel GS1200-8HPv3	VLAN-capable Ethernet switching
Wireless	2 × UniFi AP AC-Lite	Wireless client connectivity
Additional switching	Unmanaged PoE switch	Supporting device connectivity
Production virtualization	Aesir Proxmox cluster	Production VM and LXC workloads
Experimental virtualization	Vanir Proxmox environment	Testing and experimentation
Network storage	TrueNAS	Centralized data storage
Supporting systems	Raspberry Pi devices	DNS and infrastructure services

High-Level Topology

The network uses pfSense as its routing and firewall platform, with managed switches carrying traffic between the core infrastructure and connected devices.

A simplified physical representation is:

Internet
   |
Spectrum Modem
   |
pfSense Router / Firewall
   |
Core Managed Switch
   |
   +-- Downstream Managed Switching
   |
   +-- UniFi Wireless Infrastructure
   |
   +-- Proxmox Virtualization
   |
   +-- TrueNAS Storage
   |
   +-- Raspberry Pi Services
   |
   +-- Trusted, IoT and Other Devices

This illustration is a conceptual overview rather than a port-by-port wiring diagram. It does not imply every device connects directly to the core switch.

A more detailed topology will be published after the physical connections are reviewed and verified.

Logical Architecture

OnyxNet currently uses six operational VLANs:

VLAN	Name	Purpose
10	Valhalla	Management
25	Jotunheim	Internet of Things
50	Helheim	Security and cameras
99	Vanaheim	Guest access
100	Midgard	Trusted devices
1000	Asgard	Servers and data

Segmentation separates devices according to their operational roles and intended trust boundaries.

pfSense provides inter-network routing and firewall policy enforcement.

See the VLAN Segmentation document for additional details.

Design Principles

Segmentation by Function

Management, infrastructure, trusted devices, IoT equipment, cameras, and guests should not all share the same unrestricted broadcast and security domain.

VLAN segmentation provides the foundation for applying different access policies.

Controlled Inter-VLAN Connectivity

Some services require communication across VLANs.

Examples include home automation integrations, monitoring, DNS, and access to hosted services.

These exceptions should be deliberate, documented, and limited to required destinations and protocols.

Existing firewall rules will be reviewed against these goals before detailed isolation guarantees are published.

Availability and Recoverability

Supporting infrastructure includes redundant DNS services, virtualization, storage, and backup systems.

Reliability improvements remain an ongoing engineering focus.

Budget-Constrained Engineering

The current network primarily uses 1 GbE equipment.

Future 2.5 GbE or 10 GbE networking remains a longer-term objective rather than an immediate hardware purchasing requirement.

Near-term improvements should prioritize better configuration, documentation, monitoring, and operational practices using existing equipment.

Operational vs. Proposed Architecture

This documentation distinguishes three types of work:

Operational

Infrastructure that has been deployed and is in use.

Under review

Existing configurations being evaluated for correctness, security, or efficiency.

Planned or deferred

Improvements that have not been implemented.

This distinction is important because a network diagram or design proposal is not proof of a working deployment.

Architecture Decisions

Technical design choices and alternatives are documented through Architecture Decision Records.

For example, ADR-001: Ginnungagap Connectivity records why a proposed VLAN 700 transit network was superseded by a future Tailscale-based approach.

Documentation Boundaries

The public documentation intentionally excludes:

• Public IP addresses and access endpoints
• Administrative credentials and secrets
• Internal management URLs
• Sensitive firewall exports
• Unnecessary device-identifying information

Detailed operational configurations are maintained separately from this public-facing portfolio.