Twingate Headless Client Gateway
Problem
IoT devices, network appliances, and other embedded systems can't run the Twingate client but still need secure access to Twingate-protected resources. There was no official solution for environments where devices couldn't run agents - a gap that came up regularly in customer conversations, particularly in operational technology and smart office deployments.
Approach
Built a Bash automation script that configures a Linux host into a full network-aware gateway combining four layers: the Twingate headless client authenticates via a service account JSON key and brings up the encrypted tunnel interface (sdwan0); Bind9/named runs as the authoritative DNS server for connected clients, resolving both public hostnames and Twingate-protected resource addresses with ACL-restricted queries based on the configured subnet; iptables NAT masquerading with MSS clamping routes client traffic through the Twingate tunnel with automatic persistence across reboots; and the Linux kernel's IPv4 forwarding ties it together. Other devices on the network point to this host as their default gateway and DNS server, aggregating their outbound traffic through the single headless client.
Outcome
Enables zero trust access for devices that can't run agents, solving a common customer ask with no official solution at the time. Published under the Twingate-Solutions organization and accompanied by a technical document on the Twingate documentation portal, making it a supported deployment pattern rather than an ad-hoc workaround.
The v2 rewrite emphasizes production reliability: comprehensive logging to /var/log/twingate-gateway-setup.log, immediate failure detection with line numbers, idempotent re-runs that can recover or reconfigure without breaking an existing install, automatic resolution of systemd-resolved port-53 conflicts, MSS clamping for MTU optimization, and an expanded distribution support matrix covering Ubuntu 22.04 and 24.04, Debian 13, Fedora, and CentOS Stream 9.