Hello everyone,
I’ve been evaluating Twingate for our organization over the past few weeks, primarily for providing secure remote access to our on-premise ERP and inventory management systems. I’ve read through a considerable number of threads here and in other communities before deploying, and I must say the overall feedback was positive, which led to our pilot. However, I’ve run into a persistent issue that I haven’t seen discussed in great detail, and I’m hoping to gather some experiences from others who might be in a similar situation.
I am using the Twingate client on a MacBook Pro running the latest version of macOS Sonoma. The client works flawlessly when initially connecting and during active use. The problem arises consistently when the Mac wakes from sleep. The Twingate client appears to still be running and shows as connected in the menu bar, but actual network connectivity to the protected resources is lost. For example, I can no longer reach our NetSuite sandbox or the internal reporting servers. The only way to restore functionality is to manually disconnect and then reconnect the client.
This is particularly disruptive for workflows that involve long-running queries or report generation, where the laptop might go to sleep briefly and then the connection is silently broken. I have checked the client logs, which are enabled, but the entries around the sleep/wake events don’t clearly indicate a failure—they seem to suggest the connection is maintained. I have also ensured that all power-saving settings related to network are at their defaults, as I’ve seen that can sometimes interfere with similar VPN-style services.
My setup is relatively standard: Twingate Connector on a Linux instance in our data center, with the Mac client configured per the deployment guide. No other network security software is running that would conflict, like a traditional VPN or certain endpoint protection tools. I have tried reinstalling the client and recreating the network configuration from scratch, but the issue returns after a sleep cycle.
Has anyone else encountered this specific behavior with the Mac client after sleep? If so, were you able to identify a root cause or a reliable workaround beyond manual reconnection? I am curious if this might be related to a particular macOS network stack interaction or a timing issue during wake-up. Any insights from your own testing or production use would be greatly appreciated as I compile my findings for our IT security team.
This exact behavior was the reason we dropped Twingate during our last eval cycle. The menu bar icon is lying to you, it's maintaining a control channel but the data plane tunnels are dead on sleep/wake. We confirmed it with packet captures, the client stops sending TCP keepalives on the tunnel interfaces after waking up.
Check your system logs, you'll probably see a cascade of timeout errors from the tunnel driver. The official support line was to implement a launchd agent to restart the service on wake, which is a band-aid that introduces its own race conditions. We moved to a different solution that handles network namespace persistence correctly.
FinOps first, hype last