Docs

Appearance

Twingate Connectors — Private IP Governance ​

Purpose ​

Operational reference for the Twingate connectors that live in the DMZ VNET. This document is consulted whenever:

  • A PrivateFW rule needs to be scoped to "traffic from the Twingate connectors only" (the GP portal rule is the primary case).
  • A connector is replaced, recreated, or moved and its IP changes.
  • An audit reviewer asks how many connectors there are, where they run, and why the rule is scoped this way.

Related:

  • architecture/two-firewall-architecture.md — role of the DMZ in the two-firewall design
  • architecture/network-topology.md — DMZ CIDR (10.5.0.0/16)
  • runbooks/firewall-rule-reference.md — rule governance
  • Twingate admin portal — authoritative source for connector status and identity

What the Twingate Connectors Do ​

Twingate is the primary zero-trust remote-access control at Cirius. A Twingate connector is a small Linux VM that establishes an outbound tunnel to the Twingate cloud relay and brokers sessions from authenticated users to private resources. In the VPNLYR architecture:

  • The connectors sit in the DMZ VNET (not in trust-*).
  • They are the only non-GP path from a remote user to PHI.
  • They receive traffic via their outbound tunnel to Twingate cloud; they do NOT listen on any inbound public port.
  • They reach internal resources by traversing PrivateFW into the appropriate trust-* zone.
  • Each connector is locked into the twingate-connector-service-account Entra identity with only the Twingate API permissions it needs.

There are two connectors, intentionally, for HA. Either one alone can carry the full Twingate load, but the GP portal firewall rule and any audit evidence require both to be known and tracked.

Where the Two Connectors Run ​

Both connectors are Azure VMs in the same resource group but on different availability zones. The exact resource group and VM names may drift over time; this document references them by their stable role, and the real names/IPs are retrieved via az vm list.

RoleVM name patternVNETSubnetAvailability
Primary connectorvm-twingate-conn01-*vnet-dmzsnet-dmz-twingateZone 1
Secondary connectorvm-twingate-conn02-*vnet-dmzsnet-dmz-twingateZone 2

Both are joined to the DMZ RODC for local authentication and are covered by Cortex XDR and auditd.

How to Find the Current IPs ​

The IPs are not hardcoded in this document because any hardcoded address would drift the instant either VM is recreated. Instead, use one of the two canonical lookups.

Option 1 — Azure CLI (preferred) ​

From a host with PROD Azure credentials:

az vm list --resource-group rg-dmz-connectors --query "[?starts_with(name, 'vm-twingate-conn')].{name:name, id:id, nic:networkProfile.networkInterfaces[0].id}" -o table

Then for each VM, resolve its private IP:

az vm show --resource-group rg-dmz-connectors --name <vm-name> --show-details --query "{name:name, privateIps:privateIps, zone:zones}" -o table

One-line combined form:

az vm list --resource-group rg-dmz-connectors --show-details --query "[?starts_with(name, 'vm-twingate-conn')].{name:name, privateIps:privateIps, zone:zones}" -o table

Option 2 — Twingate admin portal ​

  1. Sign in to the Twingate admin portal with an admin role.
  2. Navigate to Network → Remote Networks → cirius-dmz.
  3. Both connectors appear with their assigned private IPs and status (Online / Offline).
  4. If either shows Offline for more than ~1 hour, the twingate_agent.py in bedrock-hub will already have fired a CRITICAL incident in SecOps — cross-check before raising a new one.

Option 3 — Terraform state (tie-breaker) ​

For dispute resolution only, the authoritative addresses are stored in azure-infra/tfstate/dmz.tfstate. Use terraform state show module.dmz.azurerm_network_interface.connector01 (and ...connector02) from an approved read-only checkout. Never edit state.

Why the GP Portal Rule Is Scoped to These IPs ​

The GlobalProtect portal on PrivateFW is the break-glass path for CEO/CTO. For all users who are not CEO/CTO, the only path to the GP portal is through a Twingate session — and that Twingate session always lands on one of the two connectors before PrivateFW ever sees it.

Therefore, the PrivateFW rule that allows traffic toward the GP portal interface on the DMZ-facing side is scoped to a source address object containing exactly the two connector private IPs. This:

  • Prevents any other DMZ host (e.g., RODC, future DMZ services) from even being able to reach the GP portal interface.
  • Defends against a compromised DMZ workload attempting lateral movement toward the portal.
  • Leaves the CEO/CTO break-glass path (direct internet → PublicFW → GP portal) unaffected because that flow lands on the portal's untrust-side interface, not the DMZ-side interface.

The address object in Panorama is named addr-twingate-connectors and contains two /32 entries. It is referenced by the PrivateFW rule gp-gateway-landing (see runbooks/firewall-rule-reference.md).

How to Update the Firewall Rule When IPs Change ​

This is the procedure when a connector is recreated, moved, or the IP otherwise changes. Follow it in order; never skip the final step.

  1. Confirm the new IP. Run the az vm list command above on the new or recreated connector. Verify it in the Twingate admin portal — the admin portal should report the connector Online with the new IP before you change the firewall.
  2. Open a SecOps story. Title: "Update Twingate connector IP in Panorama address object". Include the old IP, the new IP, the VM name, and a link to the Twingate admin portal status.
  3. Wait for Rory's approval. This is a firewall change. Rory is the sole approver (see runbooks/firewall-rule-reference.md). Do not edit Panorama before approval even if the connector is offline — Twingate HA means the other connector is still serving traffic.
  4. Update Panorama (Rory). In Panorama, edit addr-twingate-connectors to replace the old /32 with the new /32. Do NOT add the new IP alongside the old — unless there is a transition period where both IPs are valid, in which case note that explicitly in the commit description and schedule the old entry for removal in the same ticket.
  5. Commit and push. Panorama commit → push to device group for PrivateFW. Verify rule hit counters look sane within 10 minutes.
  6. Update this document if the procedure changes. The IPs themselves are NOT stored in this file — only the procedure. A change to how you find the IPs or how you validate the change goes here, via PR on bedrock-docs.
  7. Close the SecOps story. Reference the Panorama commit timestamp and the old/new IPs in the close note.

Monitoring ​

  • bedrock-hub/agents/twingate_agent.py — alerts CRITICAL if any connector is offline for >1 hour.
  • Panorama rule hit counter on gp-gateway-landing — sudden drop to zero may indicate an IP drift that has cut off the GP path.
  • Cortex XDR on the connectors — behavioral monitoring on the connector VMs themselves.
  • Intune compliance on any workstation using Twingate — device must be compliant before the Entra CA policy issues a session.

Non-Goals ​

This document does NOT contain:

  • The actual current private IPs — retrieve them with the commands above. Hardcoding IPs in a git-tracked doc invites drift.
  • GP portal configuration — that lives in Panorama and is referenced in runbooks/firewall-rule-reference.md.
  • Twingate license or identity configuration — in the Twingate admin portal, with audit evidence in compliance/vpnlyr-audit-evidence.md Control B.

Internal use only — Cirius Group