Design: Routed Management vs a Bastion Host
Why routed management through the core router beat a dedicated bastion VLAN in a single-admin lab, and when a bastion comes back.
2026-01-18#CyberDen
work: Jan 2026 · Decision record · short · CyberDen, Architecture, AccessThe options
| Pattern | How admin traffic flows | Good when |
|---|---|---|
| Bastion host | admin → hardened jump box → targets | compliance requires a recorded choke point; many admins |
| Router as jump | admin → core router → targets | the router is already trusted and in-path |
| Routed management (chosen) | admin workstation routes the lab via the core router; direct SSH/RDP to targets | single admin, the router already enforces east–west policy |
Why routed management won here
- It fixed the actual problem (asymmetric routing, W03) at Layer 3
- No extra OS, sshd or failure domain
- The admin workstation is the privileged endpoint and the core router is the choke point, so the admin path follows the control plane
- The bastion I'd built (OpenBSD on its own VLAN) still dropped sessions for host-level reasons, and fixing it would have added nothing
When I'd bring a bastion back
- More than one admin
- A need for session recording or audit trails (I'd want this before exposing remote access)
- Remote access over VPN from the ThinkPad: VPN → MFA → bastion → management
How I removed it
Bottom-up, so nothing was left orphaned: switch VLAN membership → VyOS sub-interface and routes → pfSense static routes → repurpose the VM.
Sources: SSH RDP Session Drops (14–18 Jan 2026), CyberDen master dump (ThinkPad remote-access design)