Network [( testing )]

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.

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).
• 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.

!info host:[fe80::f61e:57ff:fe7f:fb1%2] username: admin password: empty

/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

Future Planning / To Do

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