Skip to content

P01-T11 - CHR Flow Audit

Objective

Record the real validation status of HQ-CHR01 using a flow matrix instead of assuming that successful partial bring-up means the router is fully audited.

This page is an audit record, not a deployment runbook.

Audit date

Saturday, July 18, 2026, with follow-up CHR evidence on Sunday, July 19, 2026

Scope

Audit the CHR behavior that matters to the current lab:

  • administrative access
  • WAN access
  • DHCP relay
  • workstation to DC flows
  • workstation to file server flows
  • isolation controls
  • container and Cloudflare tunnel paths

Flow matrix

Flow Expected result Status Evidence / notes
VLAN100 admin -> CHR management allowed Validated base firewall validation and ongoing CHR administration from hypervisor/admin path
CHR -> Internet allowed Validated router ping tests to 1.1.1.1 and cloudflare.com succeeded
VLAN20 server -> Internet allowed Validated HQ-DC01 internet access validated through CHR
VLAN30 client -> DHCP via relay allowed Validated Linux DHCP test reproduced failure, then succeeded after relay input rules were placed before INPUT - Default Drop
VLAN30 client -> HQ-DC01 DNS allowed Validated Resolve-DnsName hq-dc01.corp.gntech.me succeeded from real Windows client after explicit forward rules were added
VLAN30 client -> HQ-DC01 AD join ports allowed Validated TCP 53, 389, and 445 succeeded from real Windows client; domain join succeeded
VLAN30 client -> GPO retrieval from HQ-DC01 allowed Validated gpresult /scope computer /r on joined client showed GPO-Workstations-Baseline and GPO-Workstations-Hardening applied from HQ-DC01.corp.gntech.me
VLAN30 client -> HQ-FS01 SMB allowed for approved shares Validated after adding the explicit workstation-to-HQ-FS01 SMB rules, Test-NetConnection 172.20.20.21 -Port 445 returned True from the workstation and real file operations against \\HQ-FS01\Public succeeded
GUEST -> LAN blocked Validated a dedicated guest audit container on 172.20.70.10 reached 172.20.70.1 and the internet, but could not reach 172.20.20.11
DMZ -> LAN blocked Validated a dedicated DMZ audit container on 172.20.80.10 reached 172.20.80.1 and the internet, but could not reach 172.20.20.11
Containers -> WAN allowed Validated Cloudflare prechecks passed for DNS, UDP, TCP, and API reachability
Containers -> HQ-DC01 DNS allowed if configured Validated container DNS rules present and cloudflared runtime succeeded
Containers -> internal origin on VLAN20 allowed only as required Partially validated tunnel/container health validated; final customer-facing origin path still depends on Cloudflare-side ingress correctness

July 19 CHR evidence

The July 19 router audit confirmed:

  • vlan30-workstations DHCP relay exists and points to 172.20.20.11 with local address 172.20.30.1
  • all documented VLAN gateway interfaces from 10 through 110 are running on ether2
  • bridge-containers owns 172.20.120.1/24
  • default route is 0.0.0.0/0 -> 172.31.255.1
  • NAT masquerade is enabled on out-interface-list=WAN
  • /system device-mode print shows container: yes
  • cloudflared:latest is running on veth-cloudflared
  • CHR ping to 172.20.20.11 succeeded with 0% packet loss
  • CHR ping to 1.1.1.1 succeeded with 0% packet loss
  • CHR ping to cloudflare.com succeeded with 0% packet loss
  • /ip firewall filter print stats was captured after validation traffic

The firewall counter evidence showed:

  • DHCP relay client broadcasts: 13 packets
  • DHCP relay server replies from HQ-DC01: 12 packets
  • workstation DNS UDP to HQ-DC01: 734 packets
  • workstation DNS TCP to HQ-DC01: 8 packets
  • workstation Kerberos TCP to HQ-DC01: 126 packets
  • workstation core UDP to HQ-DC01: 160 packets
  • workstation core TCP to HQ-DC01: 364 packets
  • workstation RPC dynamic TCP to HQ-DC01: 67 packets
  • workstation SMB TCP to HQ-FS01: 30 packets
  • guest isolation drop: 2 packets
  • DMZ isolation drop: 2 packets
  • container to WAN: 686 packets
  • container to servers: 13 packets

The first stats output confirmed duplicate workstation-to-HQ-FS01 SMB forward rules:

  • FWD - Workstations to HQ-FS01 SMB TCP appeared twice
  • FWD - Workstations to HQ-FS01 SMB UDP appeared twice
  • the active TCP rule had 30 packets
  • the duplicate TCP and UDP copies had 0 packets

This did not block traffic, but it was not acceptable as a final documented firewall state because rule counters and future troubleshooting become ambiguous. P01-T07 now includes a duplicate-cleanup block before final validation.

After cleanup, /ip firewall filter print detail where comment~"HQ-FS01 SMB" showed only one TCP rule and one UDP rule:

  • FWD - Workstations to HQ-FS01 SMB TCP
  • FWD - Workstations to HQ-FS01 SMB UDP

The post-cleanup /ip firewall filter print stats output confirmed the final rule numbers:

  • 25 = FWD - Workstations to HQ-FS01 SMB TCP, 30 packets
  • 26 = FWD - Workstations to HQ-FS01 SMB UDP, 0 packets
  • 27 = FWD - Default Drop, 850 packets

Key finding

HQ-CHR01 should not be described as fully audited unless workstation-originated flows are validated from a real client.

The gap found in this audit was:

  • DHCP relay was working
  • client addressing was correct
  • but workstation-to-DC DNS and AD traffic still hit FWD - Default Drop

That means earlier statements that CHR was "complete" were too broad. The accurate state was:

  • partially validated for routing, DHCP relay, WAN access, and container networking
  • not yet fully audited for workstation end-to-end AD consumption until the explicit forward rules were added and tested

Corrective action

The corrective action was to add explicit forward rules before FWD - Default Drop for:

  • DNS UDP/TCP
  • Kerberos
  • core AD ports
  • RPC dynamic range
  • SMB to HQ-FS01

The validated recovery method used direct place-before=[find where chain=forward comment="FWD - Default Drop"] insertion so the rules landed in the correct place immediately during a live outage.

These rules are now documented in:

Current confidence statement

As of this audit:

  • CHR is validated for the current workstation onboarding and GPO flow
  • CHR is validated for DHCP relay on VLAN30
  • CHR is validated for Cloudflare container egress and tunnel health
  • CHR guest and DMZ isolation to the DC were revalidated successfully in this cycle
  • CHR is validated for workstation-to-HQ-FS01 SMB on the approved Public share path
  • CHR is functionally validated for the current lab flows
  • CHR firewall rules are clean-final for the currently validated lab flows after duplicate workstation-to-HQ-FS01 SMB rules were removed and stats were captured again

Remaining audit tasks before calling CHR fully audited

  • confirm every future CHR rule change is reflected in both the operational runbook and this audit record if the change came from live validation