[alexmensch]

Thanks! One of the things that we've really focused on is making Twingate super, super easy to deploy.

From all of our customers conversations we've found that despite acknowledging that a better approach to remote access is possible, most people are really turned off by how hard it seems to be to implement a "zero trust" type solution. Our product goal is a 15-minute deployment, and our initial customers have been really excited about how easy it is to start using Twingate. One of the biggest selling points is that users can keep using the same addresses (either DNS or IP) for their resources with zero application, network or device configuration changes. That's a huge difference compared to every other product that's out there.

As far as the underlying technology is concerned, we're entirely standards-based with all transport encryption done via TLS. In fact, the name "Twingate" comes from an architectural decision that we made to ensure that multiple authorization checks are performed for every single network connection request.

If you'd like to dig more into the details, I'd definitely encourage you to read our "how it works" documentation here: https://docs.twingate.com/docs/how-twingate-works

[microcolonel]

> ...with all transport encryption done via TLS...

Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?

[alexmensch]

The client (the Twingate app on the user’s device) actually runs a transparent TCP proxy, so we’re just forwarding TCP payloads to the connector at the other end of the tunnel. This avoids the “TCP meltdown” problem of a TCP-in-TCP connection and also why we support any higher level protocol without any special configuration. (By the way, the client also runs a transparent UDP proxy.)

[hashamali]

Love this mission statement. I hope to never wrestle with VPN ever again. Good luck!