Earlier quoted context omitted.
Hey, great question, and your setup seems very secure, but I’m sure it would be nice to reduce some of the overhead. The right way to support your ephemeral bastion use case with Twingate will ultimately be to use a public API that we plan to launch later this year. That will allow you programmatically deploy connectors as needed. However, I’d also question whether you even need your ephemeral bastions anymore with T…
Can you explain how this is more secure than SSH to a bastion host via an out of band network?
Show HN: Twingate – A modern solution for remote access
31–40 of 52 posts
Re: Show HN: Twingate – A modern solution for remote access
#32Earlier quoted context omitted.
Can you explain how this is more secure than SSH to a bastion host via an out of band network?
Could you clarify a bit on "out of band" in this use case? In principle, if you have a way to access your bastion on a completely private--maybe physically separate / leased line--network, then that's going to be extremely secure, but maybe you had a different use case in mind?
SSH is two factor - key + password and Argo,ngrok,wireguard to a VPS provide DDoS mitigation and attack surface concealment and reduction.
I think I’m missing what your product adds.
Re: Show HN: Twingate – A modern solution for remote access
#33A few issues I have with these NoVPN products: * They are entirely proprietary or are proprietary extensions on top of open source software * The clients are mostly proprietary and the distribution channels are limited. I'm guessing no .DMG is offered for macOS due to Apple's insane restrictions on OS-integrated VPN clients. * There is usually a hard dependency on the provider for the connection, negotiation, or key…
On the pricing front, our goal is to make the service cost-competitive when you take into account the positive security externalities, but in particular the huge time sink that teams and companies put into deploying, distributing and managing a typical VPN solution. This is a big reason why we’re so focused on ease of use.
Re:BeyondCorp, I brought it up as a comparison point in my blog post, but I don’t want to appear to be making claims that our product is currently a 1:1 BeyondCorp replacement. One of the next things on our roadmap is to start exposing device inventory and posture checks as management options in the product to start getting closer to a full BeyondCorp-like offering.
However, a key insight we had in working with early beta customers is that there is significant pain to address even without getting all the way to a full zero trust / BeyondCorp state. That’s a big reason we decided to launch our product now, even before we’ve had the opportunity to add functionality we know will need to be added in the future.
Re: Show HN: Twingate – A modern solution for remote access
#34A few issues I have with these NoVPN products: * They are entirely proprietary or are proprietary extensions on top of open source software * The clients are mostly proprietary and the distribution channels are limited. I'm guessing no .DMG is offered for macOS due to Apple's insane restrictions on OS-integrated VPN clients. * There is usually a hard dependency on the provider for the connection, negotiation, or key…
At least Twingate doesn't try to do sanke oil advertising like Tailscale and sells itself as an "open source" (go have a look at their Github open issues, it's a complete disaster) while it is not. Also the other thing is, if you have a relatively small company of 50 people you will end up actually paying MORE than those seemingly overpriced yet established products like Zscaler ZPA.
For me, the only serious alternative to expensive products like ZPA are Zerotier and Pritunl. They are as transparent as open source yet still viable as businesses without being greedy or captive to VC money to extract every single dollar out of you.
Re: Show HN: Twingate – A modern solution for remote access
#35Very cool! How does this compare with Tailscale which utilizes Wireguard under the hood?
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…
Is it a TCP-only tunnel? Do you mitigate the issues with TCP-in-TCP in any way? Or do you mean DTLS?
Re: Show HN: Twingate – A modern solution for remote access
#36Re: Show HN: Twingate – A modern solution for remote access
#37We already have 100% of our business systems for 1 project using web-based access. This makes ramping new employees and doling out restricted access so much easier. If you give someone VPN access, you need to hire a full time guy to manage that bucket of pain if you want granular per-user permissions at the network-level. Web has no such problems. Everything is typically a completely independent security context in terms of network for any layer below HTTP. VPN means you have ~layer 3+ access by default to everything on that network.
There is an argument to be made for "XYZ doesn't have a web interface/API". But, I pose that this is a weak argument in 2020. Every cloud provider can be automated 100% via API calls. Every single thing you can do on the GitHub[Lab] web UI can be automated. Even if there isn't an explicit API, you can automate literally any legacy application with some mild scripting and duct tape. I've seen automation that samples a 3d application output in real-time and checks pixel colors for eventing, so I know this can be done. Bonus points here because these are typically legacy static and never-changing systems so you can code for it 1 time. There aren't really any excuses in my shop for manual labor. Setting up a new public webapp that can 2FA your employees and provision cloud resources via the AWS JSON API is not hard. You can make it hard, but you can also make it very very easy if you just focus on the value angle. Once you build one of these things, the next one takes 1/10th time time because you know how to do it. Maybe you just add a 2nd navigation option to your 1st one to manage that additional system...
Re: Show HN: Twingate – A modern solution for remote access
#38Earlier quoted context omitted.
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…
> ...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?
Re: Show HN: Twingate – A modern solution for remote access
#39https://docs.twingate.com/docs/download
To me that reads that I could just pick a known company using your service and get right in. What's going on here folks?
Re: Show HN: Twingate – A modern solution for remote access
#40Earlier quoted context omitted.
Could you clarify a bit on "out of band" in this use case? In principle, if you have a way to access your bastion on a completely private--maybe physically separate / leased line--network, then that's going to be extremely secure, but maybe you had a different use case in mind?
Out of band could be as simple as ngrok, or cloudflare Argo - or as you suggest by a separate connection. SSH is two factor - key + password and Argo,ngrok,wireguard to a VPS provide DDoS mitigation and attack surface concealment and reduction. I think I’m missing what your product adds.