This is a follow-up to #10851.
In order to be able to use and reason about the DoH servers, we need to
deserialize the list and pass the servers into connlib's `DnsConfig`.
Right now, they just sit there and we don't do anything with them. Thus,
this PR is save to go into `main`, even if we were to make a release
before our DoH support is fully finished.
To ensure this is the case, we also update the proptests in this PR to
randomly sample and apply DoH servers.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
On macOS, IPC calls to the network extension can wake it whilst not
connected, causing the system to create a utun device.
If startTunnel() is not subsequently called, these devices
persist and accumulate over time.
The existing dryStartStopCycle() mechanism was introduced to wake the
extension after upgrades, but other IPC operations (log management
functions) could also wake the extension without proper cleanup.
Solution
--------
Add wrapper functions in IPCClient that automatically handle wake-up
and cleanup lifecycle for IPC calls made whilst disconnected:
- Check VPN connection status
- If connected: execute IPC operation directly (utun already exists)
- If disconnected: wake extension → wait 500ms → execute IPC → cleanup
Implementation
--------------
For async IPC operations (clearLogs, getLogFolderSize):
Created free functions in IPCClient that wrap low-level IPC calls
with wrapIPCCallIfNeeded():
- clearLogsWithCleanup(store:session:)
- getLogFolderSizeWithCleanup(store:session:)
For callback-based exportLogs:
We cannot use wrapper because exportLogs returns immediately and uses
callbacks for streaming chunks. Wrapper would call stop() before
export finishes, killing the extension mid-stream.
Solution: Manual wake-up/cleanup in LogExporter where we already have
continuation that waits for chunk.done signal:
1. Check if extension needs waking (vpnStatus != .connected)
2. If yes: wake extension, wait 500ms
3. Start export with callbacks
4. When chunk.done=true: cleanup utun device, then resume continuation
5. On error: cleanup utun device, then resume with error
Fixes#10580
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
With the introduction of DoH, we will need a more advanced error type
for recursive DNS responses. In particular, a DoH query might fail
because the underlying TCP connection got closed. With #10856, the HTTP
client no longer supports retries but instead needs to be recreated.
In order to accurately detect this failure case, we need `anyhow`'s
downcasting abilities.
This PR prepares the already existing code for that by switching from
`io::Error` to `anyhow::Error`.
On Resources and Policies forms, we were triggering the form's
validation helpers when checking and unchecking a checkbox.
Unfortunately this causes the checkbox to be reset since it was not
saved across the to_form(changeset) rebuilding.
To prevent this, we simply ignore checkbox changes from triggering form
validations. We can also remove the `field=` property on these because
we are setting the `checked` property ourselves.
This will be refactored to be made simpler with the new modals approach,
so a minimal fix is implemented for now.
Related:
https://firezonehq.slack.com/archives/C098RV5BL1K/p1763024374383399Fixes: #9143
In order to bootstrap DoH servers, we need a way of reliably resolving
the domain of the DoH server to an IP address. Initially, I thought that
this would be tricky to do if we have to integrate this into the
Client's state machine.
Whilst implementing DoH however, I realised that we can instead put this
responsibility onto the IO layer of connlib. Similar to other cases, we
can reuse external triggers as our retry mechanism in case of failure.
In particular, we can simply issue UDP DNS queries for the DoH domain to
all system-defined DNS resolvers every time we are told to send a DNS
query over DoH but the corresponding client isn't initialized yet.
In other words, instead of building a retry mechanism ourselves, we
attempt to repair any kind of broken state once per DNS query that we
receive.
Performing this DNS resolution does require a bit of code. We already
started to do something similar in #10817. In order to reuse that code,
we extract it into a `l4-udp-dns-client` crate and slightly refactor its
semantics. In particular, we now wait for the response of all upstream
servers (but at most 2s) and combine the result.
The resulting `UdpDnsClient` can now be used inside the Client's
event-loop to re-resolve the portal URL and will also be used as part of
our DoH implementation to bootstrap the connection to the DoH server.
Related: #4668
Our `socket-factory`-aware HttpClient is currently only able to handle a
single request at a time. That is a result of the requirement that we
wanted to support connections to different domains but also be able to
"self-heal" those connections by establishing a new one if the current
one failed.
As I am learning more about how connlib's DoH support is going to work,
it became apparent that we will only ever need to connect to a single
domain per instance of the `HttpClient`. In addition, it is quite
important to allow for concurrent requests: We don't want to process DoH
queries in sequence but instead make full use of the underlying HTTP2
protocol and send multiple requests in parallel.
This PR refactors the `HttpClient` (which isn't in use anywhere yet) to
only support a single connection per instance. That connection is
established when the instance is created. This is also conceptually
easier to understand as we only manage a single connection without
mutable state.
Related: #4668
In order to support multiple different protocols of upstream DNS
resolvers, we deprecate the `upstream_dns` field in the client's `init`
message and introduce two new fields:
- `upstream_do53`
- `upstream_doh`
For now, only `upstream_do53` is populated and `upstream_doh` is always
empty.
On the client-side, we for now only introduce the `upstream_do53` field
but fall-back to `upstream_dns` if that one is empty. This makes this PR
backwards-compatible with the portal version that is currently deployed
in production. Thus, this PR can be merged even prior to deploying the
portal.
Internally, we prepare connlib's abstractions to deal with different
kinds of upstreams by renaming all existing "upstream DNS" references to
`upstream_do53`: DNS over port 53. That includes UDP as well as TCP DNS
resolution.
Resolves: #10791
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 24.5.2 to 24.7.2.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps
[@types/node](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/node)
from 24.5.2 to 24.7.2.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/node">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
In #10817, we landed a fix that allows Clients to re-resolve the portal
URL every time the WebSocket connection fails. Currently, we use the
active upstream resolvers for this.
This can lead to a kind of deadlock in case the upstream resolver is a
CIDR resource that we are not yet connected to. In that case, we'd need
a connection to the portal to establish a connection to the Gateway.
By always using the system resolvers for this, we avoid this circular
dependency.
By default, DNS queries are sent over UDP by most systems. UDP is an
easy to understand protocol because each packet stands by itself and at
least as far as UDP is concerned, the payload is contained within a
single packet.
In Firezone, we receive all DNS traffic on the TUN device as IP packets.
Processing the UDP packets is trivial as each query is contained within
a single IP packet. For TCP, we first need to assemble the TCP stream
before we can read the entire query.
In case a DNS query is not for a Firezone DNS resource, we want to
forward it to the specified upstream resolver, either directly from the
system or - in case the specified upstream resolver is an IP resource -
through the tunnel as an IP packet. Specifically, the forwarding of UDP
DNS packets through the tunnel currently happens like this:
IP packet -> read UDP payload -> parse DNS query -> mangle original
destination IP to new upstream -> send through tunnel
For TCP DNS queries, it is not quite as easy as we have to decode the
incoming TCP stream first before we can parse the DNS query. Thus, when
we want to then forward the query, we need to open our own TCP stream to
the upstream resolver and encode the DNS query onto that stream, sending
each IP packet from the TCP client through the tunnel.
The difference in these designs makes several code paths in connlib hard
to follow.
Therefore - and despite the simplicity of DNS over UDP - we already
created our own "Layer 3 UDP DNS"-client. This PR now integrates this
client into the tunnel. Using this new client, we can simplify the
processing of UDP DNS queries because we never have to "go back" to the
original IP packet. Instead, when a DNS query needs to be forwarded to
an usptream resolver through the tunnel, we simply tell the Layer 3 UDP
DNS client to make a new DNS query. The processing of the resulting IP
packet then happens in a different place, right next to where we also
process the IP packets of the TCP DNS client.
That simplifications unlocks further refactorings where we now only
process DNS queries in a single place and the transport we received it
over is a simple function parameter with the control flow for both of
them being identical.
Related: #4668
Currently, the DNS records for the portal's hostname are only resolved
during startup. When the WebSocket connection fails, we try to reconnect
but only with the IPs that we have previously resolved. If the local IP
stack changed since then or the hostname now points to different IPs, we
will run into the reconnect-timeout configured in `phoenix-channel`.
To fix this, we re-resolve the portal's hostname every time the
WebSocket connection fails. For the Gateway, this is easy as we can
simply reuse the already existing `TokioResolver` provided by hickory.
For the Client, we need to write our own DNS client on top of our socket
factory abstraction to ensure we don't create a routing loop with the
resulting DNS queries. To simplify things, we only send DNS queries over
UDP. Those are not guaranteed to succeed but given that we do this on
every "hiccup", we already have a retry mechanism. We use the currently
configured upstream DNS servers for this.
Resolves: #10238
Now that we have an APT repository for Debian / Ubuntu packages, we
should also tell our users about it. We introduce a new "Debian /
Ubuntu" tab on the deployments screen in the portal. The tab is selected
by default as it should provide the best user experience for manually
deployed Gateways:
- Updates are as easy as `sudo apt upgrade`
- The systemd file and token are fully managed in the background
Here is what the new tab looks like:
<img width="679" height="786" alt="image"
src="https://github.com/user-attachments/assets/da69fc55-6a6a-476d-bed4-634dd05df8bc"
/>
Resolves: #10701
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Bumps
[fast-xml-parser](https://github.com/NaturalIntelligence/fast-xml-parser)
from 5.2.5 to 5.3.0.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/CHANGELOG.md">fast-xml-parser's
changelog</a>.</em></p>
<blockquote>
<p><!-- raw HTML omitted -->Note: If you find missing information about
particular minor version, that version must have been changed without
any functional change in this library.<!-- raw HTML omitted --></p>
<p><strong>5.3.1 / 2025-11-03</strong></p>
<ul>
<li>Performance improvement for stopNodes (By <a
href="https://github.com/macieklamberski">Maciek Lamberski</a>)</li>
</ul>
<p><strong>5.3.0 / 2025-10-03</strong></p>
<ul>
<li>Use <code>Uint8Array</code> in place of <code>Buffer</code> in
Parser</li>
</ul>
<p><strong>5.2.5 / 2025-06-08</strong></p>
<ul>
<li>Inform user to use <a
href="https://github.com/NaturalIntelligence/fxp-cli">fxp-cli</a>
instead of in-built CLI feature</li>
<li>Export typings for direct use</li>
</ul>
<p><strong>5.2.4 / 2025-06-06</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/747">#747</a>):
fix EMPTY and ANY with ELEMENT in DOCTYPE</li>
</ul>
<p><strong>5.2.3 / 2025-05-11</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/747">#747</a>):
support EMPTY and ANY with ELEMENT in DOCTYPE</li>
</ul>
<p><strong>5.2.2 / 2025-05-05</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/746">#746</a>):
update strnum to fix parsing issues related to enotations</li>
</ul>
<p><strong>5.2.1 / 2025-04-22</strong></p>
<ul>
<li>fix: read DOCTYPE entity value correctly</li>
<li>read DOCTYPE NOTATION, ELEMENT exp but not using read values</li>
</ul>
<p><strong>5.2.0 / 2025-04-03</strong></p>
<ul>
<li>feat: support metadata on nodes (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/593">#593</a>)
(By <a href="https://github.com/srl295">Steven R. Loomis</a>)</li>
</ul>
<p><strong>5.1.0 / 2025-04-02</strong></p>
<ul>
<li>feat: declare package as side-effect free (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/738">#738</a>)
(By <a href="https://github.com/tbouffard">Thomas Bouffard</a>)</li>
<li>fix cjs build mode</li>
<li>fix builder return type to string</li>
<li></li>
</ul>
<p><strong>5.0.9 / 2025-03-14</strong></p>
<ul>
<li>fix: support numeric entities with values over 0xFFFF (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/726">#726</a>)
(By <a href="https://github.com/mcdurdin">Marc Durdin</a>)</li>
<li>fix: update strnum to fix parsing 0 if skiplike option is used</li>
</ul>
<p><strong>5.0.8 / 2025-02-27</strong></p>
<ul>
<li>fix parsing 0 if skiplike option is used.
<ul>
<li>updating strnum dependency</li>
</ul>
</li>
</ul>
<p><strong>5.0.7 / 2025-02-25</strong></p>
<ul>
<li>fix (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/724">#724</a>)
typings for cjs.</li>
</ul>
<p><strong>5.0.6 / 2025-02-20</strong></p>
<ul>
<li>fix cli output (By <a href="https://github.com/angeld7">Angel
Delgado</a>)
<ul>
<li>remove multiple JSON parsing</li>
</ul>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="badf18960c"><code>badf189</code></a>
Use <code>Uint8Array</code> in place of <code>Buffer</code> in
Parser</li>
<li><a
href="418ab9535c"><code>418ab95</code></a>
fix <a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/764">#764</a>
(<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/765">#765</a>)</li>
<li><a
href="ad17aa4b12"><code>ad17aa4</code></a>
Fix typo in types (<a
href="https://redirect.github.com/NaturalIntelligence/fast-xml-parser/issues/760">#760</a>)</li>
<li>See full diff in <a
href="https://github.com/NaturalIntelligence/fast-xml-parser/compare/v5.2.5...v5.3.0">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [nu-ansi-term](https://github.com/nushell/nu-ansi-term) from
0.50.1 to 0.50.3.
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/nushell/nu-ansi-term/commits">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The current CI job expects the release to have the `.deb` files
attached. Since writing that workflow, I've changed my mind on attaching
the `.deb` files there. Instead, they are only uploaded to the
repository. Without documentation on how to use them, these `.deb` files
are unlikely to provide a good user experience.
We change the job to instead promote the latest "preview` archives to
the stable repo.
By default, the Sentry SDK doesn't include custom user attributes when
it sends logs. To make viewing logs easier, we add the `account_slug`
attribute to all logs that are posted to Sentry.
All of our Linux applications have a soft-dependency on systemd. That
is, in the default configuration, we expect systemd to be present on the
machine. The only exception here are the docker containers for Headless
Client and Gateway.
For the GUI client in particular, systemd is a hard-dependency in order
to control DNS on the system which we do via `systemd-resolved`. To
secure the communication between the GUI client and its tunnel process,
we automatically create a group called `firezone-client` to which the
user gets added. All members of the group are allowed to access the unix
socket which is used for IPC between the two processes. Membership in
this group is also a prerequisite for accessing any of the configuration
files.
On the first launch of the GUI client on a Linux system, this presents a
problem. For group membership changes to take the effect, the user needs
to reboot. We say that in the documentation but it is unclear whether
all users will read that thoroughly enough. To help the user, the GUI
client checks for membership of the current user in the group and alerts
the user via a dialog box if that isn't the case. This would all be fine
if it would actually work. Unfortunately, that check ends up being too
late in the process. If we aren't a member of the group, we cannot read
the device ID and bail early, thus never reaching the check and
terminating the process without any dialog box or user-visible error.
We could attempt to fix this by shuffling around some of the startup
init code. That is a sub-optimal solution however because it a) may get
broken again in the future and b) it means we have to delay
initialisation of telemetry until a much later point.
Given that this is only a problem on Linux, a better solution is to
simply not rely on the disk-based device ID at all. Instead, we can
integrate with systemd and deterministically derive a device ID from the
unique machine ID and a randomly chosen "app ID".
For backwards-compatibility reasons, the disk-based device ID is still
prioritised. For all new installs however, we will use the one based on
`/etc/machine-id`.
When we are building the log message that is sent to Sentry, we append
several attributes to mimic the formatting that we get from
`tracing_subscriber::fmt`. To do that, we strip the span name from the
attribute which can result in us processing the same attribute such as
`cid` twice: Once from a span and once from the actual log message. In
order to not append the same message twice, we check for its presence in
the attributes map first.
This avoids having message in Sentry such as:
```
Sampled relay cid=c18e1da8-8ef8-4e11-a325-28d6b387d503 rid=3af15c76-9e84-46a6-90e1-63ecb2bc9f80 cid=c18e1da8-8ef8-4e11-a325-28d6b387d503
```
When investigating, why a connection fails it is useful to know right
away, what the last connection state was, including the kind of
connection, such as `PeerToPeer`, `RelayToPeer` etc.
Sentry appends "breadcrumbs" to every error that gets sent to the
backend. By default, those include the last 500 DEBUG logs. Our
`phoenix_channel` module logs the incoming and outgoing messages on
TRACE using the `wire::api::send` and `wire::api::recv` targets.
To make debugging these easier, we always include anything on
`wire::api` in the breadcrumbs.
The current test installation fails because it is operating in a
headless environment without a display user. Some more testing of the
`who` command showed that we can simply take the first user. That avoids
`grep` which was previously failing with an exit code of 1, aborting the
installation because our `postinst` script has `pipefail` set.
Specifying `sudo` in the script is unnecessary as it already runs as
root. Additionally, only executing `systemd-sysusers` for our config
file is better because it narrows the scope of what should be done.
Several aspects of the Gateway's Debian package depend on `systemd`
being present. Without it, we don't have the necessary users and files
in place for the Gateway to function. With that specified, we can fail
the `postinst` script (and therefore the installation) if anything in
there goes wrong.
By checking various environment variables, we can automatically add the
current user to the `firezone-client` group which allows them to connect
to the IPC socket of the tunnel process. Unfortunately, they still have
to create a new login session / reboot for that to be reflected.
The docs update for this will follow once we have cut a release with
this code in it.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Prompted by Xcode warning at project startup.
Most of the changes are simple migrations from entitlements files
to build settings, which is the recommended approach, and were done
automatically by Xcode.
new settings:
- REGISTER_APP_GROUPS - Automatically registers app groups with
provisioning
profile (I had to set this manually when setting up, so it's a welcome
change)
- STRING_CATALOG_GENERATE_SYMBOLS - type-safe localization (no
regression, we're not doing any localization currently)
- ENABLE_USER_SCRIPT_SANDBOXING - sandboxing all the build scripts
Note: I had to turn off the recommended `ENABLE_USER_SCRIPT_SANDBOXING`
as it
would interfere with our building of connlib during the build.
Also: make Makefile more ergonomic to use (setup LSP config during first
build)
For DNS resources, the Gateway maintains a per-peer NAT table from the
client-assigned proxy IPs to the real IPs of the domain. Whenever the
Client re-queries a DNS resource domain locally, we asynchronously ping
the Gateway to also re-query said domain. This allows us to detect
changes in the DNS records of DNS resources.
To avoid breaking existing connections, the mapping between proxy IPs
and real IPs is currently not updated if there are any active UDP or TCP
flows for a proxy IP.
This logic turns out to be unnecessarily restrictive as TCP flows can
linger around for up to 2h before they timeout if they are not closed
with a TCP RST. What we really need to do is always update the mapping
of proxy IP <> real IP but honor existing NAT table entries when we
route packets before creating new ones. This ensures that an existing
connection to a previously resolved IP remains intact, even if a later
DNS response for the same domain updates the mapping. At the same time,
new connections (i.e. with a different source port) will immediately use
the new destination IP.
Refactors IPCClient from an actor to a stateless enum with static
methods, removing unnecessary actor isolation and instance management.
- IPCClient: Actor → enum with static methods taking session parameter
- Store: Removed IPCClient instance caching, added resource list caching
- Store: Moved resource fetching logic from IPCClient into Store
- All call sites: Updated to pass session directly to static methods
Store now directly manages resource list hashing and caching via
fetchResources() method, using SHA256 hash optimisation to avoid
redundant updates when resource lists haven't changed.
Enables SWIFT_APPROACHABLE_CONCURRENCY build setting which activates
a few key Swift 6.2 concurrency features, including:
1. NonisolatedNonsendingByDefault - Makes nonisolated async functions
run
on the caller's executor instead of the global executor, providing
more predictable performance and behaviour
2. InferIsolatedConformances - Protocol conformances automatically
inherit global actor isolation, reducing annotation burden
Read more:
https://www.donnywals.com/what-is-approachable-concurrency-in-xcode-26/
Also bumps swift-tools-version from 6.0 to 6.2 in Package.swift to
enable newer Package Manager manifest APIs.
As a result of better type inference, removes 1 redundant @Sendable
annotation in Store.swift:
- vpnStatusChangeHandler: @MainActor closures are implicitly Sendable
This PR upgrades the Swift client from Swift 5 to Swift 6.2, addressing
all
concurrency-related warnings and runtime crashes that come with Swift
6's
strict concurrency checking.
## Swift 6 Concurrency Primer
**`actor`** - A new reference type that provides thread-safe, serialised
access to mutable state. Unlike classes, actors ensure that only one
piece of
code can access their mutable properties at a time. Access to actor
methods/properties requires await and automatically hops to the actor's
isolated executor.
**`@MainActor`** - An attribute that marks code to run on the main
thread.
Essential for UI updates and anything that touches UIKit/AppKit. When a
class/function is marked @MainActor, all its methods and properties
inherit
this isolation.
**`@Sendable`** - A protocol indicating that a type can be safely passed
across concurrency domains (between actors, tasks, etc.). Value types
(structs, enums) with Sendable stored properties are automatically
Sendable.
Reference types (classes) need explicit @unchecked Sendable if they
manage
thread-safety manually.
**`nonisolated`** - Opts out of the containing type's actor isolation.
For
example, a nonisolated method in a @MainActor class can be called from
any
thread without await. Useful for static methods or thread-safe
operations.
**`@concurrent`** - Used on closure parameters in delegate methods.
Indicates
the closure may be called from any thread, preventing the closure from
inheriting the surrounding context's actor isolation. Critical for
callbacks
from system frameworks that call from background threads.
**Data Races** - Swift 6 enforces at compile-time (and optionally at
runtime)
that mutable state cannot be accessed concurrently from multiple
threads. This
eliminates entire classes of bugs that were previously only caught
through
testing or production crashes.
## Swift Language Upgrade
- **Bump Swift 5 → 6.2**: Enabled strict concurrency checking throughout
the
codebase
- **Enable ExistentialAny (SE-0335)**: Adds compile-time safety by
making
protocol type erasure explicit (e.g., any Protocol instead of implicit
Protocol)
- **Runtime safety configuration**: Added environment variables to log
concurrency violations during development instead of crashing, allowing
gradual migration
## Concurrency Fixes
### Actor Isolation
- **TelemetryState actor** (Telemetry.swift:10): Extracted mutable
telemetry
state into a dedicated actor to eliminate data races from concurrent
access
- **SessionNotification @MainActor isolation**
(SessionNotification.swift:25):
Properly isolated the class to MainActor since it manages UI-related
callbacks
- **IPCClient caching** (IPCClient.swift): Fixed actor re-entrance
issues and
resource hash-based optimisation by caching the client instance in Store
### Thread-Safe Callbacks
- **WebAuthSession @concurrent delegate** (WebAuthSession.swift:46): The
authentication callback is invoked from a background thread by
ASWebAuthenticationSession. Marked the wrapper function as @concurrent
to
prevent MainActor inference on the completion handler closure, then
explicitly hopped back to MainActor for the session.start() call. This
fixes EXC_BAD_INSTRUCTION crashes at _dispatch_assert_queue_fail.
- **SessionNotification @concurrent delegate**
(SessionNotification.swift:131): Similarly marked the notification
delegate
method as @concurrent and used Task { @MainActor in } to safely invoke
the
MainActor-isolated signInHandler
### Sendable Conformances
- Added Sendable to Resource, Site, Token, Configuration, and other
model
types that are passed between actors and tasks
- **LogWriter immutability** (Log.swift): Made jsonData immutable to
prevent
capturing mutable variables in @Sendable closures
### Nonisolated Methods
- **Static notification display** (SessionNotification.swift:73): Marked
showSignedOutNotificationiOS() as nonisolated since it's called from the
Network Extension (different process) and only uses thread-safe APIs
Fixes#10674Fixes#10675
