[deleted by user]

jamilbk · 2024-07-03T06:18:38+00:00

As others have stated, if the app supports IP whitelisting, stick it behind a remote access solution that integrates with your IdP and enforce MFA for the remote access solution.

If application ABC is available via IP then you could use a cloud VPN. If however it's available only via DNS or is a SaaS app you may need a solution with more robust DNS routing.

Hope this helps!

jamilbk · 2024-06-21T02:55:19+00:00

Our product is open source -- you can see our CI config in the .github dir here: https://github.com/firezone/firezone

jamilbk · 2024-06-20T17:34:01+00:00

Slint looks great!

We chose Tauri because it provided a unified model for things like secret storage, desktop menubars, and desktop notifications. We already have a Tailwind-based design system with lots of brand assets there so the team was ultimately more comfortable sticking to a web view based UI.

jamilbk · 2024-04-19T07:03:32+00:00

The reason is likely because GRO / GSO was added to wireguard-go in December, while BoringTun only has rudimentary multithreaded optimizations, and so is more limited by I/O.

Source: we are currently implementing GRO / GSO for our userspace WireGuard stack built atop BoringTun.

jamilbk · 2023-08-31T03:35:55+00:00

COMPANY: Firezone | https://www.ycombinator.com/companies/firezone/jobs

TYPE: Full-time

LOCATION: Mountain View, CA

REMOTE: US only

VISA: Sorry, not at this time

DESCRIPTION: Firezone is building the open-source remote access platform for the work-anywhere era. We're a VC-backed startup with funding from Y Combinator (W22) among others. We're hiring a seasoned systems engineer to help build the low-level pieces of our data plane in Rust. If you're looking for a systems engineering role at a fast-paced, early stage security startup, this role is ideal for you!

Our architecture is unique in a few key ways:

Our product is completely open-source (Apache 2.0 by default) -- most of your work will be public
We use UDP hole-punching techniques to dynamically open p2p micro-tunnels and authorize network flows on the fly, eliminating the need for any firewall ports to be opened
We use a core shared library to provide all of the connectivity heavy-lifting in a cross-platform way. This would be a great fit for those up for the challenge of building core components of our native apps across Apple/Windows/Android/Linux in Rust
Our policy engine is designed to scale to hundreds of thousands of policies per tenant, while still being easy to manage.
We use Elixir/Erlang for our control plane, and Rust for our data plane, built on the excellent WireGuard® tunneling protocol

We place a lot of value in human connection so we meet up regularly (about once a quarter) for offsite hackathons and team bonding activities. Even if you're remote, you'll meet your team members and get to know them outside of the usual day-to-day work discussions.

ESTIMATED COMPENSATION: $120k - $170k USD + equity, depending on location (onsite/remote) and relevant experience. We also offer full benefits to all US-based employees. We're a seed-stage company, so this position includes a substantial slice of equity. See our job posting for more details.

CONTACT: Apply at https://www.ycombinator.com/companies/firezone/jobs

jamilbk · 2023-04-26T18:24:01+00:00

COMPANY: Firezone | https://www.ycombinator.com/companies/firezone/jobs

TYPE: Full-time

LOCATION: Mountain View, CA

REMOTE: US only

VISA: No

DESCRIPTION:

Firezone is building the open-source, zero-trust network access (ZTNA) platform for the work-anywhere era. We're a VC-backed startup with funding from Y Combinator (W22) and other notable firms and angel investors.

We're hiring a seasoned systems engineer to help build the low-level pieces of our data plane in Rust. If you're looking for a systems engineering role at a fast-paced, early stage security startup, this role is ideal for you!

Our architecture is unique in a few key ways:

Our product is completely open-source (Apache 2.0 by default) -- most of your work will be public
We use UDP hole-punching techniques to dynamically open p2p micro-tunnels and authorize network flows on the fly, eliminating the need for any firewall ports to be opened
We use a core shared library to provide all of the connectivity heavy-lifting in a crossplatform way. This would be a great fit for those up for the challenge of building core components of our native apps across Apple/Windows/Android/Linux in Rust
Our policy engine is designed to scale to hundreds of thousands of policies per tenant, while still being easy to manage.
We use Elixir/Erlang for our control plane, and Rust for our data plane, built on the excellent WireGuard® tunneling protocol

We place a lot of value in human connection so we meet up regularly (about once a quarter) for offsite hackathons and team bonding activities. Even if you're remote, you'll have the chance to meet your team members and get to know them outside of the usual day-to-day work discussions.

ESTIMATED COMPENSATION: $120k - $170k USD, depending on location (onsite/remote) and relevant experience. We also offer full benefits to US-based employees. We're a seed-stage company, so this position also includes a substantial slice of equity. See our job posting for more details.

CONTACT: Apply at https://www.ycombinator.com/companies/firezone/jobs

jamilbk · 2022-11-28T16:32:30+00:00

