HOMELAB / SANITISED ARCHITECTURE
An anonymised description of the physical network, VLANs, firewall rules, fail-open routing, current features, known limitations and planned upgrades.
DESIGN BRIEF
The MikroTik switch is the internal core. Cisco handles edge routing and selects either the normal inspected route or the restricted fail-open route. Separate PA-220 and FortiGate HA clusters provide firewall platforms, while Proxmox hosts the main virtual workloads.
FEATURES IN USE
This list covers the features currently used or actively tested. Items that only appear in the roadmap are not counted here.
VIRTUALISED SERVICES / SANITISED
Two ProDesk-class hosts provide separate Linux and Windows virtualisation paths. Public documentation shows the platform roles, but withholds hostnames, addresses, ports, exact models, software versions and VM names.
This separate path is intended for Windows infrastructure services. It is shown as planned work rather than as a currently deployed feature.
PHYSICAL TOPOLOGY / SANITISED
LOGICAL TOPOLOGY / PROTECT SURFACES
SEGMENT REGISTER / SYNTHETIC IDENTIFIERS
The letters do not correspond to deployed VLAN IDs or subnets.
| Alias | Function | Protect surface | Purpose |
|---|---|---|---|
VLAN-A | Management | Infrastructure control planes | Isolate administrative access and admit only authorised management workflows. |
VLAN-B | User devices | Interactive client systems | Provide required home and lab services without treating network location as trust. |
VLAN-C | Connected devices | IoT and embedded systems | Constrain devices to named controllers, DNS, time and approved external services. |
VLAN-D | Guest access | Unmanaged visitor devices | Offer internet access while denying private, management and service protect surfaces. |
VLAN-E | Compute | Virtual machines and containers | Separate workload traffic from hypervisor administration and limit workload dependencies. |
VLAN-F | Core services | Identity, DNS, time and platform services | Expose each shared service only to its documented consumers and applications. |
VLAN-G | Security lab | Defensive tooling and analysis workloads | Contain elevated tooling and control which telemetry sources it may ingest. |
VLAN-H | Cyber range | Disposable adversarial test workloads | Prevent test traffic from reaching production-like services or management planes. |
VLAN-I | Storage | NAS and virtualisation storage | Permit storage protocols only between authorised hosts; deny general client routing. |
VLAN-T | Firewall transit | Core-to-NGFW routed handoff | Carry routed traffic between enforcement points; host no endpoints or services. |
VLAN-X | Edge recovery transit | Core-to-edge recovery handoff | Provide a monitored degraded path with a deliberately reduced permission set. |
VLAN-N | Native / blackhole | Unexpected untagged frames | Terminate untagged traffic without a gateway, clients or useful services. |
ZERO TRUST / RULEBASE DESIGN
Management, identity, storage, workloads and public services are defined as small protect surfaces. A device does not become trusted because it joined a particular VLAN.
Rules consider source, destination, application, user, device or workload context wherever the platform supports it. Broad port-only access is an exception to justify.
Every allow rule has a named purpose, owner and expected consumers. Inter-zone traffic finishes at an explicit deny rule and temporary exceptions have review dates.
Allowed flows receive appropriate anti-malware, vulnerability, DNS, URL and file controls. Inspection depth follows risk, privacy and platform capability.
High-value management and storage paths remain isolated even from ordinary user systems. Logs are centralised so unexpected east-west behaviour can be investigated.
Rule hit counts, stale objects, shadowed rules and denied-flow logs feed periodic recertification. A syntactically valid configuration is not accepted as proof of enforcement.
| Rule purpose | Path | Application scope | Decision and controls |
|---|---|---|---|
| Administration | Admin endpoint → management plane | HTTPS / SSH to named assets | Allow with strong identity, restricted source and complete logging |
| User services | User devices → core services | DNS, NTP and named applications | Allow only documented consumers and application identities |
| Connected devices | Connected devices → controller / infrastructure | Exact controller, DNS and NTP flows | Allow narrow destinations; block lateral and management access |
| Guest egress | Guest devices → internet | Approved outbound applications | Allow via inspection; deny all internal protect surfaces |
| Workload dependencies | Compute workloads → service or update endpoints | Per-workload applications | Allow by workload need; attach threat and URL profiles where suitable |
| Public web | Internet → reverse proxy / application | TLS only | Publish through the security boundary; never expose a management interface |
| Cleanup | Any remaining source → any protect surface | Any | Deny and log at session end |
TRANSIT + EDGE
Normal traffic crosses one of the firewall HA clusters before it reaches the Cisco edge. A separate routed handoff lets Cisco use a lower-priority path which bypasses the firewall when the inspected route is unavailable. Both handoffs are infrastructure-only and contain no client devices or services.
The Cisco device runs IP Base. The IP SLA probing and policy-based routing needed for automatic health-based forwarding require a paid higher-tier feature licence, but the device is out of contract. The recovery path therefore uses normal route preference and external monitoring rather than Cisco probing or policy-based routing.
SANITISED CONFIGURATION / NON-DEPLOYABLE
! IP Base installed
! IP SLA and policy-based routing unavailable
ip route 0.0.0.0 0.0.0.0 <PAN_TRANSIT> <PRIMARY_DISTANCE>
ip route 0.0.0.0 0.0.0.0 <EDGE_RECOVERY> <HIGHER_DISTANCE>rule <PURPOSE_BASED_NAME>
from <SOURCE_SURFACE>
to <DESTINATION_SURFACE>
application <APP_IDS>
source-user <AUTHORISED_IDENTITIES>
action allow + inspect + log
rule <INTERZONE_DEFAULT>
action deny + logbridge <DATA_PLANE>
vlan-aware yes
allow <WORKLOAD_VLANS>
bridge <MANAGEMENT_PLANE>
access <VLAN-A>
host-management onlyThese examples show the type of configuration used without publishing the real addresses, interface names, object names or complete commands. They are not intended to be pasted into a device.
PLATFORM INVENTORY
Reserve equipment is identified by vendor and device role only. Exact models, software versions and management details are withheld.
CONSTRAINTS / WORKAROUNDS
| Constraint | Engineering impact | Current or planned workaround |
|---|---|---|
| Cisco IP Base licence | The installed IP Base licence does not provide the required IP SLA probing or policy-based routing features. The higher-tier IP feature licence is paid, and the device is out of contract. | Use normal routing, a documented floating static recovery route and external monitoring. Move probing and policy-based forwarding to a capable platform when the edge is replaced. |
| Core-owned gateways | Traffic between local gateways can route on the MikroTik core without traversing either firewall cluster. | Use tightly scoped controls now and move high-value protect-surface gateways or selected flows to firewall enforcement where inspection is required. |
| Recovery path bypass | Direct edge recovery can restore connectivity without the full policy, NAT and inspection guarantees of the primary NGFW path. | Treat it as monitored degraded mode, minimise its rule set and rehearse restoration to the inspected path. |
| Stateful path asymmetry | Parallel inspected and recovery paths can produce different forward and return paths, invalidating state and obscuring troubleshooting. | Keep route preference deterministic, test both directions and capture at each enforcement boundary during failover validation. |
| Single-uplink hypervisor bootstrap | Management and early workload traffic currently share part of the Proxmox host path, increasing blast radius. | Move the control plane to VLAN-A and use VLAN-aware bridges for workload and storage networks. |
| Legacy management crypto | Older platforms may require SSH algorithms that current clients reject. | Contain compatibility access to a dedicated admin path while firmware, re-keying or retirement removes the exception. |
| Cross-vendor Layer 2 semantics | Trunk, native VLAN and aggregation terminology differs across MikroTik, Cisco and the separate HPE/Aruba test environment. | Document the intended forwarding behaviour first, then validate tagging, allowed lists and LAG state independently at both ends. |
ROADMAP
LESSONS LEARNED
The failover plan depended on IP SLA tracking and policy-based routing.
How it was learnedThe Cisco device was running IP Base, which did not provide the required features. The paid higher-tier licence could not be added because the device was out of contract, so the design changed to normal routing, a floating route and external monitoring.
The backup route only reacts when the preferred route is removed.
How it was learnedRoute-table checks showed that a route can remain installed while NAT, policy, DNS or upstream forwarding is broken. Service checks are now kept separate from route preference.
Local traffic can be routed by the MikroTik core without crossing a firewall.
How it was learnedFollowing the packet path and checking each gateway showed that a default route through a firewall does not force local inter-VLAN traffic through it. Sensitive paths are now designed around the real enforcement point.
The Cisco edge can bypass the normal firewall path when connectivity fails.
How it was learnedTesting the recovery route showed that it changes NAT, logging and inspection, not just the next hop. The bypass is therefore restricted and treated as a temporary degraded state.
A session needs the same stateful path in both directions.
How it was learnedRoute and session checks showed that traffic could leave through one path and return through another. The failover test now checks forward and return routing for both new and existing sessions.
Transit networks should only join routing and firewall devices.
How it was learnedPacket captures were harder to interpret when several functions shared a path. Keeping DHCP, clients and services off the transit networks made routing faults much clearer.
Cisco, MikroTik and the firewall clusters each handle a different part of the path.
How it was learnedCLI checks found cases where the expected result depended on a rule or route on another device. A flow matrix now records the device responsible for each decision.
The PA-220 aggregate interface stayed down even though both links were connected.
How it was learnedThe MikroTik side was configured as a static LAG while the Palo Alto Networks side expected LACP. Changing the MikroTik group to LACP Active allowed the bundle to form.
Allowed-VLAN and native-VLAN commands were present, but traffic was not trunking.
How it was learnedThe running interface configuration still contained an access-mode command. Checking operational switchport state, rather than reading selected lines, exposed the mismatch.
An access point stopped adopting after a factory reset even though the trunk had worked before.
How it was learnedBefore the reset, the access point already knew to tag management traffic. After the reset it sent untagged traffic into the unused native VLAN. It was adopted on a temporary access VLAN, given the management VLAN, and then returned to the trunk.
A MAC-table lookup failed with an invalid-input marker.
How it was learnedContext help showed that the command required a real VLAN in the supported range. The failed command was a bad query, not proof that the switch lacked the MAC entry.
The fail-open design could not rely on the Cisco platform translating private addresses.
How it was learnedThe expected NAT commands were absent from CLI help and rejected by the platform. NAT therefore remains on a firewall or capable edge device instead of being assumed from Layer-3 routing support.
Several faults looked correct in the configuration but were wrong at runtime.
How it was learnedCommands showing trunk state, LACP neighbours, route installation, ARP, DHCP bindings and firewall sessions revealed what the devices were actually doing.
Some devices replied to ping but would not complete an SSH session.
How it was learnedARP and ICMP proved that the path worked. Testing with a current client then separated algorithm negotiation, device credentials, stale sessions and missing keys from network reachability.
The HPE/Aruba test switch required compatibility with older SSH behaviour.
How it was learnedThe connection reached the switch but failed during session setup. Server state, keys, logs and negotiated algorithms were checked from the console; compatibility settings were limited to the isolated management path.
Cisco, MikroTik, Palo Alto Networks and HPE/Aruba use different terms for similar jobs.
How it was learnedComparing MAC tables, tags, LACP state and packet flow showed that matching behaviour is more useful than matching command names.
The Cisco equivalent of Palo Alto Networks PBF was considered for sending selected traffic through a firewall.
How it was learnedThe required policy-based routing feature was not included with IP Base. The higher feature licence was paid and unavailable on the out-of-contract device, so this design could not be implemented there.
DNS, NTP, identity, certificates and updates cross several boundaries.
How it was learnedBlocking tests showed that an application can appear broken because one supporting service was omitted. Dependencies are now listed before the allow rule is narrowed.
Management and workload traffic still share part of one physical path.
How it was learnedBridge and trunk planning showed that one mistake could interrupt both administration and hosted services. Separating management and data is therefore the next major hypervisor change.
A VLAN, ACL, route, tracking object or security profile can exist without being active.
How it was learnedThis was seen in the unsupported IP SLA feature, the access-mode trunk and the mismatched LAG. Changes now need a traffic test and log or state evidence from the device expected to enforce them.
One successful web request does not prove the recovery design works.
How it was learnedThe useful test records the source network, selected route, firewall path, DNS result, application result and return to normal. This catches differences between guest, user, service and management traffic.
An SVI ACL can be correct in content but attached in the wrong direction.
How it was learnedThe source and reply paths were followed through the SVI, then the inbound and outbound ACL attachments were checked separately. This showed which traffic each ACL was actually evaluating.
A broad route-map can send internal traffic towards the firewall when it should stay local.
How it was learnedWalking sample packets through the PBR match showed that private and directly connected destinations also matched the source rule. Internal exclusions were required before any internet-only forwarding rule.
A healthy firewall pair does not prove that its aggregate data links are working.
How it was learnedThe PA-220 peers could report HA state while the aggregate interface remained down. LACP negotiation, member links and the active peer had to be checked as separate parts of the fault.
A single table only shows one part of an endpoint's connection.
How it was learnedDuring access-point adoption, the DHCP binding showed the assigned address, ARP showed Layer-3 reachability and the MAC table showed the VLAN and switch port. Together they located the break.
The external handoff crossed more switching infrastructure than was ideal.
How it was learnedTracing the WAN VLAN hop by hop showed that every trunk and allowed-VLAN list became part of the internet path. The longer-term design terminates the WAN at a configurable edge device as early as possible.