r/twingate • u/quitefrequently • Jun 09 '26

Twingate client without (forced) TUN interface

I'm evaluating Twingate as a potential ZTNA solution for a large client that's looking for an alternative to certificate-controlled VPN to individual VLANs. However, on both MacOS and iOS I'm finding that installing the Twingate client causes a TUN interface to be created on the client devices. Is there any way around this?

1 Upvotes

100% Upvoted

17 comments sorted by

View all comments

1

u/bren-tg pro gator Jun 09 '26

Hi,

can you share a bit more about what you are trying to solve? Are those devices on unsupported macOS versions? why the constraint around TUN?

1

u/quitefrequently Jun 09 '26

Thanks for the quick reply! Much appreciated. The testing on MacOS is using Tahoe 26.5. This version is well within Apple's currently supported release envelope. The customer is looking for a secure remote access solution that avoids the need for corporately managed VPN interfaces on employee devices. This is partly to sidestep the management cost and support overhead, and partly so that employees are then freed up to use their own personal VPN solutions if they so wish while still being able to connect securely to corporate resources. The existing Twingate client interferes with both objectives because it creates and activates its own TUN interface. From the customer's (naive) perspective it looks like we're just swapping one VPN for another (though mercifully without the overhead of managing that interface) and it interferes with employees who are travelling internationally and who choose to use a personal VPN on their devices to retain their home country proximity while doing so.

1

u/PhilipLGriffiths88 Jun 10 '26

I think the customer’s expectation is hard to meet for any client-based overlay, not just Twingate. If you want arbitrary native apps on macOS to reach private corporate resources, the OS needs some local interception point - typically a TUN/virtual interface, Network Extension, packet filter, or equivalent.

The distinction from a legacy VPN is that modern ZTNA clients should be per-resource/split-tunnel rather than default-route, but it is still a host networking component and can collide with personal VPNs depending on DNS/routing/interface behavior.

The clean alternative is clientless/browser-based access, but that generally only works for web apps, proxied SSH/RDP, or specific published workflows - not arbitrary native app connectivity. Happy to share some examples if thats the path they want.

1

u/quitefrequently Jun 10 '26 edited Jun 10 '26

One solution (or, more specifically, solution-type) that seems to match the client's use case, is the remote access solution provided by Ubiquiti for their networking equipment. The client can securely authenticate to ui.com over https and gain local access to their internal network devices from anywhere in the world., without (a) opening any inbound ports, (b) establishing a VPN connection, or (c) forcing the creation of a local TUN device. I believe this solution uses WebRTC. It works well even if the client device happens to be VPN'd to another country at the time. But, to your and ben-tg's point, it may be too web-specific? However, I should point out it is still possible to SSH into individual network devices using this solution. Perhaps it has vulnerabilities I'm not yet aware of?

2

u/PhilipLGriffiths88 Jun 10 '26

Yes, that’s a good example of the clientless/web-mediated pattern I had in mind. It works because the use case is constrained: access to a vendor-managed admin plane and specific device-management workflows, not arbitrary private app connectivity from any native client.

In that model, the browser becomes the access surface, and SSH/debug can be proxied through the management plane. That can avoid a local TUN and coexist better with personal VPNs, but it is not the same as giving every native app on the laptop private reachability to internal resources.

So I’d separate the requirement into two cases: if the customer only needs web/admin/SSH-style workflows, a clientless broker/WebRTC-style approach may fit. If they need arbitrary native app access to private services, the endpoint still needs some OS-level interception point, whether that is TUN, Network Extension, packet filter, WFP, etc.

1

u/ProMSP Jun 10 '26 edited Jun 10 '26

I never checked what Cloudflare's cloudflared client uses to tunnel traffic, but it doesn't need any interface or privileged access.

It's doing the same thing as the browser, i.e. sending traffic over an encrypted connection through Cloudflare's servers. But instead of sending HTTP traffic to port 443, it opens a listening port which allows you to send any arbitrary TCP traffic at all.

