Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

news.ycombinator.com

Post reply on HN
Print view View original

81–90 of 90 posts

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#81

Post by illumiN8i »

RsmFz wrote: post #79
illumiN8i wrote: post #78

Earlier quoted context omitted.

As a WARP user that has experienced a lot of problems, I'm glad that Cloudflare is allowing WARP users to switch from wireguard to MASQUE. I'm hopeful this will solve a lot of our issues.

Hm, is Wireguard getting blocked by middleboxes or something?

Sometimes yes. MASQUE just looks like normal TLS port 443 traffic so it's less likely to be prevented. Other issues we had were just bugs with the WARP wireguard implementation regarding how the tunnel is built in Windows. I imagine it works better on Linux or MacOS which is likely what the developers were running when they designed WARP.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#82

Post by altdataseller »

jamilbk wrote: post #26
altdataseller wrote: post #25

Not a comment on the actual product but did you use a specific template or stack on the app you show in the demo?

Are you referring to the macOS client app? It's built in Swift with an FFI bridge to the Rust-powered connectivity layer. Source is here: https://github.com/firezone/firezone/tree/main/swift/apple

I am referring to the web app

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#83

Post by tptacek »

PLG88 wrote: post #65
nmadden wrote: post #57

Earlier quoted context omitted.

I took tptacek’s comment as implying that ZTNA solutions do do microsegmentation. Otherwise, if I get a shell in one app and have access to the entire network then what was the point of any of it? Are you saying they don’t do microsegmentation?

Agreed. My point was that ZTNA requires more than just micro segmentation, it should also include deny by default, service based access, least privilege, endpoint posture checks etc.

Not really, no.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#84

Post by PLG88 »

RsmFz wrote: post #80
PLG88 wrote: post #39

Earlier quoted context omitted.

Through OpenZiti into the mix too - https://openziti.io/ . Its open source and was designed from the ground up with zero trust, SDN, and deny-by-default principles. It also includes SDKs to allow developers to embed ZTN as part of the SDLC. We also built zrok ( https://zrok.io/ ) on top of it, as a demonstration of a 'ziti-native' app, and being a better Ngrok.

Oh so that allows it to run in-process? That's cool, I did that for an HTTP forwarding thing a while back.

Yes, indeed, this blog gives a great view on it - https://blog.openziti.io/go-is-amazing-for-zero-trust - using Golang and HTTP examples. My favourite part:

"Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats are immediately useless."

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#85

Post by RsmFz »

illumiN8i wrote: post #81
RsmFz wrote: post #79

Earlier quoted context omitted.

Hm, is Wireguard getting blocked by middleboxes or something?

Sometimes yes. MASQUE just looks like normal TLS port 443 traffic so it's less likely to be prevented. Other issues we had were just bugs with the WARP wireguard implementation regarding how the tunnel is built in Windows. I imagine it works better on Linux or MacOS which is likely what the developers were running when they designed WARP.

Ah that's tough because Wireguard being UDP is a selling point for us at Firezone

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#86

Post by RsmFz »

PLG88 wrote: post #84
RsmFz wrote: post #80

Earlier quoted context omitted.

Oh so that allows it to run in-process? That's cool, I did that for an HTTP forwarding thing a while back.

Yes, indeed, this blog gives a great view on it - https://blog.openziti.io/go-is-amazing-for-zero-trust - using Golang and HTTP examples. My favourite part: " Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats ar…

Well that's also true for Firezone :)

It's a tradeoff between in-process and out-of-process though. It's nice that Firezone Gateways don't have access to the service's memory space and can't crash the process, but it's also nice that an in-process Gateway equivalent doesn't need to loop through the network to reach its service.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#87

Post by RsmFz »

altdataseller wrote: post #82
jamilbk wrote: post #26

Earlier quoted context omitted.

Are you referring to the macOS client app? It's built in Swift with an FFI bridge to the Rust-powered connectivity layer. Source is here: https://github.com/firezone/firezone/tree/main/swift/apple

I am referring to the web app

I think it's LiveView for the frontend-backend comms and Tailwind CSS for some of the frontend, not sure if that answers your question

-- (non-web) developer at Firezone

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#88

Post by PLG88 »

RsmFz wrote: post #86
PLG88 wrote: post #84

Earlier quoted context omitted.

Yes, indeed, this blog gives a great view on it - https://blog.openziti.io/go-is-amazing-for-zero-trust - using Golang and HTTP examples. My favourite part: " Now, your server has no listening ports on the underlay network. It's literally unattackable via conventional IP-based tooling. Seriously, stop and consider that for just a moment. By adopting an OpenZiti SDK into the server, all conventional network threats ar…

Well that's also true for Firezone :) It's a tradeoff between in-process and out-of-process though. It's nice that Firezone Gateways don't have access to the service's memory space and can't crash the process, but it's also nice that an in-process Gateway equivalent doesn't need to loop through the network to reach its service.

Maybe we are referring to different things when we say 'process'... I am not aware (happy to be educated) of Firezone having SDKs to embed the zero trust overlay running directly in an application, i.e., in the app process and memory.

Do they support this?

I hear you on having 'out of process', that's why OpenZiti also has tunnellers for deploying on host as well as virtual appliances to run in the DMZ/VNET/VPC etc. I was only aware of Firezone supporting those 2 deployment models.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#89

Post by qrkourier »

hardwaresofton wrote: post #71
PLG88 wrote: post #69

Earlier quoted context omitted.

You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster, re…

> You could use OpenZiti together with Cilium/Calico, there are some distros, eg., https://kubezt.com/ which do that (though in truth, KubeZT has moved to Istio for E-W, uses OpenZiti for N-S. OpenZiti does a lot of things that service mesh technologies do not, for example, extending outside of the cluster (incl. to non-K8S workloads), allowing closing of inbound FW ports, providing a private DNS outside of cluster,…

> This is awesome -- I really like my current admission controller though (Traefik), it's FANTASTIC. I think moving ingress controllers might be a large lift for people (it would be for me).

Clarification: You could use Traefik's ingress controller in tandem with a hypothetical OpenZiti ingress controller. You'd set `ingressClass: openziti` on those Ingress resources you wish OpenZiti to handle. Nothing would prevent you from creating two Ingress resources for the same ClusterIP service: one each for Traefik and OpenZiti.

Re: Launch HN: Firezone (YC W22) – Zero-trust access platform built on WireGuard

#90

Post by wh33zle »

illumiN8i wrote: post #81
RsmFz wrote: post #79

Earlier quoted context omitted.

Hm, is Wireguard getting blocked by middleboxes or something?

Sometimes yes. MASQUE just looks like normal TLS port 443 traffic so it's less likely to be prevented. Other issues we had were just bugs with the WARP wireguard implementation regarding how the tunnel is built in Windows. I imagine it works better on Linux or MacOS which is likely what the developers were running when they designed WARP.

Depends. MASQUE implies QUIC and a lot of coporate networks still block QUIC, forcing a fallback to TCP (for web browsers).

Not sure how they want to address this in case of WARP?

Nevertheless, MASQUE is some pretty exciting development in the network space.

Post reply on HN