Overview

Network Topology and IP Allocation

This section details the subnet mapping, VLAN assignments, and IP allocation strategy. Each subnet uses a /24 mask (255.255.255.0) to ensure logical separation and manageable broadcast domains, with the exception of the Core Net which uses a /27 mask.

Network Device Inventory

Subnet & VLAN Allocation Matrix

IP Allocation Strategy

To maintain consistency across all subnets, the following IP ranges are strictly enforced within their respective CIDR blocks:

• .1: Default Gateway (Router Interface).
• .2 – 99: Static IPs.
• .100 – .250: DHCP Pool (Dynamic Assignments Not applicable to core since we expect all IPs to be assigned and documented).
• DNS: Clients use the Gateway IP; Router caches upstream DNS (1.1.1.1, 8.8.8.8).

Security Policies and Firewall Posture

The current architecture utilises a Router on a Stick (RoaS) internal topology using a single logical bridge with hardware-offloaded VLAN filtering (802.1Q).

Access Control Matrix

Prod-to-Core Pinhole Rules

To allow Prod services to function, only the following traffic is permitted from the Prod Net (10.4.4.0/24) to the Core Net (10.4.2.0/27):

• DNS: UDP 53 to Core DNS.
• Storage: TCP 2049 (NFS) or TCP 445 (SMB) to NAS.
• Version Control: TCP 22 to Git Server.
• NTP: UDP 123 for time synchronisation.

• All other traffic is implicitly DROPPED.

Layer 3 & Security Services

• Firewall Posture:
• input chain: accept (Permits unrestricted management access to the router control plane from any connected interface).
• forward chain: accept (Permits unrestricted Inter-VLAN routing across all subnets).

• Security Note: The current configuration represents an open architecture. Production deployment requires immediate hardening of the forward chain to enforce the Access Control Matrix defined above.

• WireGuard VPN: Operates on UDP 51820 with an MTU of 1420 to accommodate headers and prevent fragmentation over standard 1500 MTU WAN links.

• NAT: A masquerade rule on the srcnat chain is applied globally for all internal subnets egressing via ether1.

Layer 2 Capabilities

• Bridge Name: bridge
• VLAN Filtering: true (Strict 802.1Q compliance).

Port Configurations (ether2 - ether5)

Ports ether2, ether3, ether4, and ether5 are configured as Hybrid Trunk ports.

• PVID (Native): 88 (Landing Zone). Any device plugged in without VLAN configuration will receive a 10.8.8.x IP address.
• Tagged: Allowed to carry tagged frames for VLANs 42 (Core), 44 (Prod), 88 (Landing), and 99 (Test).

Initialisation and Bootstrap Sequence

Before executing the Terraform state, the physical hardware must be wiped and bootstrapped to establish the Terraform API user and initial Layer 3 management connectivity.

Hardware Reset Sequence

Initiate a zero-configuration state via CLI or the physical hardware pin.

Method A: CLI Execution

/system reset-configuration no-defaults=yes skip-backup=yes

Method B: Hardware Interrupt

1. Disconnect power.
2. Depress and hold the hardware reset pin.
3. Apply power while maintaining pin depression.
4. Maintain depression until the ACT (blue) LED ceases flashing.
5. Release the pin.

Base System Initialisation

Access the router via MAC Telnet or serial console to establish the out-of-band (OOB) management interface and service account.

/ip service enable api
/user add name=terraform group=full password="<PASSWORD>"
/ip address add address=10.2.2.2/24 interface=ether1
/interface bridge port remove [find]
/ip address remove [find where interface=bridgeLocal or interface=bridge or interface=defconf]
/interface bridge remove [find name=bridge]
# ---

Deployment

The local state management and Terraform execution sequence are detailed below.

# 1. Purge existing state and lock files
rm -rf .terraform/ terraform.tfstate terraform.tfstate.backup .terraform.lock.hcl
echo "Clean slate! Local Terraform state and cache removed."

# 2. Initialise provider plugins
terraform init

# 3. Validate syntax and provider constraints
terraform validate

# 4. Generate execution plan against RouterOS API
terraform plan

# 5. Commit state to hardware
terraform apply

User Network Access Control

The HomeLab network is designed to be segmented to ensure that user devices do not have direct access to critical infrastructure and vice versa. The only way for user devices to access the Core or Prod VLANs is through controlled and authenticated means, such as VPN access or specific port forwarding rules.

User devices are not directly connected to the Core or Prod VLANs. Instead, they are expected to connect to the user network (either via Wi-Fi or lan).

In the case of the user network, we enforce strict MAC address filtering (from list on the vpn dashboard) to ensure that only authenticated devices can access the network and a to list to restrict only specific devices to access the WireGuard VPN interface.

Future Planning / To Do

• TODO: Testing Net - Further planning and architectural design are required for the Testing Network. Currently designated for an isolated OpenWrt lab.