4 ms·

Impressive work, congrats on the launch! Aside from the OSS perspective, how would you compare your service to Twingate?

jamilbk 2y ago
Thanks! We're similar to Twingate in how we model resources, but our policy system has optional conditions you can apply to restrict access further, which works a bit differently. We expect to continue building in that area over time. We also use WireGuard as a transport while I believe Twingate operates over QUIC.
- PLG88 2y ago
  My understanding is that Twingate uses a service-based access model, rather than host/IP/ACL-based, as Wireguard defines the world. As you are based on WG, have you somehow paperer over that to move away from network trust and lack of scalability (that I read across HN/Reddit/YT) inherent to other WG based solutions?
  - jamilbk 2y ago
    I may not be fully understanding the question, but I think you may be referring to DNS-based resources? Those will allow you to manage access to an app or service by its DNS name (wildcards supported). You can also use IP or CIDR resources as well of course. In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?
    - PLG88 2y ago
      I refer to doing service based connections, abstracted away from whether its DNS, IP or something else. To do this you really need a private DNS function and to operate with attribute based access controls. Complexity of policy mngt. I read that ACLs are fine at small scale but become a nightmare at larger enterprise scale.
      - jamilbk 2y ago
        Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer. It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone https://www.firezone.dev/blog/how-dns-works-in-firezone In terms of attributes for allowing access, we currently support time-based, country/region-based, auth method, and IP-based, with more planned: https://www.firezone.dev/kb/deploy/policies#conditional-access-policies https://www.firezone.dev/kb/deploy/policies#conditional-acce...

jamilbk 2y ago

Thanks! We're similar to Twingate in how we model resources, but our policy system has optional conditions you can apply to restrict access further, which works a bit differently. We expect to continue building in that area over time. We also use WireGuard as a transport while I believe Twingate operates over QUIC.

PLG88 2y ago
My understanding is that Twingate uses a service-based access model, rather than host/IP/ACL-based, as Wireguard defines the world. As you are based on WG, have you somehow paperer over that to move away from network trust and lack of scalability (that I read across HN/Reddit/YT) inherent to other WG based solutions?
- jamilbk 2y ago
  I may not be fully understanding the question, but I think you may be referring to DNS-based resources? Those will allow you to manage access to an app or service by its DNS name (wildcards supported). You can also use IP or CIDR resources as well of course. In terms of scalability, are you referring to throughput or simply the complexity of policy management as the number of resources grows?
  - PLG88 2y ago
    I refer to doing service based connections, abstracted away from whether its DNS, IP or something else. To do this you really need a private DNS function and to operate with attribute based access controls. Complexity of policy mngt. I read that ACLs are fine at small scale but become a nightmare at larger enterprise scale.
    - jamilbk 2y ago
      Firezone's DNS-based routing is able to manage access to multiple services independently, even if they share the same IP address. So you could for example allow access to gitlab.company.com but not jira.company.com even if they were on the same webserver / loadbalancer. It took a couple iterations to get it right - lots of fun edge cases involved. We ended up having to build automatic NAT64 and 46 for DNS resources to handle some of them. We wrote a post on how this works: https://www.firezone.dev/blog/how-dns-works-in-firezone https://www.firezone.dev/blog/how-dns-works-in-firezone In terms of attributes for allowing access, we currently support time-based, country/region-based, auth method, and IP-based, with more planned: https://www.firezone.dev/kb/deploy/policies#conditional-access-policies https://www.firezone.dev/kb/deploy/policies#conditional-acce...