Skip to main content

Network Architecture and Traffic Flow

The Sea Of Fate network is designed with a "layered security" model that balances the convenience of a standard home network with the hardened isolation required for a secure data silo. By utilizing a multi-NIC Proxmox setup and a dedicated virtualized firewall, we have created a clear boundary between "Edge" services (ISP-facing) and "Internal" infrastructure (VLAN-segmented).

The Edge Tier: 192.168.1.0/24 (The Unfiltered Zone)

The outermost layer is governed by the ISP Edge Router (192.168.1.1). Because consumer ISP hardware is often restrictive, we have offloaded critical network logic to local services to maintain control over the "Primary" network.

  • DNS & DHCP Sovereignty: We have disabled the ISP router's DHCP in favor of a dedicated AdGuard Home instance (192.168.1.109). This allows us to enforce network-wide DNS filtering and, crucially, use DNS Rewrites. By pointing seaoffate.net directly to the pfSense WAN (192.168.1.125), we bypass the need for complex NAT Hairpinning, ensuring internal traffic stays internal.

  • Encrypted Upstreams: DNS queries are hardened against ISP snooping via DNS-over-HTTPS (DoH), utilizing Quad9 as the primary and Cloudflare as the secondary provider.

  • The Legacy Compromise: Devices like smart lights and Firesticks remain on this subnet. We accept that these devices may bypass our DNS settings; however, by keeping them on the WAN side of pfSense, they are physically unable to "see" or probe our internal archival VLANs.

The Management & Ingress Layer

Connectivity between the hosts is managed via a combination of physical hardware and virtual bridges.

  • Pear Connectivity: The built-in 1Gb/s NIC on Pear serves as vmbr0, handling the Proxmox Management UI (192.168.1.111) and the pfSense WAN interface.

  • Kiwi Isolation: Kiwi is wired at 192.168.1.112. Because Proxmox requires an untagged wired NIC for reliable management, the wireless interface (192.168.1.113) remains dormant. Crucially, Kiwi has no local firewall. All traffic from its VLANs is forced through the 2.5Gb/s link to Pear, where pfSense acts as the central traffic warden.

  • Grape (The Desktop): Connected via a 2.5Gb/s NIC directly to the Production VLAN (100) on the managed switch, ensuring high-speed access to the data silo.

VLAN Segmentation: The Internal Silo

The internal network is partitioned into functional zones, orchestrated by the pfSense VM on Pear. Each VLAN is strictly isolated, with rulesets determining exactly who can talk to whom.

VLAN Name Description & Security Posture
99 Admin/MGT The Inner Sanctum. Accessible only via a specific guest VM. All pfSense config and sensitive monitoring (Grafana/Victoria) are locked here. No external access.
100 Production The core of the project. Contains the Data Silo, extraction services, Jellyfin, Minecraft, and MySQL. Web-facing services reside here but are firewalled from the Admin VLAN.
110 Infra Back-end services: Internal DNSmasq, Vaultwarden, and the Dockge manager for container orchestration.
111 Remote/RDP Dedicated desktops for remote work. Access is restricted to WireGuard users or specific requests from the 192.168.1.0 subnet.
120 Sandbox The "Blast Zone" for experimental VMs. These are completely isolated to prevent any "containment leaks" during AI testing.
130 VPN Gate Hosts the WireGuard and OpenVPN servers. This is the only legitimate entry point into the internal network from the outside world.

Traffic Logic and Fault Tolerance

The dependency on Pear for network routing is a calculated risk. Since pfSense and the primary management tools reside on Pear, a host failure would effectively take the internal network offline. However, as the majority of the project's data and services are contained on Pear, this "single point of failure" is acceptable; if the host is down, there is no "Production" or "Infra" to manage anyway.

This architecture ensures that even as we ingest terabytes of data via Kiwi, the traffic is properly tagged and routed over the 2.5Gb/s backbone, preventing the 900Mb/s internet connection from being saturated by internal file transfers.

 

The Management Fortress: VLAN 99 and the Principle of Total Isolation

