Alright, let's cut through the usual "zero-trust is magic" marketing. Everyone diagrams a clean hub-and-spoke until reality hits. Here's my reality: two legacy on-prem data centers, each with its own egress and no direct route between them. Management insists on deploying a Twingate connector in *each* network for "local performance."
Now I've got two separate Twingate networks, each blissfully unaware of the other, trying to protect access to the *same* set of application servers (which are stretched across both sites for disaster recovery). The predictable happens: access control lists start conflicting, resource definitions are duplicated, and my users' clients flip-flop between connectors based on DNS whims. Half my team can't reach the PostgreSQL primary in DC1, the other half is locked out of the Cassandra cluster in DC2. It's a beautiful, self-inflicted split-brain.
The official docs are useless here—they assume a single, unified network under your control. So, for those of us living in the real world of mergers, acquisitions, and technical debt: what's the actual playbook?
Is the only sane move to designate one DC as the "primary" for Twingate, swallow the latency for the other site, and force all traffic through a single connector cluster? Or is there a way to make two connectors in segregated networks synchronize state, or at least fail over cleanly, without building a custom control plane? I'm not looking for a theoretical "should"; I need the "how" from someone who's survived the network partition and lived to tell the tale. My current `twingate.yaml` for each connector looks standard, but the problem is architectural, not config.
```yaml
# DC1 Connector config - DC2's is a mirror image
network: "acme-prod-dc1"
access-token: "****"
# Trusted proxies, local routes, etc., all pointing to DC1 subnets
```
Do I need to script a DNS-based failover, or is there a Twingate-native feature for this that they don't advertise?
Oof, that sounds rough. This might be a dumb question, but why not just have one connector network but deploy the actual connector software in both data centers? Wouldn't that let you keep the single control plane for ACLs while still getting local egress? Or does Twingate not let you do that?
Containers are magic, but I want to know how the magic works.
>what's the actual playbook?
Been there. The playbook is to get out of the vendor's happy path. You need one Twingate network, not two. Then you deploy two *connectors* from that single network, one in each DC.
Here's the catch: you'll likely need to NAT or proxy the connector traffic in one site to make it look like it's egressing from the same IP range as the other, or Twingate's control plane gets confused about where the connector lives. It's a hack, but it keeps your ACLs sane.
Your real problem is that your stretched apps are now a single resource definition pointing at two backend IPs. If one DC dies, Twingate won't know to fail over. You're back to DNS tricks. Sometimes zero-trust and active-active DR just fight each other.
Trust but verify.
I had that exact same thought! It seems like the obvious fix.
But from what I've been reading, the control plane needs a stable IP or FQDN to talk to each connector. If the two sites have completely separate egress IPs, the network might see them as two separate, healthy connectors... but routing gets messy for users. The user794 reply below about NAT makes a lot of sense, even if it's a bit of a hack.
Have you ever tried setting up a connector in two locations under one network? I'm curious if the admin panel even allows it.