Docs

Appearance

Two-Firewall Architecture ​

Purpose ​

This document describes the Cirius Group two-firewall (layered) remote-access architecture implemented under the VPNLYR project. The design places two independent Palo Alto firewalls in series between the internet and any resource that stores or processes PHI, ensuring that a compromise of either firewall alone cannot expose production data.

This is the authoritative description of the design for HIPAA evidence, onboarding, incident response, and change review. It is NOT a rule reference — see runbooks/firewall-rule-reference.md for rule governance and Panorama for the actual live policy set.

Related documents:

  • architecture/network-topology.md — VNET/VPC IP ranges and route design
  • compliance/three-layer-access-architecture.md — ZTNA + Entra + Intune layers that sit on top of this firewall layer
  • compliance/vpnlyr-audit-evidence.md — HIPAA / SOC2 control mapping
  • runbooks/twingate-connector-ips.md — connector IP governance
  • security/palo-alto-overview.md — firewall platform reference

Design Principles ​

  1. Two independent chokepoints. Any traffic path from internet to PHI traverses both PublicFW (internet-facing) and PrivateFW (internal), in that order. Either firewall can independently drop the traffic.
  2. DMZ between the two firewalls. All externally-reachable services (Twingate connectors, RODC) live in the DMZ VNET. DMZ cannot reach PHI networks directly — all east-west traffic from DMZ to internal passes through PrivateFW.
  3. No internal system is internet-facing. There is no public IP on any VM that holds PHI. The only public-reachable endpoints are the GlobalProtect portal (on PublicFW) and the Twingate cloud relay.
  4. Break-glass path is out-of-band. GlobalProtect for CEO/CTO bypasses Twingate but still lands in the DMZ — it must still traverse PrivateFW to reach PHI, and is subject to Entra ID conditional access with MFA.
  5. Rule governance by design. Firewall rule changes are Rory-only. The architecture exists so the rule set can stay minimal and auditable.

Component Overview ​

                               Internet
                                  │
                                  ▼
                      ┌───────────────────────┐
                      │      PublicFW         │
                      │  (azure-prod-firewall)│
                      │  Internet-facing      │
                      │  Zones: untrust, dmz, │
                      │         management    │
                      └───────────────────────┘
                                  │
                                  │   Untrusted side: inbound
                                  │   GP portal (CEO/CTO), outbound
                                  │   internet from DMZ only
                                  ▼
                      ┌───────────────────────┐
                      │       DMZ VNET        │
                      │                       │
                      │  - Twingate Conn x2   │
                      │    (HA pair)          │
                      │  - RODC (DMZ auth)    │
                      │                       │
                      │  NO PHI, NO SERVERS   │
                      └───────────────────────┘
                                  │
                                  │   East-west traffic DMZ → internal
                                  │   inspected by PrivateFW
                                  ▼
                      ┌───────────────────────┐
                      │      PrivateFW        │
                      │   Internal firewall   │
                      │  Zones: dmz, trust-id,│
                      │         trust-prod,   │
                      │         trust-dev,    │
                      │         trust-legacy  │
                      │                       │
                      │  GlobalProtect portal │
                      │  (DMZ-facing)         │
                      └───────────────────────┘
                                  │
                  ┌───────────────┼───────────────┐
                  ▼               ▼               ▼
          ┌─────────────┐  ┌────────────┐  ┌────────────┐
          │ Identity    │  │    Prod    │  │    Dev     │
          │ VNET        │  │   VNET     │  │   VNET     │
          │ (Entra + AD)│  └────────────┘  └────────────┘
          └─────────────┘

                           Legacy VNET (being decommissioned, June 2026)

PublicFW — Internet-Facing ​

  • Role: first line of defense between the public internet and everything behind it. Hosts untrust, dmz, and management zones.
  • Devices (per CLAUDE.md): azure-prod-panorama (mgmt plane), azure-prod-firewall (data plane).
  • What it allows inbound: GlobalProtect portal for CEO/CTO only, and only from allowlisted IPs where that is practical. Nothing else is exposed to the public internet.
  • What it allows outbound: egress from DMZ (Twingate connectors reaching Twingate cloud, RODC patching) subject to URL filtering, DNS Security, and WildFire inspection.
  • What it does NOT do: does not terminate user sessions to PHI. Users that reach PHI must also authenticate through PrivateFW.

PrivateFW — Internal / East-West ​

  • Role: inspects all east-west traffic between DMZ and internal trust zones (Identity, Prod, Dev). Hosts the GlobalProtect portal on its DMZ-facing interface so GP users are re-authenticated to reach trust zones.
  • Default posture: deny-by-default between zones. Any permit rule is scoped to service/destination.
  • What it allows: narrowly-scoped inter-VNET policy (domain replication, Twingate resource access, WSUS, monitoring) — the rules documented at a category level in runbooks/firewall-rule-reference.md.
  • What it does NOT do: no internet egress originates on PrivateFW — anything leaving the environment egresses via PublicFW.

DMZ VNET ​

  • No PHI, no domain members that serve production users. Only three roles live here:
    1. Two Twingate connectors (HA pair, see runbooks/twingate-connector-ips.md).
    2. Read-Only Domain Controller (RODC) — provides DMZ-local AD auth for the Twingate connectors and any DMZ-resident service without letting an attacker on a DMZ host dump the full AD database.
    3. Future: GlobalProtect portal interface on PrivateFW (DMZ side), WildFire sinkhole, future DLP egress inspector.