In a network where experimental AI and massive data extractions are occurring simultaneously, the security of the management layer cannot be left to chance. VLAN 99 is not merely a "management subnet"; it is a hardened silo containing a single, dedicated Virtual Machine that serves as the exclusive gateway to the network's vital organs. This VM is the only point from which the pfSense administrative interface can be reached and where the Grafana and VictoriaMetrics dashboards—which monitor the heartbeat of the 5950X on Pear and the Ryzen 5 on Kiwi—are accessible. By restricting these sensitive tools to a non-routable VLAN that is physically inaccessible from the standard Production or Internet zones, we mitigate the risk of a "lateral movement" attack. Even if a public-facing webserver in VLAN 100 were compromised via a vulnerability in Joomla or Nextcloud, the attacker would find themselves trapped in a network cul-de-sac, unable to even ping the management interface or probe the underlying Proxmox hypervisor. This "Inner Sanctum" approach is the cornerstone of our defense-in-depth strategy, ensuring that the "keys to the kingdom" are never exposed to the same traffic as a Minecraft player or a web crawler.

The Production Engine: Service Diversity and the Hidden Database Core

VLAN 100 serves as the primary operational hub for the household and the archival mission, hosting a suite of services that balance immediate utility with long-term preservation. Here, we maintain a diverse ecosystem: MediaWiki for legacy technical notes, Joomla for our public-facing web presence, Piwigo for active photo management, and this BookStack instance as our structured documentation alternative. We also host Nextcloud for file synchronization, providing a localized alternative to corporate cloud storage. However, the true strength of this VLAN lies in its "Hidden Core"—a standalone MySQL Server that acts as the data backbone for every application in the zone. By decoupling the database from the individual application servers, we improve performance and significantly harden our security posture. This MySQL instance is configured with no direct route to any network outside of VLAN 100; it exists solely to serve the internal requests of the production guests. This ensures that even if an application-level exploit occurs, the raw databases containing years of project metadata remain shielded behind an additional layer of internal firewalling.

The Containerized Triage: Quince, Blackberry, and the GPU Intelligence Layer

Within the Production zone, we utilize a specialized trio of Docker VMs to handle specific resource-intensive tasks, led by Quince and Blackberry on the primary host, Pear. Quince is our "Intelligence Node," specifically engineered to host applications that require the 16GB of VRAM provided by the NVIDIA 5060 Ti passthrough. This VM is the home of our local LLMs and Jellyfin media server, ensuring that high-compute tasks like AI inference and video transcoding have direct, hardware-level access to the GPU without competing for the host’s primary CPU cycles. In contrast, Blackberry is our "Data Workhorse." It is a high-I/O VM designed to manage the primary archival containers that don't require a GPU but do require massive throughput. Blackberry handles the complex ingestion scripts and the movement of multi-terabyte datasets within the 32TB IronWolf array. By separating the "thinking" (Quince) from the "moving" (Blackberry), we prevent a GPU driver crash or an LLM memory leak from stalling our primary data ingestion pipelines.

Physical Decoupling: Tayberry and the Kiwi Isolation Strategy

The final piece of our containerized strategy is Tayberry, which represents a critical "Physical Decoupling" of our most volatile archival tasks. Hosted on the secondary node, Kiwi, Tayberry is tasked with the high-intensity OpenAlex scholarly extraction and other Java-based processing jobs that are notorious for their aggressive RAM and I/O demands. By placing this VM on Kiwi’s Ryzen 5 platform with its own 64GB of dedicated RAM, we ensure that the "Life Management" services on Pear remain entirely unaffected by the massive Java garbage collection cycles or the "I/O Wait" death-spirals common in scholarly data processing. Both Blackberry and Tayberry are allocated multi-terabyte virtual disks sourced directly from the mechanical IronWolf ZFS pools. While we acknowledge that these 16TB and 14TB drives are relatively slow compared to our SSD rpools, their high capacity and low cost-per-terabyte make them the only viable medium for a project of this scale. We accept the slower seek times as a necessary trade-off for the ability to "hoard" the 2025 baseline at a scale that would be financially impossible using all-flash storage.

 

