Docs

Appearance

Twingate Operations Guide ​

What Twingate Does Here ​

Twingate is the primary remote access method for all staff except CEO/CTO (who use GlobalProtect). It is a zero-trust network access (ZTNA) solution — users authenticate through Entra SSO and get access only to the specific resources they are authorized for, not the whole network.

Key design points:

  • Two connector VMs in the DMZ (vm-twingate-conn01-*, vm-twingate-conn02-*) — HA pair, either one handles full load
  • Connectors make outbound connections to Twingate cloud — no inbound ports open on the connectors
  • User identity comes from Entra (SSO) — Twingate has no separate user database
  • Device compliance is enforced via Intune integration (see Twingate Compliance Enforcement)

Admin portal: https://auth.twingate.com — sign in with your Twingate admin account (in Keeper)

Adding a New User ​

Twingate users are managed via Entra group sync — you do not add users directly in the Twingate portal.

  1. Add the user to the appropriate Entra group:

    • AllStaff — standard access (Tier 2 resources)
    • PrivilegedUsers — admin access (Tier 0 + Tier 1 resources) — Rory, Kevin, Greg
    • ContractorAccess — contractor access (limited resource set)

  2. Twingate syncs groups from Entra automatically (sync runs every few hours, or trigger manually: Twingate admin portal → Settings → Identity Provider → Sync Now)

  3. The user installs the Twingate client:

    • Windows: https://www.twingate.com/download
    • iOS/Android: App Store / Play Store — search "Twingate"
    • The network name is cirius — users enter this when setting up the client

  4. First login: user opens Twingate client → enters network cirius → authenticates with their ciriusgroup.com Microsoft account → MFA challenge

  5. Verify access in Twingate portal: Users → find the user → confirm they appear with the right group memberships

Onboarding checklist for new users: also see Onboarding Security Checklist for the full provisioning sequence including Intune enrollment, which must complete before device compliance enforcement allows Twingate Tier 0 access.

Removing a User ​

  1. Remove the user from all Twingate-mapped Entra groups
  2. Twingate syncs automatically — the user loses access within a few hours
  3. For immediate termination: Twingate admin portal → Users → find user → Suspend
  4. Also: revoke their Entra account and all active sessions per the offboarding checklist

Adding a New Resource ​

A "resource" in Twingate is any internal host or service users need to reach.

Step 1 — Decide the trust tier ​

TierExamplesRequired trust level
Tier 0Jump hosts, Panorama, Veeam management, domain controllersHigh + FIDO2
Tier 1PHI-adjacent servers, Key Vault, Terraform state storageHigh
Tier 2File shares, internal business appsMedium
Tier 3Low-sensitivity toolingMedium

Step 2 — Create a firewall rule (if needed) ​

The Twingate connectors live in the DMZ. If the new resource is in a trust-* zone, the PrivateFW already allows DMZ → trust traffic for established session types. If your new resource needs a port that is not already allowed, open a firewall change request per Firewall Change Procedure.

Step 3 — Add the resource in Twingate admin portal ​

  1. Twingate admin portal → Resources → Add Resource
  2. Name: descriptive (jump-host-prod, panorama-mgmt, file-server-01)
  3. Address: the private IP or hostname the connectors can reach
  4. Remote Network: cirius-dmz (the connector pool)
  5. Protocols: restrict to only the ports needed (do not leave open all ports)
  6. Groups: assign the Entra group(s) that should have access
  7. Security: set the minimum trust level per the tier table above
  8. Save

Step 4 — Test access ​

From a device that should have access:

  1. Open Twingate client — confirm it shows Connected
  2. Attempt to reach the new resource (SSH, RDP, browser, etc.)
  3. Confirm in Twingate portal → Logs that the connection was recorded with the correct user, device, and trust level

Troubleshooting — User Cannot Connect ​

Work through this in order before escalating.

Step 1 — Is Twingate connected? ​

User opens Twingate client. Does it show Connected or Disconnected?

  • Disconnected: see §"Client won't connect" below
  • Connected but resource unreachable: continue to Step 2

Step 2 — Does the user have access to the resource? ​

Twingate admin portal → Users → find user → Resources tab. Is the target resource listed? If not, the user's Entra group does not have access to that resource. Add the group to the resource, or add the user to the right Entra group.

Step 3 — Does the device meet the trust requirement? ​

Twingate admin portal → Users → find user → Devices tab. Check the trust level for this device. If it is lower than the resource requires:

  • Is Intune compliance state "Compliant"? Check Intune admin center.
  • Is the Twingate client up to date? Outdated clients can report stale posture.
  • Did the user just enroll a new device? Intune sync can take up to 1 hour.

