May 2024 Update

In this update:

• New feature: Traffic restrictions
• Blog: How DNS works in Firezone
• Connectivity and reliability improvements

Continue reading below for more details.

Traffic restrictions

At Firezone our mission is to improve your organization's security. You've already been able to define Group-based access policies to restrict access to a particular host, but we've taken this a step further. You can now add port and protocol (ICMP, UDP, and TCP currently supported) restrictions on each Resource to define even more granular access controls.

Simply add the desired filters when creating or editing a Resource, and only that type of traffic will be allowed. This is useful for allowing access to some services running on a host but not all of them.

How it works

When you add traffic restrictions to a Resource, all Gateways that can serve that Resource will immediately receive the updated Resource configuration.

Restrictions are enforced at the Gateway level. If a user tries to access a service on the host not allowed by the restriction, the Gateway will simply drop the traffic, preventing it from ever reaching the service in question.

One popular use case for traffic restrictions is segmenting access to individual services on a host. To do this, simply create a Resource for each service on the host you want to allow access to, and add the appropriate traffic restrictions to each one. Create an Resource with the TCP/22 restriction to allow SSH access for your DevOps team, then add another Resource with the TCP/443 restriction to allow access to an HTTPS service for the rest of your organization.

Traffic restrictions are supported on all Resource types, including DNS, IP, and CIDR-based Resources, and can be enabled on the Team and Enterprise plans.

Blog: How DNS works in Firezone

Firezone's approach to DNS works a bit differently than one might expect. One question we get a lot is, "why do my DNS Resources resolve to different IPs with Firezone enabled?". Great question! We've written an in-depth explanation of this in this blog post.

So if you've ever wondered why your DNS Resources resolve to different IPs with Firezone enabled, or if you're just curious about how DNS works in Firezone, go read the post!

Connectivity and reliability improvements

Last but not least, we've made several improvements to the way Firezone Clients stay connected to Gateways, even when switching WiFi networks or moving between cellular, WiFi, and ethernet connections.

Connections were already quite stable before, but could take a few seconds to resume when switching networks. We've made several improvements to the way Clients handle network changes to improve reconnection times considerably, to the point where you shouldn't notice any interruption at all.

We also added more Points of Presence (PoPs) in several regions to improve latency and reliability for users in those areas. See our updated PoP list for more details on where Firezone's Relay and control plane servers are available.