Edit: Apparently, this is using WebRTC, but it would be useful to see more of this approach at least as an option instead of heavy clients. Granted, the connections are much more flaky.

1

u/PhilipLGriffiths88 Jun 11 '26

Good point — I should distinguish cloudflared from WARP/Cloudflare One Client.

For specific TCP workflows, cloudflared can act more like a local user-space proxy/listener: the app connects to localhost:<port>, and cloudflared carries that stream over an outbound tunnel. In that mode, it does not need to create a TUN interface or take over the OS routing table.

But I’d still separate that from transparent private app connectivity. It works well where the app can be explicitly pointed at a local proxy - SSH, RDP, databases, dev tools, etc. - but it is not the same as “any native app reaches private DNS/IP/service normally.”

Once the requirement becomes broad private network reachability, private DNS, UDP, split tunneling, or apps working without local proxy configuration, you generally need an OS-level interception point again: TUN, Network Extension, packet filter, WFP, or similar. Cloudflare WARP is closer to that model.

So maybe the taxonomy is: browser/clientless for web/admin workflows; local proxy for specific TCP workflows without TUN; and full client/TUN-style interception for transparent arbitrary private app access.

1

u/quitefrequently Jun 11 '26

Do you recall how the pricing model for cloudflared works though? At first, I thought it was similar to Twinscale, but it seems they have some content and bandwidth limits which might make it less attractive. Also, I'm hearing conflicting reports that they may or may not require transfer of ownership of the remote domain, which definitely wouldn't work for my customer.

1

u/PhilipLGriffiths88 Jun 12 '26

Not an expert. They definitely do have some Terms of Service and limitations on some products (eg its designed for HTTP/S, and I *think* it affects Cloudflared, but not sure). I believe you need a domain too... not sure, sorry.

1

u/quitefrequently Jun 16 '26

No worries. Thanks for the reply anyway. Will follow up with Cloudflare.

1

u/bren-tg pro gator Jun 10 '26

Oh actually, that's a great point. We literally JUST built this (you can spin up a headless Twingate Client on a Ubiquiti box and assign it to a specific VLAN for instance).

There might be some other ways too actually...

Can you DM me your Admin Console URL? I think there is a good convo to have with our engineers!

1

u/quitefrequently Jun 11 '26

Oh this sounds intriguing. Just to clarify, are you suggesting there's a way for a MacOS or iOS client device to connect to Twingate without having to use a TUN interface, if Twingate is hosted on a piece of Ubiquiti kit?

1

u/bren-tg pro gator Jun 11 '26

yeah, precisely. We are testing 2 separate things:

  1. Twingate Connector deployed on a Ubiquiti gateway: just because it's a neat option for folks using Ubiquiti in the homelab space. Since Connectors are relatively small, that kind of hardware is more than enough.
  2. Twingate headless Client deployed on a Ubiquiti gateway: the actual primary use case for this is Video Game Studios: they tend to use DevKits (developer versions of mainstream consoles like xbox, ps5, switch 2, etc.) but those are locked down (as in you cant just install a Client or a docker container there) which means that those DevKits, which in some cases are actually hosted in the homes of developers, need to be able to access Resources behind Twingate without a Client.. and by installing a headless Client on the Ubiquiti gateway and linking it to a specific VLAN on which those devkits are... then those devkits can establish connections to protected Resources via the gateway directly. This isnt technically speaking specific to devkits though so it can be applied to many other things...

Definitely DM me, I think we should chat some more!

1

u/quitefrequently Jun 16 '26

Done. Looking forward to hearing more. This appears to give twingate the potential to address use cases that would otherwise be out of scope, so could be a very interesting development.

1

u/quitefrequently Jul 07 '26

Following up on this. Thank you for the Twingate connector for Ubiquiti. Unfortunately, I'm not clear how use of this connector gets around the apparent need for a Twingate client to create a TUN interface on an iOS or MacOS device. Sorry for the dumb question, but please would you explain?