Step 4 — Is the resource address correct? ​

If the connector cannot reach the resource address, the connection will time out even for authorized users. Check:

  • Is the resource IP correct and reachable from the DMZ?
  • Is the connector up? (see §"Connector health check" below)
  • Did the VM IP change? VMs get new IPs if recreated — update the resource in Twingate.

Step 5 — Check Twingate logs ​

Twingate admin portal → Logs → filter by user and time. Look for:

  • Access denied — trust level or group mismatch (fix in resource policy)
  • Resource unreachable — network path issue (check connector and firewall)
  • Authentication failed — Entra SSO issue (check Conditional Access policies)

Troubleshooting — Client Won't Connect ​

Authentication loop ​

User clicks "Sign in with Microsoft" but keeps bouncing back to the Twingate login screen. Usually a Conditional Access policy blocking the Twingate app registration.

  1. Check Entra sign-in logs for the user — look for CA policy failures
  2. Common cause: new CA policy that accidentally blocked Twingate SSO application
  3. Also check: is the user's MFA working? Try signing in to portal.azure.com directly.

Client shows connected but no resources load ​

  1. Connector may be down — check §"Connector health check" below
  2. Split-tunneling issue — Twingate uses split-tunnel (only resource traffic goes through Twingate, not all internet traffic). Some corporate proxy configurations intercept Twingate traffic — confirm the user is not behind a transparent proxy.

Client won't install / crashes on Windows ​

  1. Verify the user is running Windows 10 22H2+ or Windows 11 23H2+
  2. Check for conflicting VPN software — if GlobalProtect is also installed and running, it can conflict. GlobalProtect should only be running for CEO/CTO.
  3. Run as administrator for initial install

Connector Health Check ​

The twingate_agent.py in bedrock-hub fires CRITICAL if any connector is offline for more than 1 hour. If you receive this alert:

  1. Twingate admin portal → Network → Remote Networks → cirius-dmz — both connectors should show Online with a green dot — if one shows Offline, the other is still serving traffic (HA pair)

  2. Azure Portal → check the connector VMs:

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

  3. If the VM is running but the connector shows Offline:

    • SSH to the VM (via the other Twingate connector, or via jump host in the same subnet)
    • Check the Twingate connector service: systemctl status twingate
    • Restart if needed: systemctl restart twingate
    • Check logs: journalctl -u twingate -n 50

  4. If the VM is stopped:

    • Start it from Azure Portal or: az vm start --resource-group rg-dmz-connectors --name <vm-name>

  5. If the connector VM needs to be rebuilt, see Twingate Connector IPs for the procedure — a new IP means the firewall address object addr-twingate-connectors must also be updated in Panorama.

Both Connectors Down (Twingate Outage) ​

If both connectors are offline simultaneously, all Twingate remote access stops for all users. This is an incident.

  1. Start recovery on the connector VMs immediately (see §above)
  2. Notify affected users — they cannot access internal resources remotely
  3. If the outage will last more than 30 minutes, notify leadership
  4. CEO/CTO are unaffected — they use GlobalProtect, not Twingate
  5. For emergency access during a Twingate outage, the break-glass path is GlobalProtect for those who have it, or direct console access for admins (document in Out-of-Band Communications Plan)
  6. File a SecOps incident for the outage

Granting Temporary / Time-Bound Access ​

For contractors, vendors, or short-term access needs:

  1. Add the user to the ContractorAccess Entra group (or a purpose-specific group)
  2. Set a reminder to remove them at the access expiry date
  3. For Twingate compliance exceptions (device doesn't meet posture requirements), follow the exception process in Twingate Compliance Enforcement

Twingate Admin Accounts ​

The Twingate admin portal requires a Twingate-native admin account (separate from Entra SSO — this is the portal management account, not the end-user SSO).

Admin credentials: Keeper → "Twingate Admin Portal"

Do not use the admin account for day-to-day browsing. It exists for portal configuration only. Changes to resources, groups, and policies must be documented in SecOps stories (minor changes) or firewall change requests (changes that require firewall updates).

Monthly Health Check ​

As part of the Monthly Security Review, verify:

  • Both connectors show Online in the Twingate admin portal
  • Trust level distribution: ≥ 95% of privileged users at High trust, ≥ 90% of all staff at Medium or better
  • No stale users — users who have left should have been removed at offboarding
  • No resources pointing to decommissioned VMs or old IPs

Document History ​

DateChangeAuthor
May 2026Initial draft — covers user management, resource onboarding, troubleshooting, connector health, outage procedureRory

Internal use only — Cirius Group