FILE 03 · Future · WAN planning

Site 2 WAN Roadmap

A future-state plan for expanding the lab from one physical site into a mirrored two-site environment connected by an edge-router-to-edge-router DMVPN overlay.

Goal

Site 2 should not be a random second network. It should mirror the Site 1 pattern so routing, firewall policy, automation, monitoring, and inter-site design can be practiced with repeatable assumptions.

Constraint

The design should stay apartment-appropriate and realistic: small hardware footprint, mixed physical/virtual gear, and public-safe documentation.

Planned topology

Edge-to-edge overlay, explicit firewall policy.

Traditional network diagram showing Site 1 LAN, core, firewall, and the EDGE-RTR01 Cisco 1941 hub connecting across a WAN cloud through a DMVPN tunnel to the planned SITE2-EDGE01 Cisco ISR 4331 spoke, firewall, core, and LAN at Site 2.

Overlay plan

Addressing, ASNs, and route policy.

Tunnel addressing

DMVPN overlay
  172.16.100.0/24

EDGE-RTR01    .1  Site 1
SITE2-EDGE01  .2  Site 2
future spoke  .3  Site 3

BGP plan

Site 1  EDGE-RTR01
  Cisco 1941 · AS 65010

Site 2  SITE2-EDGE01
  Cisco ISR 4331 · AS 65020

The flow to prove once it exists.

Site 2 to Site 1 service

Site 2 client
  → Site 2 core
  → Site 2 firewall
  → SITE2-EDGE01
  → DMVPN overlay
  → EDGE-RTR01
  → Site 1 firewall / core
  → allowed Site 1 service

Why edge routers own the overlay

DMVPN runs edge-to-edge on Cisco gear: the existing 1941 already owns the Site 1 edge (PBR/NAT), so the hub role lands there naturally, and a planned ISR 4331 becomes the Site 2 spoke on enterprise IOS-XE patterns. OPNsense stays cleaner as the security boundary at each site, and inter-site access gets allowed by service, not by broad site-to-site trust. VyOS may be introduced much later as an optional routing lab.

Site 2 addressing

Mirror the Site 1 VLAN pattern.

Core segments

MGMT    10  10.20.10.0/24
USERS   20  10.20.20.0/24
SERVERS 30  10.20.30.0/24
TRANSIT 40  10.20.40.0/30

Lab and access

LAB      50  10.20.50.0/24
WIRELESS 60  10.20.60.0/24
ADMIN    70  10.20.70.0/24
BLACKHOLE 999  no SVI

Reserved hosts

SITE2-CORE01
  10.20.10.1

SITE2-PVE01
  10.20.10.10

SITE2-EDGE01
  WAN edge · IP TBD
  tun 172.16.100.2

Design choices to test

WAN options.

DMVPN edge-to-edge

The chosen path: Cisco 1941 hub to ISR 4331 spoke for dynamic tunnel behavior, routing adjacency decisions, and hub/spoke patterns.

Firewall-to-firewall VPN

Good for policy testing and understanding how security boundaries change when sites become connected.

VyOS / virtual edge (later)

A possible much-later addition for low-cost routing practice, clean snapshots, and fast rebuilds — not the overlay owner.

Hardware path

Small, repeatable, and still enterprise-shaped.

Compute

Assign a confirmed mini-host (UM890 Pro or M1 Plus class) as SITE2-PVE01, then mirror the Proxmox VLAN-aware bridge model from Site 1.

Routing

Deploy a Cisco ISR 4331 as SITE2-EDGE01 for the WAN edge and DMVPN spoke, keeping tunnel behavior, BGP, and route policy visible on enterprise gear.

Firewall

Keep OPNsense focused on security policy and inter-site access rules instead of making it own the overlay.

Build gates

What has to be true first.

Site 1 core routing is stable, the OPNsense baseline policy is documented, monitoring and logging are live enough to observe routing changes, AUTO01/Ansible can back up network device configs, and the first Site 2 hardware role is confirmed.

Open questions

Which mini PC becomes SITE2-PVE01. Whether Site 2 needs local domain services or leans on Site 1 at first. Whether monitoring forwards to Site 1 or gets a small local collector. Whether VLANs 80 and 90 are reserved from day one.

Next steps

Build order.

Stand up Site 2 addressing.
Define VLANs, the VLAN-aware bridge model, and management boundaries before adding services.
Prove local routing first.
Site 2 internal routing must be predictable before the overlay and BGP are added.
Bring up the overlay.
Establish the DMVPN tunnel and BGP session, advertising site summaries only.
Add policy by service.
Restrict inter-site access to named services, not broad site-to-site trust.
Document packet walks.
Capture at least one allowed and one blocked inter-site flow, showing where each decision is made.