VLAN 110: The Infrastructure Core and Internal Resolution

VLAN 110 serves as the operational "backbone" of the internal network, providing the essential services that allow the diverse array of virtual machines and containers to communicate and maintain temporal synchronization. Unlike the Production VLAN, which is optimized for external delivery and user interaction, the Infrastructure zone is focused on internal reliability, monitoring, and security management. By isolating these services, we ensure that the "metabolism" of the Sea Of Fate network—its DNS resolution, time synchronization, and performance telemetry—remains protected from the high-traffic volatility of the Minecraft servers or the intensive I/O of the archival extractions.

Internal Name Resolution and the DNS Strategy

At the heart of this VLAN sits a dedicated DNSMasq VM that handles all internal resolution for the pfSense-governed subnets. We have deliberately chosen a "Fixed-IP" philosophy for this environment; rather than implementing a DHCP server within the infrastructure zone, every critical virtual machine and container host is assigned a static IP address. This ensures that the internal DNS records remain immutable and predictable, eliminating the "chasing" of dynamic leases during system reboots or network resets.

Our DNS architecture is tiered for both privacy and performance:

  • Internal Resolution: Local queries (e.g., blackberry.seaoffate.net) are resolved instantly by the internal DNSMasq.

  • Upstream Sovereignty: For all outward-bound traffic, DNSMasq forwards queries to the AdGuard Home instance on the edge network (192.168.1.109).

  • The DoH Boundary: We have made a strategic decision to avoid DNS-over-HTTPS (DoH) within the internal network. While we utilize DoH at the AdGuard level for all queries leaving the house (forwarded to Quad9/Cloudflare), internal traffic remains unencrypted. This reduces the computational overhead on the internal DNS VM and simplifies the troubleshooting of local resolution issues, as internal traffic is already physically isolated within the VLAN structure.

The Telemetry Vault: Grafana and VictoriaMetrics

The second pillar of the Infrastructure zone is our monitoring suite. In a departure from our usual containerization strategy, we have chosen to host Grafana and VictoriaMetrics as direct, "bare-metal" applications within a dedicated VM rather than running them in Docker. This was a calculated choice to ensure the highest possible reliability for our telemetry data; by avoiding the additional abstraction layer of a container engine, we reduce the risk of a Docker daemon failure blinding us to the host's performance during a critical resource spike. This VM acts as the centralized repository for all performance data harvested from the 5950X on Pear and the Ryzen 5 on Kiwi. VictoriaMetrics provides a high-efficiency, long-term storage solution for our time-series data, allowing us to analyze trends in ZFS ARC usage and CPU thermals over months of archival activity.

The Hybrid Transition: Vaultwarden and Dockge

Despite our initial "non-Docker" stance for infrastructure, we eventually recognized the necessity of containerization for specific, high-security, and high-management applications. We implemented a lightweight Docker environment within VLAN 110 to host:

  • Vaultwarden: A self-hosted Bitwarden-compatible server that serves as our local "Credential Silo." By hosting this within the Infrastructure VLAN rather than Production, we add a layer of isolation between our passwords and our public-facing web servers.

  • Dockge: A specialized, stack-oriented manager used to orchestrate the Docker environments across our other VMs (Quince, Blackberry, and Tayberry). Dockge allows us to manage our "Compose" files with a clean, web-based UI, providing a visual overview of the containerized ecosystem without the bloat of Portainer.

Temporal Integrity: The Planned NTP Migration

As the project matures, we have identified the lack of a localized NTP (Network Time Protocol) server as a minor but growing risk. For monitoring applications like VictoriaMetrics and Grafana, even a few seconds of "clock drift" between the Pear and Kiwi hosts can lead to misaligned telemetry and confusing logs. To rectify this, we plan to deploy a lightweight NTP server. Given its minimal resource footprint, this service will likely be co-located as an LXC (Linux Container) alongside the existing DNSMasq instance. Providing a single "Source of Truth" for time within the network will ensure that every extraction log, database entry, and monitoring point is perfectly synchronized, further hardening the integrity of the Project Codex archival record.

 