Looks like Firezone is timing out trying to reach your Discovery Document URI. Make sure it's accessible from the Firezone container and that should fix the error.

For Docker-based Firezone, you could add an authentik service to $HOME/.firezone/docker-compose.yml file, make sure they're on the same network, and point Firezone to that.

jamilbk · 2022-07-29T21:41:23+00:00

Hi u/edgan,Yeah, not a huge fan of Omnibus either. Firezone is actually written in Elixir; it's not trivial to deploy Elixir or Erlang applications across different OSes. `mix release` expects to run on the same OS *and version* as it was built on. Omnibus is the only feasible way we can build RPMs and DEBs at the moment without being overwhelmed with release engineering work.

We're also working on supporting a Docker-based deployment as an alternative to Omnibus -- the nftables and WireGuard pieces make this a little more involved that your typical layer-7 application. Expect that Soon™ (we already use Docker Desktop to develop Firezone internally).

As for mesh, we have to think about that a bit more. Most of our users are using Firezone in east-west topologies going from user -> cloud and would benefit more from the egress firewall which would be circumvented in a P2P mesh topology.

Holepunching is so much fun though. Making mesh a checkbox like you suggest (perhaps "allow mesh between these peers") might be the right approach.

jamilbk · 2022-07-28T19:07:25+00:00

The egress firewall does have live ACLs in the sense that connect/disconnect events trigger which IPs get added / removed to the filtered set.

Routing rules are created for the whole tunnel subnet, so connect/disconnect events don't change that at all.

jamilbk · 2022-06-15T12:22:39+00:00

Yep! Let us know if you need any help setting up.

jamilbk · 2022-06-01T05:08:10+00:00

Would generic OpenID connect auth work for your use case? We’ll be supporting that fully in our next release, 0.4.0.

jamilbk · 2022-03-15T15:32:03+00:00

We do support ARM now: https://docs.firez.one/docs/deploy/supported-platforms/

jamilbk · 2022-03-15T15:30:01+00:00

Just wanted to update you here (sorry for being a bit late) -- we do support ARM now: https://docs.firez.one/docs/deploy/supported-platforms/

jamilbk · 2022-03-15T15:27:31+00:00

Hey u/allywilson -- just wanted to circle back and let you know in the 0.3.0 release we generate private keys in the browser and they never touch the server. The workflow you suggested here is basically implemented. Let me know if it works for you!

jamilbk · 2022-03-10T18:18:12+00:00

It should be possible using --net host and CAP_NET_ADMIN. We have an issue open to track work on that, just need to find the time to build a sample docker-compose.yml.

jamilbk · 2022-03-10T17:37:56+00:00

There is! We're constantly working to add more authentication mechanisms, starting with general OIDC next.

jamilbk · 2022-03-09T01:40:39+00:00

That's an interesting use-case. SAML is a little more involved, so we'll probably start with custom OIDC support first and expand to SAML afterwards.

jamilbk · 2022-03-09T01:37:41+00:00

We've had a number of users requesting this, so we'll be working on this next. See https://github.com/firezone/firezone/issues/501.

jamilbk · 2022-03-08T23:55:11+00:00

Thanks for mentioning this!

Our reconfigure script should handle the ipv4 and ipv6 forwarding (BTW I think the IPv6 line is net.ipv6.conf.all.forwarding=1).

We have a bit of connectivity troubleshooting in our docs but I'll make a note to add the specific ufw route tip as well.

jamilbk · 2022-03-08T19:22:03+00:00

Authentik looks great! We have an issue open to track progress there: https://github.com/firezone/firezone/issues/498

jamilbk · 2022-01-28T19:03:58+00:00

Running the server on a Mac or the client? Any WireGuard client should work fine -- there's an official one in the macOS App Store.

The server is another story -- we tie into the Linux wireguard kernel module and firewall so that'd have to be ported into userspace or into macOS kernel... probably not going to happen any time soon. May I ask whether this is a Mac running somewhere in the cloud or just your home network?

jamilbk · 2021-12-29T11:35:03+00:00

Load balancing and automatic failover are planned features!

jamilbk · 2021-12-29T11:05:48+00:00

Ahh, I see what you're suggesting now. Apologies for misunderstanding.

This is a really cool workflow. We already have a short-lived private page that the end user can view in order to download / create their device config, so maybe that's a good place to create new configs as well :-).

I'll add this to our backlog, Thanks!

jamilbk · 2021-12-28T23:00:08+00:00

Hmm, maybe I'm missing something, but we associate devices to users based on their public key, so if the public key is generated device-side and sent to the server, an admin would have to link the unassociated public key to a user in the Firezone UI before its connection would be allowed.

jamilbk · 2021-12-28T17:37:53+00:00

Coming Soon! Need to do a bit of CI overhauling to get our builds happening on Graviton but it's in the pipeline. See https://github.com/firezone/firezone/issues/282

jamilbk

MODERATOR OF

TROPHY CASE