15 ms·

There are so so many of these already... - Tinc (the OG of P2P VPN) - Hamachi (not open though) - ZeroTier - Nebula (from Slack) - Tailscale - Netbird I

There are so so many of these already... - Tinc (the OG of P2P VPN) - Hamachi (not open though) - ZeroTier - Nebula (from Slack) - Tailscale - Netbird I wonder why people keep building more. I know each has its own quirks and things they're better at, but the difference is really quite minimal. One of the things I really would like is zero-trust 'lighthouses'. With current Zerotier and Tailscale, you really have to trust them because they can add nodes on your account whenever they want. I don't want that, I want fully self-hosted and for the lighthouses to just coordinate but not to be part of the network. I have to do some research to see what would be best.

apitman 1y ago
And many more: https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling
geoctl 1y ago
With all respect, regardless of the fact that Octelium can replace the products you just mentioned, its context of interest is much larger and focused towards zero trust rather than just merely a yet another VPN/a remote access tool to access internal resources. I'd really appreciate it if you could read the docs first so that you can understand the features and architecture of Octelium and what it is meant to be. Every product claims to be "zero trust" these days, even VPNs and simple tunneling applications, however, actual zero trust architectures as defined by NIST (i.e. architectures built upon L7-aware identity-aware proxies, policy-decision-points, L7-aware and context-aware per-request access control via policy-as-code and ABAC, centralized identity and policy management, integrating context information from external tools such as SIEM, SSO and threat intelligence tools into per-request access control decisions, etc...) and there are many commercial products that are "true" ZTAs (e.g. Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, etc...). The term is being however abused by the companies, some of which are extremely well funded, to distort reality and the fact that their products were not even built for zero trust. What these fake "zero trust" vendors are trying to achieve is something like: "either we all are zero trust, or zero trust doesn't really exist or mean anything at all and it's merely a buzzword, it's your choice".
- mikevm 1y ago
  [dead]
metmac 1y ago
Reading through the docs. I feel like a lot of people are missing the value here. This could be a diamond in the rough if it actually delivers on its docs. What enterprises want is to move away from perimeter based security models towards the promise that Google überProxy/BeyondCorp popularized many years ago. Which has been lost in the buzzword soup. It’s very simple. 1. A clean separation between Prod, Corp, and the public internet. And the UX to hop between them as an employee is as transparent as possible. (Often times network segmentation comes with additional painful friction for engineerings.) 2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries. 3. Strong proofing of identity for every client, as an inherit requirement. The problem is everyone outside Google has incredibly diverse protocol ecosystems. It makes those three promises incredibly difficult to deliver on as a vendor. (I’ve evaluated many) To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story. To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful). The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved. Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space. Disclaimer: my opinions are my own.
- geoctl 1y ago
  Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
  - metmac 1y ago
    Will DM after I’ve had a chance to dig.
jvink 1y ago
Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT. There's reliquary [2] which I host and run for me and my hacker friends based on sanctum. [1] https://github.com/jorisvink/sanctum https://github.com/jorisvink/sanctum [2] https://reliquary.se https://reliquary.se
deleted 1y ago
[deleted]

apitman 1y ago

And many more: https://github.com/anderspitman/awesome-tunneling https://github.com/anderspitman/awesome-tunneling

geoctl 1y ago

With all respect, regardless of the fact that Octelium can replace the products you just mentioned, its context of interest is much larger and focused towards zero trust rather than just merely a yet another VPN/a remote access tool to access internal resources. I'd really appreciate it if you could read the docs first so that you can understand the features and architecture of Octelium and what it is meant to be. Every product claims to be "zero trust" these days, even VPNs and simple tunneling applications, however, actual zero trust architectures as defined by NIST (i.e. architectures built upon L7-aware identity-aware proxies, policy-decision-points, L7-aware and context-aware per-request access control via policy-as-code and ABAC, centralized identity and policy management, integrating context information from external tools such as SIEM, SSO and threat intelligence tools into per-request access control decisions, etc...) and there are many commercial products that are "true" ZTAs (e.g. Cloudflare Access, Teleport, Google BeyondCorp, StrongDM, Zscaler, etc...). The term is being however abused by the companies, some of which are extremely well funded, to distort reality and the fact that their products were not even built for zero trust. What these fake "zero trust" vendors are trying to achieve is something like: "either we all are zero trust, or zero trust doesn't really exist or mean anything at all and it's merely a buzzword, it's your choice".

mikevm 1y ago
[dead]

metmac 1y ago

Reading through the docs. I feel like a lot of people are missing the value here. This could be a diamond in the rough if it actually delivers on its docs. What enterprises want is to move away from perimeter based security models towards the promise that Google überProxy/BeyondCorp popularized many years ago. Which has been lost in the buzzword soup. It’s very simple. 1. A clean separation between Prod, Corp, and the public internet. And the UX to hop between them as an employee is as transparent as possible. (Often times network segmentation comes with additional painful friction for engineerings.) 2. One pipe to observe, and clearly attenuate permissions as traffic/messages flows between these boundaries. 3. Strong proofing of identity for every client, as an inherit requirement. The problem is everyone outside Google has incredibly diverse protocol ecosystems. It makes those three promises incredibly difficult to deliver on as a vendor. (I’ve evaluated many) To build a proxy that is protocol aware, only solves half the problem. It gets you some coarse grain decision making and a good logging story. To build a proxy that is also able to perform type-inference at the request layer, allows for a much richer authZ story. One where businesses can build an authorization layer at the proxy better than their in-house apps could even do natively. (As it turns out, having all the predicates of the request available to a policy engine is super useful). The docs are a little verbose, the marketing maybe isn’t amazing. But this is inherently a complex problem. No one has fully solved. Teleport was first to the market to OSS and commercialize a lot of these ideas. StrongDM also is doing really interesting work in this space. I wish Hashicorp had invested more in this space. Disclaimer: my opinions are my own.

geoctl 1y ago
Thank you really for your comment. I was actually hoping myself to get more questions that are related to the internals and architecture of Octelium, especially from those who are familiar with commercial ZTAs such as Cloudflare Access, Teleport, StrongDM, Google BeyondCorp, Pomerium and many other ZTNA/BeyondCorp based solutions.
- metmac 1y ago
  Will DM after I’ve had a chance to dig.

jvink 1y ago

Look into sanctum [1] it's cathedral mode. You can self-host those entirely and they're only discovery nodes. Once the tunnel is up the cathedral isn't involved unless for black key distribution or if your peers are behind restrictive NAT. There's reliquary [2] which I host and run for me and my hacker friends based on sanctum. [1] https://github.com/jorisvink/sanctum https://github.com/jorisvink/sanctum [2] https://reliquary.se https://reliquary.se

deleted 1y ago

[deleted]