RODC in DMZ ​

The DMZ RODC is intentional: Twingate connectors need AD auth for user session brokering, but putting a writable DC in the DMZ would be a violation of the zero-trust assumption (DMZ is treated as semi-hostile). RODC stores only a filtered set of credentials, cannot write back to AD, and is protected by the same PrivateFW east-west policy as any other DMZ host.

Traffic Flow Descriptions ​

Flow 1 — Standard user, Twingate path (normal case, SOC2 CC6.1) ​

  1. User workstation (Intune-compliant, Entra-authenticated) establishes an outbound HTTPS tunnel to the Twingate cloud relay.
  2. Twingate cloud relay brokers a session to one of the two DMZ connectors (PublicFW allows outbound DMZ→Twingate cloud; inbound to DMZ is via the connector's own outbound tunnel, so no inbound public port).
  3. Connector forwards the session to the target PHI resource via PrivateFW. PrivateFW inspects the east-west traffic (zone rule dmz→trust-prod, narrowly scoped to specific resources).
  4. Resource responds; reply traverses the same path in reverse.

Two firewalls touched: PublicFW (connector egress), PrivateFW (DMZ → trust-* inspection).

Flow 2 — CEO/CTO GlobalProtect path ​

  1. User launches GlobalProtect client; client authenticates to the GP portal on PublicFW. TLS terminates on PublicFW; allowed only from any untrust source because CEO/CTO travel, but restricted to the published portal FQDN.
  2. GP portal redirects to the GP gateway on PrivateFW (DMZ-facing interface). User re-authenticates against Entra ID with MFA; the client must still be Intune-compliant per CA policy.
  3. PrivateFW issues a tunnel into trust-* zones per the user's group membership (CEO/CTO only).
  4. PHI access is inspected by PrivateFW policy.

Two firewalls touched: PublicFW (portal landing), PrivateFW (gateway and east-west policy). Each firewall enforces its own independent auth (portal cert, then Entra/Intune MFA).

Flow 3 — Server outbound internet (patch / telemetry) ​

  1. Server in trust-prod initiates outbound HTTPS (e.g., Windows Update, Cortex XDR telemetry).
  2. PrivateFW zone rule trust-prod → dmz permits only the specific egress proxy/path.
  3. PublicFW zone rule dmz → untrust permits outbound HTTPS, runs URL filtering, DNS Security, and WildFire file inspection on downloads.
  4. Response returns the same path.

Two firewalls touched: PrivateFW (internal egress authorization), PublicFW (internet egress with security profiles).

Flow 4 — What does NOT work by design ​

  • Direct inbound from internet to a server in trust-*: no path.
  • DMZ host to trust-prod without explicit rule: denied at PrivateFW.
  • Server-to-server across trust-prod and trust-dev: no peering; no firewall policy exists to permit it. Dev cannot reach prod.

Validation Checklist ​

Use this checklist when validating a new remote-access path, a new rule, or periodic two-layer assurance (quarterly HIPAA evidence).

  • [ ] PublicFW inbound posture — Confirm only GP portal FQDN is reachable on TCP/443 from a scanner outside the Cirius network. No other service responds on a public IP. Evidence: nmap from an AWS Networking account EC2, output captured.
  • [ ] GP portal unreachable without Twingate — From an unmanaged device on a residential ISP, confirm the GP portal does not respond on the standard user's IP (CEO/CTO carve-out exempt). Evidence: curl output, firewall hit counter on the deny rule.
  • [ ] GP portal reachable via Twingate — With an authorized CEO/CTO user on an Intune-compliant device connected via Twingate, confirm the GP portal responds and auth succeeds. Evidence: GP authentication log event, Twingate session log.
  • [ ] DMZ → PHI denied by default — From a Twingate connector host shell (admin-only), confirm no TCP path exists to any trust-prod resource that is not explicitly permitted by PrivateFW policy. Evidence: PrivateFW deny counter, Cortex XDR record of the attempt.
  • [ ] Dev cannot reach Prod — From a dev VM, attempt TCP to a prod VM on any port. Must fail. Evidence: PrivateFW drop log.
  • [ ] Internet egress is inspected — Confirm a test download on a prod VM produces a WildFire verdict record and (where applicable) a URL filtering log entry. Evidence: WildFire verdict log, wildfire_agent.py findings output.
  • [ ] RODC scope — Confirm RODC is NOT a member of the writable replication set for privileged accounts. Evidence: repadmin or AD Users and Computers replication policy screenshot.
  • [ ] Break-glass path still works — Annually, confirm the break-glass GP path works for the CTO with MFA and Intune compliance enforced. Any break-glass sign-in must trigger a SecOps incident.
  • [ ] Both firewalls produce logs — Confirm PublicFW and PrivateFW both forward traffic logs to cirius-logging-law-central and S3 WORM archive. Evidence: recent log timestamps in LAW, object count in S3 prefix.

Change Boundary ​

Rory is the sole approver for any change to this architecture. This document reflects the design as-built. Proposed changes are raised via the VPNLYR backlog in SecOps and reviewed before any rule or VNET is touched. See runbooks/firewall-rule-reference.md for the rule change procedure and security/firewall-change-procedure.md for Palo-specific mechanics.

Internal use only — Cirius Group