VLAN 111 & 130: Remote Access Strategy and the VPN Gateway

As we finalize the architectural layout of the Sea Of Fate network, we address the critical interfaces for remote interaction and the external gateways that allow us to maintain our silo from the outside world. This section details the pivot from resource-heavy Windows environments to lean Linux alternatives and the strategic decision-making behind our dual-VPN gateway.

VLAN 111: The Remote Desktop Pivot

VLAN 111 was originally conceived as a zone for Windows 11 RDP servers to provide a familiar desktop environment for remote tasks. However, operational reality quickly collided with our primary constraint: RAM scarcity. We observed that Windows 11 guests are exceptionally resource-hungry, consuming significant idle memory and CPU cycles just to maintain the OS background processes.

To preserve the 128GB/64GB RAM pools on Pear and Kiwi for archival and AI tasks, we are pivoting toward Linux Desktops. By utilizing NoMachine and xrdp, we can achieve high-performance remote desktop sessions with a fraction of the overhead. These Linux environments allow us to perform GUI-based management of our data extractions without the "Windows Tax," ensuring that the majority of our hardware remains dedicated to Project Codex.

The Security of Obscurity: Why No Public RDP

A strict mandate of this network is that no remote desktop ports (RDP/NoMachine) are exposed to the public internet. The security risks of open RDP ports are catastrophic, but the secondary risk is administrative: even if our passwords hold, the sheer volume of automated bot attacks would likely trigger a "Blackbox" event from our ISP. To avoid having our IP neutralized or flagged for malicious traffic, we refuse to encourage the bots. Access to VLAN 111 is only possible through the encrypted tunnels of VLAN 130.

VLAN 130: The Dual VPN Gateway

VLAN 130 serves as the singular, hardened point of entry for the Sea Of Fate network. We currently host two distinct VPN guests—WireGuard and OpenVPN—to evaluate their performance against our specific internal requirements.

  • WireGuard (The Daily Driver): WireGuard has proven superior for our standard use case, particularly regarding Split DNS. We found that WireGuard handles the transition of Windows clients into our internal DNS structure (resolving via our internal DNSmasq) with significantly less friction. It is fast, lean, and reliable for "tunnelling in" to check on an OpenAlex extraction.

  • OpenVPN (The Privacy Specialist): While we found it difficult to get the OpenVPN Windows client to correctly recognize internal split DNS, it remains a vital tool for potential privacy-focused pivots. If we decide to route our personal DNS or traffic to high-privacy jurisdictions like Iceland or cheaper Lithuania, OpenVPN’s mature routing capabilities make it the more likely candidate for a permanent, hardened outbound connection. The main reason for even mentioning Lithuania is more from the point of managing the end point of high risk services like Minecraft and other game servers because bots do frequently target any Ip addresses that host gameservers, especially Minecraft and while we could use TCPshield or a similar service the other strategy is to buy a cheap VPS and route between them, so that as the bots find the endpoint of the gameserver/s they can only ever probe the VPS and if the only port that is actually open is the game the bots will most likely quit after a relatively short period, even if the bot persists it is only the VPS and gameserver that is affected..

Conclusion: Network Architecture and Traffic Flow

The Sea Of Fate network architecture is a testament to the "Silo Strategy"—a deliberate, layered defense designed to protect the 2025 human-primary baseline. By segregating our guests across five distinct VLANs, we have ensured that:

  1. Management is physically isolated from production risks.

  2. Production is supported by a hidden database core.

  3. Infrastructure is lean, static, and monitored.

  4. Remote Access is resource-efficient and strictly internal.

  5. External Connectivity is limited to encrypted, verified tunnels.

This topology acknowledges the physical limits of our AM4 hardware and our 2.5 Gb/s backbone while providing a secure environment for AI inference and massive data archival. We have successfully transformed a consumer-grade internet connection into a professional-grade research fortress, ensuring that as the live web becomes increasingly "washed" and synthetic, our local silo remains an unalterable and accessible record of truth.

No comments to display

Back to top